Кратко

  • RFC 1016 предложил SQuID: исходный IP-модуль хранит для недавно посещённых адресатов задержку D между датаграммами. Обычное D равно нулю; запись нужна только для направлений с положительной задержкой.
  • В параметрах примера первое предупреждение устанавливает не менее 75 мс, следующее событие прибавляет 20 мс, сообщения за две секунды сводятся к одному событию, а при наличии данных к отправке D уменьшается на 1 мс после каждой подходящей секунды. Авторы проверяли поведение в модели, написанной на C.

Быстрая локальная сеть способна наполнить очередь шлюза быстрее, чем узкая линия освободит место. W. Prue и Jon Postel в RFC 1016 приводили болезненно простой расчёт: если перед линией 56 кбит/с скопился мегабайт данных, последняя датаграмма ждёт отправки больше двух минут. При нехватке буфера шлюз мог отбросить датаграмму и послать источнику ICMP Source Quench — просьбу сбавить темп до указанного адресата. В сообщении было направление проблемы. Сколько ждать между новыми отправками, источник должен был решить сам.

Ответ авторы назвали SQuID, Source Quench Introduced Delay. Модуль IP исходного хоста вводил D — интервал между датаграммами к одному получателю. Обычно D было нулём. Хост хранил записи только для недавно посещённых адресатов с ненулевой задержкой. Пока одно направление ждало, пакет к другому мог уйти. Очередь одного шлюза не превращалась в карантин для всей исходящей почты машины.

Алгоритм быстро увеличивал паузу и осторожно сокращал её. При событии Source Quench D становилось большим из двух значений: прежнее D плюс 20 миллисекунд либо минимум 75 миллисекунд. Одно или несколько предупреждений в течение двух секунд считались одним событием. Если шлюз отправлял целую пачку сигналов, источник не должен был растягивать паузу после каждого из них. Через подходящую секунду после прошлого уменьшения, когда имелись данные к отправке, D снижалось на одну миллисекунду, не уходя ниже нуля. Простой без отправок сам по себе задержку не списывал.

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

Шлюзу тоже досталась программа действий. В иллюстративных порогах RFC очередь при 70% заполнения начинала посылать предупреждения, продолжая пересылать вызвавшую сигнал датаграмму. При 95% начиналось отбрасывание данных. Сигналы продолжались, пока заполнение не опускалось ниже 50%. Ранний сигнал давал источнику время изменить следующие отправки, а нижний порог удерживал реакцию до заметной разгрузки. Шлюз видел свою очередь; источник контролировал время выхода будущих пакетов.

Чтобы увидеть взаимодействие этой схемы с TCP, Prue и Postel написали на C модель сети. Между двумя локальными участками по 10 Мбит/с находилась линия 56 кбит/с. Модель содержала очереди, датаграммы по 512 байтов и фиксированные маршруты; фрагментацию и TTL в ней не моделировали. Все исследованные алгоритмы колебались. Медленное увеличение D и быстрое сокращение слишком долго удерживали отправителя выше возможностей сети, вызывая потери. Более сильное увеличение, медленное возвращение и объединение короткой серии сигналов выглядели в модели удачнее.

Одна сцена показывает, насколько беспощадна разница скоростей. В условиях RFC двадцать датаграмм TCP приходили к шлюзу за 81 миллисекунду. Следующий участок пропускал примерно одну за 73 миллисекунды. При выбранной ёмкости очереди номера 17–20 терялись в каждом полном окне. Окно TCP разрешало выпустить двадцать штук, но шлюз не располагал местом для такого единовременного наплыва. Секундомер на источнике должен был распределить отправку ещё до узкого прохода.

RFC отмечал и разрыв внутри хоста: многие реализации TCP не получали чётко определённого события Source Quench от IP и ICMP. Ответ на уровне исходного IP позволял непосредственно менять график датаграмм. Результаты модели указывали, что предупреждение до потери могло улучшить эффективную передачу. Для оценки за пределами модели потребовались бы измерения в действующей сети с переменным трафиком. Исторически любопытнее само распределение труда: шлюз умеет сказать «тесно», отправитель умеет поставить паузу перед следующим пакетом.