Network Working Group M. Allman
Request for Comments: 2414 NASA Lewis/Sterling Software
Category: Experimental S. Floyd
LBNL
C. Partridge
BBN Technologies
September 1998
Увеличение начального окна TCP
Increasing TCP’s Initial Window
Статус документа
Этот документ описывает экспериментальный протокол (Experimental Protocol) для сообщества Internet и не задает каких-либо стандартов Internet. Документ служит приглашением к дискуссии в целях развития протокола и может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (1998). All Rights Reserved.
Тезисы
Этот документ задает увеличение разрешенного начального окна TCP с одно сегмента приблизительно до 4 килобайт. В документе рассматриваются преимуществ и недостатки такого подхода, а также приводятся результаты экспериментов, показывающие издержки и преимущества такого изменения TCP.
Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [RFC2119].
1. Изменение TCP
Этот документ задает возможность увеличения верхней границы размера начального окна TCP с одного сегмента до 2 – 4. В большинстве случаев это приводит к увеличению верхней границы размера начального окна приблизительно до 4 Кбайт (хотя при большом размере сегментов разрешенное начальное окно в два сегмента может быть существенно больше 4 Кбайт). Верхняя граница размера начального окна определяется уравнением (1).
min (4*MSS, max (2*MSS, 4380 байт)) (1)
Эквивалентные уравнения для начального размера окна, основанном на максимальном размере сегмента (MSS1) приведены ниже.
If (MSS <= 1095 байт)
then win <= 4 * MSS;
If (1095 байт < MSS < 2190 байт)
then win <= 4380;
If (2190 байт <= MSS)
then win <= 2 * MSS;
Такое увеличение начального размера окна не является обязательным – TCP может начинать работу с большим размером окна, но не обязан делать это.
Эта верхняя граница начального размера окна отличается от указанной в RFC 2001 [S97], где сказано, что окно насыщения инициализируется с размеров один сегмент. Если опыт реализации этого предложения будет успешным, предполагается включить данное изменение при пересмотре RFC 2001.
Это изменение применяется к начальному окну соединения в первый период кругового обхода (RTT2) передачи, следующей за трехэтапным согласованием TCP. Ни SYN/ACK, ни его подтверждение (ACK) при трехэтапном согласовании не должны увеличивать начальный размер окна сверх значения, определяемого уравнением (1). Если пакет SYN или SYN/ACK теряется, начальное окно, используемое отправителем после корректно переданного пакета SYN должно быть размером в 1 сегмент.
Реализации TCP используют процедуру замедленного старта как минимум тремя разными способами: (1) для организации нового соединения (начальное окно), (2) для восстановления передачи после продолжительного бездействия (окно перезапуска) и (3) перезапуска после тайм-аута повтора (окно потерь). Предложенные в этом документе изменения влияют на размер начального окна. В дополнение к этому TCP может установить для окна перезапуска меньшее из значений начального окна и текущего cwnd (иными словами, использовать увеличенное окно перезапуска без увеличения размера cwnd). Предлагаемые изменений не затрагивают окна потерь, размер которого должен оставаться равным 1 сегменту (чтобы разрешить минимально возможный размер окна при сильной перегрузке).
2. Вопросы реализации
При использовании увеличенного начального окна вместе с Path MTU Discovery [MD90] и обнаружении слишком большого значения MSS, которое будет применяться, размер окна насыщения cwnd следует уменьшить для предотвращения больших всплесков сегментов малого размера. Значение cwnd следует на коэффициент, равный отношению старого размера сегмента к новому.
При использовании увеличенного начального окна вместе с Path MTU Discovery [MD90] возможна установка бита DF3 во всех сегментах начального окна или только в одном из сегментов. Выбор одного из этих вариантов является открытым вопросом — предполагается, что опыт реализации поможет выбрать лучший вариант. В первом случае при установки флага DF во всех сегментах все начальные пакеты слишком большого размера будут отброшены в сети. Во втором случае все слишком большие пакеты, за исключением помеченного флагом DF, будут фрагментированы в сети. Если в этом варианте флаг DF устанавливается для последнего сегмента начального окна, это обеспечивает снижение вероятности передачи ненужных повторов, когда размер начального сегмента оказывается слишком велик, поскольку минимизируется вероятность дубликатов подтверждений ACK, включающих механизм ускоренного повтора (Fast Retransmit). Однако в этом случае требуется более внимательно учитывать взаимодействие между увеличенным начальным окном и механизмом Path MTU Discovery.
Предложенное в этом документе увеличение размера начального окна не предназначено для поощрения web-браузеров к открытию множества одновременных соединений TCP с большими начальными окнами. Когда браузер открывает множество одновременных соединений TCP с одним адресатом, это работает против механизмов контроля перегрузок TCP [FF98], независимо от размера начального окна. Совмещение такого подхода с увеличением начального окна усугубляет ситуацию .
3. Преимущества большего окна
-
Когда начальное окно имеет размер 1 сегмент, получатель, использующий отложенные подтверждения [Bra89], вынужден ждать тайм-аута прежде, чем генерировать ACK. При начальном окне в два сегмента и больше получатель будет генерировать ACK после прибытия второго сегмента данных. Это избавляет от необходимости ждать тайм-аут (зачастую до 200 мсек).
-
Для соединений, передающих незначительный объем данных, увеличенное начальное окно уменьшает время передачи (в предположении умеренной потери сегментов). Для многих почтовых транзакций (SMTP [Pos82]) и передачи web-страниц (HTTP [BLFN96, FJGFBL97]) объем данных составляет менее 4 Кбайт и увеличенное начальное окно будет снижать время передачи до одного периода RTT.
-
Для соединений, которые способны использовать большое окно насыщения, предлагаемое изменение избавляет от ожидания трех интервалов RTT и тайм-аута отложенных подтверждений на начальной фазе замедленного старта (slow-start). Это преимущество особенно заметно на широкополосных каналах со значительными задержками (например, спутниковых).
4. Недостатки увеличенного окна для отдельного соединения
В средах с высоким уровнем насыщения, в частности, маршрутизаторах, предпочитающих ровный трафик сильным всплескам (типа маршрутизаторов с очередями Drop Tail4) соединения TCP иногда лучше начинать с окном размером в один сегмент. Существуют сценарии, в которых соединение TCP с замедленным стартом и начальным окном в один сегмент не будет сталкиваться с отбрасыванием сегментов, тогда как соединение TCP с начальным окном в 4 сегмента может столкнуться с неожиданными повторами передачи в результате неспособности маршрутизатора обрабатывать небольшие пики трафика. Это может приводить к неоправданным тайм-аутам повтора передачи. Для соединения с большим окном, которое может восстанавливаться без тайм-аута повтора, это будет приводить к слишком раннему переходу из фазы замедленного старта (slow-start) в фазу предотвращения перегрузки (congestion-avoidance) алгоритма управления окном. Такие преждевременные потери сегментов вряд ли будут происходить в слабо загруженных сетях с достаточной буферизацией или сетях со средним уровнем перегрузки, где перегруженные маршрутизаторы используют активное управление очередями(например, Random Early Detection [FJ93, RFC2309]).
Для некоторых соединений TCP увеличение размера начального окна будет повышать производительность даже в тех случаях, когда связанный с начальным окном пик трафика приводит к преждевременному отбрасыванию сегментов. Это верно, если (1) соединение TCP восстанавливается после потери сегмента без тайм-аута повтора и (2) соединение TCP вынуждено использовать небольшое окно насыщения по причине перегрузки сети или в соответствии с анонсированным получателем размером окна приема.
5. Недостатки увеличенного окна для сети
С точки зрения возможности коллапса насыщения рассматривается две разных потенциальных опасности для сети. Первая опасность связана с ситуациями, когда большое число сегментов в перегруженных каналах является дубликатами сегментов, которые уже получены адресатами. Вторая опасность связана со случаями, в которых большое число сегментов в перегруженных каналах будет потом отброшено в сети до получения их адресатами.
В плане отрицательного воздействия на другой трафик в сети возможные недостатки в результате увеличения размера начального окна связаны с общим повышением частоты отбрасывания пакетов в сети. Все три случая более подробно рассмотрены ниже.
Дубликаты сегментов
Как описано в предыдущем параграфе, увеличение размера начального окна иногда может приводить к отбрасыванию сегмента из начального окна, если отправитель использует процедуру замедленного старта (slow-started) с начальным окном в один сегмент. Однако в Приложении A показано, что даже в таких случаях увеличение размера начального окна не приводит к росту числа передаваемых дубликатов сегментов.
Отброшенные в сети сегменты
Насколько увеличенное начальное окно TCP будет повышать число сегментов, которые будут отбрасываться в перегруженных каналах, не достигая конечного получателя? Имеется проблема, проявляющая только в соединениях, проходящих через множество перегруженных каналов, когда сегмент может использовать дефицитный ресурс полосы перегруженного канала, а потом оказаться отброшенным в очередном перегруженном канале на своем пути.
Во-первых, многие соединения TCP будут включать на своем пути лишь один перегруженный канал. В таком случае отброшенные сегменты не будут «потреблять» дефицитную пропускную способность и вносить свой вклад в возникновение коллапса насыщения.
Однако некоторые пути будут включать множество перегруженных каналов и сегменты из начального окна, которые уже использовали дефицитную пропускную способность первого перегруженного канала, могут быть отброшены в последующих перегруженных каналах. Поскольку частота отбрасывания пакетов не зависит от размера начального окна, используемого TCP, проблема перегруженных каналов, передающих сегменты, которые будут впоследствии отброшены до прибытия к конечному адресату, будет похожей для соединений TCP, начинающихся с отправки 4 сегментов и 1 сегмента.
Повышение уровня потерь
Для сети с высокой частотой отбрасывания сегментов увеличение начального окна TCP может дополнительно повысить частоту отбрасывания сегментов. Это частично обусловлено тем, что маршрутизаторы с управлениям очередями Drop Tail сталкиваются с трудностями при всплесках трафика в периоды насыщения. Однако с учетом отсутствия корреляций прибытия сегментов разных соединений TCP увеличение начального окна TCP не должно существенно повышать частоту отбрасывания сегментов. Имитационные исследования этого вопроса рассмотрены в параграфе 7.2.
Упомянутые здесь потенциальные опасности для сети исследовались на моделях и в экспериментах, описанных ниже. Наше заключение состоит в том, что при наличии опасности коллапса перегрузки в современной сети Internet (см. [FF98], где рассматривается опасность коллапса насыщения в результате роста числа приложений UDP без сквозного контроля перегрузок),увеличение размера начального окна TCP до 4 Кбайт не создает дополнительной опасности.
6. Типичные уровни всплесков трафика для TCP
Увеличение начального окна TCP не приведет к резкому росту всплесков трафика TCP в современной сети Internet, поскольку этот трафик уже является достаточно «взрывным». Пики в 2 или 3 сегмента уже типичны для TCP [Flo97], отложенные подтверждения (покрывающие два еще не подтвержденных сегмента), полученные в период предотвращения перегрузки приводят к сдвигу окна насыщения и передаче двух сегментов. Те же самые отложенные пакеты ACK, полученные во время процедуры замедленного старта (slow start) сдвигают окно на два сегмента, увеличивая его на один сегмент, что ведет к всплеску из трех сегментов. Пики из 4 и 5 сегментов TCP не столь распространены, но достаточно часты. Для отложенных подтверждений один отброшенный пакет ACK приводит к последующему подтверждению, которое покрывает 4 еще не подтвержденных сегмента. Во время процедуры предотвращения перегрузки это вызывает передачу 4 сегментов, а во время замедленного старта – 5.
Меняется также процесс ослабления проблем производительности, вызываемых пиками трафика среднего размера. Одно из таких изменений заключается во внедрении высокоскоростных каналов на некоторых участках сети и пики трафика в 4 Кбайта здесь представляют достаточно малый объем данных. Второе изменение связано с маршрутизаторами, имеющими достаточную буферную емкость и поддерживающими механизмы управления очередями типа RED, которые разработаны с учетом устойчивости к пикам трафика.
7. Результаты моделирования и экспериментов
7.1 Исследование соединений TCP с увеличенным начальным окном
В этом разделе рассмотрены модели и эксперименты, использованные для исследования влияния увеличенного начального окна TCP на применяющие это соединения. В первом наборе экспериментов исследовалась работа соединений через спутниковые каналы. Было показано, что увеличение начального размера окна повышает производительность соединений TCP через спутниковые каналы [All97b]. В этом исследовании начальное окно в 4 сегмента (512-байтовые MSS) приводило к росту производительности до 30% (в зависимости от суммарного объема передачи). В [KAGT98] показано, что использование увеличенного начального окна ведет к снижению времени передачи в тестах HTTP через спутниковые каналы ACTS. Исследование включало моделирование большого числа соединений HTTP на гибридных линиях HFC5, которое показало, что увеличение начального окна снижает время загрузки страниц WWW [Nic97].
Во второй группе экспериментов исследовалась производительность соединений TCP на модемных каналах через телефонную сеть. В экспериментах на канале 28,8 кбит/с6 [All97a, AHO98] 4-сегментное начальное окно снижало время передачи файла размером 16 Кбайт примерно на 10% без увеличения частоты отбрасывания пакетов. Особый интерес вызывали соединения TCP через низкоскоростные каналы (например, модемы на телефонных линиях) в комбинации с маршрутизаторами, имеющими малый размер буферов. В модельном исследовании [SP97] рассматривалось влияние увеличенного начального окна на хосте, подключенном через модем к маршрутизатору с буфером на 3 пакета. В этом случае увеличение размера начального окна не снижало производительности TCP. Были подняты вопросы о влиянии увеличенного начального окна на время передачи небольших объемов данных в такой среде, однако этот эффект не был определен количественно. Был также поднят вопрос влияния на другие соединения TCP через этот же канал.
7.2 Исследование сетей с увеличенным начальным окном
В этом параграфе рассматриваются модели и эксперименты по исследованию влияния увеличенного начального окна на другие соединения TCP, проходящие по тому же пути. Эксперименты [All97a, AHO98] показали, что при передаче 16-килобайтных блоков данных 100 хостам Internet 4-сегментное начальное окно приводит к незначительному росту частоты отбрасывания пакетов (0,04 сегмента на передачу). Частота потерь возрастала несущественно, а время передачи снижалось примерно на 25% для передач с использованием 4-сегментного (512-байтовый MSS) начального окна по сравнению с обычным окном в 1 сегмент.
Одним из вызывающих беспокойство вопросов являются сильно загруженные каналы. Например, несколько лет назад один из трансатлантических каналов был загружен так сильно, что корректный размер окна насыщения для соединений составил около 1 сегмента. В такой среде новые соединения с увеличенным начальным окном будут начинать работу с окном в 4 раза большим. К чему это приведет? Удастся ли организовать соединения?
В модельном исследовании [PN98] было рассмотрено влияние увеличенного начального окна на другой трафик, передаваемый в то же время. В этом исследовании потоки HTTP и FTP использовали общий загруженный шлюз (число одновременных потоков HTTP и FTP варьировалось). Для каждого набора параметров определялась агрегатная загрузка канала, частота отбрасывания пакетов, средняя задержка при загрузке web-страниц и скорость передачи FTP. Увеличение начального окна в общем случае повышало пропускную способность, незначительно увеличивало частоту потери пакетов и повышало общую производительность сети. За исключением одного сценария, увеличение размера начального окна повышало частоту потерь менее, чем на 1% по сравнению с оценкой для случая начального окна в 1 сегмент. Для упомянутого исключения частота потерь выросла от 3,5% для начального окна в 1 сегмент до 4,5% при 4-сегментном начальном окне. В результате дается заключение, что увеличение начального окна TCP до трех пакетов (или 4380 байтов) повышает воспринимаемую производительность.
Morris [Mor97] исследовал влияние увеличенного начального окна в сильно перегруженной сети, передавая блоки данных размером 20 Кбайт. Частота потерь в сетях, где все соединения TCP использовали 4-сегментное начальное окно, увеличивалась на 1-2% по сравнению с использованием начального окна в 1 сегмент. Это сохранялось для уровня загрузки, при котором частота потерь для 1-сегментного начального окна менялась от 1 до 11%. Кроме того, в сетях, где соединения использовали 4-сегментное начальное окно, соединения TCP тратили больше времени на ожидание тайм-аута повтора (RTO) для повторной передачи сегмента. Время ожидания тайм-аута RTO определяет период бездействия, когда через соединение не передается полезной информации. Эти результаты показывают, что в сильно загруженных средах, где доля каждого соединения в «узком месте» составляет около 1 сегмента, использование увеличенного начального окна может приводить к ощутимому росту частоты потерь и тайм-аутов повтора передачи.
8. Вопросы безопасности
В этом документе рассмотрено увеличение начального окна для соединений TCP, которое не усугубляет ни одной из известных проблем безопасности TCP.
9. Заключение
В этом документе предложено незначительное изменение протокола TCP, которое может обеспечить преимущества для краткосрочных соединений TCP, а также соединений, проходящих через каналы с большим временем кругового обхода RTT (обеспечивается экономия в несколько интервалов RTT для начальной фазы замедленного старта).
10. Благодарности
Авторы благодарны Vern Paxson, Tim Shepard, участникам почтовой рассылки End-to-End-Interest, а также членам рабочей группы IETF TCP Implementation за полезные дискуссии по затронутым в документе вопросам и отклики на этот документ.
11. Литература
[All97a] Mark Allman. An Evaluation of TCP with Larger Initial Windows. 40th IETF Meeting — TCP Implementations WG. December, 1997. Washington, DC.
[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of TCP with Larger Initial Windows, March 1998. Submitted to ACM Computer Communication Review. URL: “http://gigahertz.lerc.nasa.gov/~mallman/papers/initwin.ps“.
[All97b] Mark Allman. Improving TCP Performance Over Satellite Channels. Master’s thesis, Ohio University, June 1997.
[BLFN96] Berners-Lee, T., Fielding, R., and H. Nielsen, “Hypertext Transfer Protocol — HTTP/1.0”, RFC 1945, May 1996.
[Bra89] Braden, R., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, October 1989.
[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, 26(3), July 1996.
[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking. URL “http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html“.
[FJGFBL97] Fielding, R., Mogul, J., Gettys, J., Frystyk, H., and T. Berners-Lee, “Hypertext Transfer Protocol — HTTP/1.1”, RFC 2068, January 1997.
[FJ93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.
[Flo94] Floyd, S., TCP and Explicit Congestion Notification. Computer Communication Review, 24(5):10-23, October 1994.
[Flo96] Floyd, S., Issues of TCP with SACK. Technical report, January 1996. Available from http://www-nrg.ee.lbl.gov/floyd/.
[Flo97] Floyd, S., Increasing TCP’s Initial Window. Viewgraphs, 40th IETF Meeting – TCP Implementations WG. December, 1997. URL “ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps“.
[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. March 1998. Proceedings of the Sixth International Conference on Telecommunication Systems. URL “http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps“.
[MD90] Mogul, J., and S. Deering, “Path MTU Discovery”, RFC 1191, November 1990.
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, “TCP Selective Acknowledgment Options”, RFC 2018, October 1996.
[Mor97] Robert Morris. Частное сообщение, 1997. Указано лишь для подтверждения и благодарности.
[Nic97] Kathleen Nichols. Improving Network Simulation with Feedback. Com21, Inc. Technical Report. Available from http://www.com21.com/pages/papers/068.pdf.
[PN98] Poduri, K., and K. Nichols, “Simulation Studies of Increased Initial TCP Window Size”, RFC 2415, September 1998.
[Pos82] Postel, J., “Simple Mail Transfer Protocol”, STD 10, RFC 8217, August 1982.
[RF97] Ramakrishnan, K., and S. Floyd, “A Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP”, Work in Progress8.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, “Recommendations on Queue Management and Congestion Avoidance in the Internet”, RFC 2309, April 1998.
[S97] Stevens, W., “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms”, RFC 2001, January 1997.
[SP97] Shepard, T., and C. Partridge, “When TCP Starts Up With Four Packets Into Only Three Buffers”, RFC 2416, September 1998.
12. Адреса авторов
Mark Allman
NASA Lewis Research Center/Sterling Software
21000 Brookpark Road
MS 54-2
Cleveland, OH 44135
EMail: mallman@lerc.nasa.gov
http://gigahertz.lerc.nasa.gov/~mallman/
Sally Floyd
Lawrence Berkeley National Laboratory
One Cyclotron Road
Berkeley, CA 94720
EMail: floyd@ee.lbl.gov
Craig Partridge
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
EMail: craig@bbn.com
Перевод на русский язык
Николай Малых
13. Приложение — дубликаты сегментов
В современной среде (без явных уведомлений о перегрузке ECN9 [Flo94] [RF97]) все реализации TCP применяют отбрасывание сегментов в качестве индикации выхода за пределы доступной пропускной способности. Мы утверждаем здесь, что увеличение размера начального окна не приведет к большому числу дубликатов, уже принятых получателем, среди передаваемых отправителем повторных сегментов.
При отбрасывании сегмента из начального окна есть три способа восстановления для TCP: (1) замедленный старт с окном в один сегмент как после тайм-аута повторной передачи или ускоренного повтора (Fast Retransmit) в Tahoe TCP, (2) ускоренное восстановление (Fast Recovery) без селективных подтверждений (SACK) как после трех дубликатов ACK в Reno TCP и (3) ускоренное восстановление с SACK для TCP, где отправитель и получатель поддерживают опцию SACK [MMFR96]. Во всех трех случаях при отбрасывании одного сегмента из начального окна дубликаты сегментов (т. е., сегменты уже принятые получателем) не передаются. Отметим, что для TCP, передающего четыре сегмента по 512 байтов в начальном окне отбрасывание одного сегмента не требует тайм-аута повторной передачи и восстановление возможно с использованием алгоритма ускоренного повтора (Fast Retransmit), если таймер повтора передачи не завершил отсчет до этого. При отбрасывании одного сегмента из трехсегментного начального окна возможно восстановление с использованием алгоритма ускоренного повтора в зависимости от того, какой из сегментов был отброшен и использования отложенных подтверждений. Например, при отбрасывании первого из трех сегментов начального окна всегда требуется ожидание тайм-аута. Однако при отбрасывании третьего сегмента всегда возможно восстановление с помощью алгоритма ускоренного повтора, если не было потери пакетов ACK.
Далее рассмотрим сценарии с начальным окном 2 — 4 сегмента и отбрасыванием по крайней мере двух из этих сегментов. Если отбрасываются все сегменты начального окна, очевидно, что дубликатов сегментов не передается, поскольку получатель не принял еще ни одного сегмента. (По-прежнему сохраняется вероятность того, что эти отброшенные сегменты использовали дефицитную пропускную способность — этот вопрос рассмотрен в разделе 5.)
Когда отбрасывается 2 сегмента из 3-сегментного начального окна, отправитель будет передавать дубликат лишь в том случае, если отброшены два первых сегмента из трех и отправитель не получил пакета с опцией SACK, подтверждающего прием третьего сегмента.
Когда отбрасывается 2 сегмента из 4-сегментного начального окна, проверка шести возможных вариантов (которую мы здесь не делаем) показывает, что в зависимости от номеров отброшенных сегментов при отсутствии SACK отправитель может передать один дубликат уже принятого сегмента. Вариантов с передачей двух дубликатов не возникает.
При отбрасывании 3 сегментов из 4-сегментного начального окна в отсутствие SACK возможна передача одного сегмента-дубликата в зависимости от номеров отброшенных сегментов.
Вывод заключается в том, что при отсутствии SACK возможны варианты, когда отбрасывание нескольких сегментов из начального окна приводит к передаче одного сегмента-дубликата. Вариантов с передачей нескольких дубликатов не возникает. Наше заключение что число дубликатов, передаваемых в результате увеличения начального окна, будет невелико.
14. Полное заявление авторских прав
Copyright (C) The Internet Society (1998). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
1The maximum segment size.
2Round trip time.
3Don’t Fragment — не фрагментировать.
4«Отрубание хвостов».
5Hybrid fiber coax — сеть на основе оптических и коаксиальных линий связи.
6В оригинале ошибочно указано бит/с.
9Explicit Congestion Notification.
