Кратко

  • RFC 2416 моделировал 9600-бит/с модем и очередь на три пакета. В этой схеме четвёртый пакет четырёхпакетного старта неизбежно терялся.
  • Однако эксперимент не приравнивал эту локальную потерю к худшему результату соединения. Обычный медленный старт позже создавал сопоставимый всплеск, а обе трассы приходили почти к одинаковому состоянию восстановления — в разное время и на разных номерах пакетов.
  • После учёта времени передачи через модем четырёхпакетный вариант в большинстве случаев опережал базовый примерно на 0,229 секунды. Авторы ограничили вывод «именно этим случаем» и оставили открытыми поведение реальных устройств и безопасность сети в целом.
  • Исторический урок здесь — сравнивать полные трассы, включая потери у базового варианта, и не превращать один результат симулятора в универсальную гарантию.

Потеря была неизбежной; вывод — нет

Вопрос выглядел почти слишком простым: очередь вмещает три пакета, значит, четвёртому в ней не место. RFC 2416 не пытался обойти это ограничение. Авторы проверяли другое: окажется ли соединение с начальным окном в четыре пакета хуже обычного варианта, если проследить оба запуска через один и тот же узкий участок до восстановления.

Меморандум сентября 1998 года имел статус Informational, то есть не устанавливал стандарт. В модели источник передавал данные по каналу 100 Мбит/с без задержки, затем по каналу 1,5 Мбит/с с односторонней задержкой 25 мс и, наконец, через модемный канал 9600 бит/с с односторонней задержкой 150 мс. У маршрутизатора перед модемом было три пакетных буфера: один пакет передавался, ещё два могли ждать. Очереди на первых двух каналах не ограничивали эксперимент.

Для расчётов использовался симулятор NS 1.2a2 из Lawrence Berkeley National Laboratory. Сравнивались модули Tahoe, Reno, SACK и FACK; на иллюстрации показан Tahoe. Время передачи рассчитывалось для пакетов по 1024 байта. TCP-модули оперировали номерами пакетов и не моделировали механизм TCP sequence numbers. Наблюдения снимались у отправителя, на быстром канале без задержки. Эти решения делают эксперимент понятным, но одновременно очерчивают границу его доказательств.

Базовый вариант тоже дошёл до потери

При обычном медленном старте отправитель сначала посылает пакет 1. Подтверждение, пришедшее через 1,222 секунды, разрешает передачу пакетов 2 и 3; следующее важное подтверждение, в момент 2,444 секунды, открывает отправку пакетов 4 и 5. В 3,278 секунды подтверждение пакета 3 позволяет отправить пакеты 6 и 7. Позже теряется пакет 7, а его повторная передача начинается в 8,278 секунды после третьего дублирующего подтверждения.

Четырёхпакетный запуск сразу отправляет пакеты с 1-го по 4-й. Четвёртый теряется, потому что очередь на три пакета уже заполнена. Третье дублирующее подтверждение приходит через 5,389 секунды и вызывает повторную передачу. В этот момент трассы оказываются почти в одном состоянии восстановления. Дальше они почти совпадают после сдвига на 2,889 секунды и три номера пакетов.

Такое сравнение меняет постановку вопроса. Обычный медленный старт не избегает четырёхпакетного всплеска навсегда: окно постепенно растёт и позднее приводит к похожей нагрузке. Потеря при четырёхпакетном старте реальна, но реальна и более поздняя потеря пакета 7 в базовом варианте. Если смотреть лишь на первый отброшенный пакет, сравнение будет охватывать разные фрагменты двух запусков.

Что именно измеряли 0,229 секунды

Разница во времени между почти одинаковыми состояниями восстановления составляла 2,889 секунды. Передача трёх сегментов по 1024 байта через модем, согласно меморандуму, занимала 2,66 секунды. После вычета оставалось преимущество примерно в 0,229 секунды в большинстве случаев. Авторы объясняли его тем, что модем простаивал, пока вариант с одним пакетом ждал таймер задержки подтверждения у получателя. Из-за потери разных пакетов одни случаи завершались раньше, другие — позже; 0,229 секунды не были обещанием для каждого запуска.

Это свидетельство о смоделированном соединении, а не доказательство безопасности более крупного начального окна на любом маршруте. Сам меморандум оставлял открытым вопрос о безопасности такого старта для сети и предлагал повторить опыт на реальных реализациях TCP, модемах и ограничениях в три буфера. Симуляция делала предполагаемую локальную потерю неизбежной, но не могла определить внешние издержки для других потоков в общей сети.

Идеи Хэна Лу Running-Code Primacy и Reality Layers здесь служат аналитическими линзами, а не исторической атрибуцией. Running-Code Primacy ставит трассы пакетов и подтверждений выше интуитивных ожиданий, но требует ограничивать вывод проверенным кодом и маршрутом. Reality Layers помогает не смешивать потерю в очереди, время завершения одного соединения и устойчивость сети. RFC 2416 даёт материал для первых двух уровней в рамках модели и прямо не разрешает третий вопрос.

Источники