Кратко

  • Высокий goodput без потерь не доказывает, что узкий обратный путь сохраняет временную структуру ACK и сигналы, необходимые для быстрого восстановления.
  • Фильтрация, приоритет, реконструкция и pacing могут улучшить один показатель, одновременно изменив burst, fairness, безопасность или происхождение evidence; итог требует цепочки независимых квитанций.

Испытание отправляло большой поток только вниз. Обратный канал почти не имел посторонней нагрузки, потери не вводились, а завершение приложения заменили счётчиком транспортных байтов. Результат оказался отличным.

Он был точным для созданного сценария и бесполезным для более важного вопроса: что произойдёт, когда upload займёт очередь, ACK начнут теряться или сжиматься, а прямой пакет потребует быстрого recovery?

RFC 3449 вышел в декабре 2002 года как BCP 69. Это исторический обзор асимметричных путей, а не современный benchmark. Его главный вклад — дисциплина границ: прямую скорость нельзя выдавать за доказательство всей feedback loop.

Пропускная способность — лишь один участок контура

Кумулятивный ACK сообщает sender, до какого sequence point дошёл receiver TCP. Он открывает send window, влияет на congestion-window growth и несёт duplicate/SACK evidence для loss recovery. Он не подтверждает, что приложение сохранило или использовало данные.

При self-clocking прямой bottleneck задаёт интервалы data, receiver возвращает ACK, а их приход разрешает новые пакеты. Узкий обратный путь может стать настоящими часами широкого downstream.

Поэтому тестовая спецификация обязана называть оба маршрута, capacity, стоимость packet event, cross traffic, queue discipline, buffer и ACK policy. Иначе она проверяет трубу, а не доставку.

Без потерь нельзя проверить восстановление

В мелкой reverse queue ACK отбрасываются. Более поздний cumulative ACK способен подтвердить все предыдущие bytes, и итоговый счётчик сойдётся. Но duplicate ACK или SACK, нужные для Fast Retransmit и Fast Recovery, могут не дойти.

Редкие ACK также замедляют реализацию, растущую по числу подтверждений, или освобождают сразу большой объём данных. Одна и та же потеря feedback даёт медленный growth и крупный burst.

Тест без controlled loss не отличит своевременное recovery от ожидания timeout. Зелёный goodput в чистом канале не является квитанцией поведения при повреждении.

Глубокая очередь скрывает ограничитель

В глубоком reverse buffer ACK не падают, а ждут. Они выходят реже, чем были созданы: ACK dilation. Sender тактируется обратным bottleneck, downstream простаивает без прямой потери, RTT растёт.

Средний round-trip delay показывает симптом, но не место. Нужны временные точки receiver emission, до и после bottleneck и sender reception. Только тогда видно, что ограничителем был ACK service.

В примере RFC 3449 прямой канал 10 Mbps, обратный 50 Kbps, data packet 1 000 bytes, ACK 40 bytes; нормализованное k = 8. Это иллюстрация, не измерение действующего оператора.

Двусторонняя нагрузка меняет форму ACK

Большие upload-пакеты могут задерживать маленькие ACK. После ожидания группа выходит вместе и приходит к sender плотнее, чем была создана. Это ACK compression.

Sender отвечает concentrated data burst, который способен переполнить прямую queue. Средний downstream utilisation до этого мог быть низким. Причина прямой потери при этом возникла в расписании обратного направления.

Однонаправленный benchmark исключает именно этот механизм. Нужны смешанная нагрузка, inter-ACK на нескольких точках, распределение burst и последующая loss/recovery.

Оптимизация должна проверяться за пределами своего счётчика

ACK Filtering удаляет избыточные cumulative ACK до bottleneck. Он экономит обратные пакеты, но surviving stretch ACK разрешают больше data. RFC 3449 обозначил метод experimental и потребовал burst mitigation.

ACK Decimation выбирает сообщения грубее с помощью queue/drop policy и может сильнее повредить recovery evidence. Общее увеличение delayed-ACK factor не было рекомендовано. Большой MSS без router fragmentation был recommended при подходящем PMTU; создание фрагментации — нет.

Уменьшение ACK rate в отчёте может означать улучшение, активное удаление, receiver policy или потерю. Без provenance это не метрика причины.

Сглаженный график может быть синтетическим

ACK Reconstruction вставляет после bottleneck новые ACK на основе soft state. Они не являются свежими наблюдениями receiver. RFC 3449 классифицировал подход как not recommended и отметил amplification risk при инъекции подходящих stretch ACK.

Если реконструктор участвует в тесте, следует записывать его identity, input, state lifetime, rate bounds и generated messages. Иначе хороший clock смешивает endpoint evidence с работой посредника.

Sender Pacing меняет другое: распределяет уже разрешённую отправку во времени. Он не создаёт ACK, но требует rate prediction и был experimental. Улучшившийся queue graph доказывает изменение actuation, не улучшение обратной доставки.

Приоритет создаёт невидимого проигравшего

ACKs-first scheduling сокращает feedback delay, но без ограничения ACK volume способен вызвать starvation upload data. Поэтому RFC 3449 не рекомендовал его как общую интернет-политику. Fair queuing лучше разделяет flows, хотя результат зависит от workload.

Header compression, filtering и reconstruction часто требуют видеть или менять TCP header. Шифрование и integrity protection могут убрать такую власть. Это не провал защиты, а архитектурная граница, которую тест обязан учитывать.

Успех download не компенсирует провал upload, loss recovery или security contract.

Матрица приёмки вместо одной скорости

Первая квитанция — оба маршрута и период наблюдения. Далее идут directional capacity, MAC event cost, cross traffic, queue policy и buffer depth. Затем ACK policy и исходный timing receiver.

Loss, filtering, decimation, compression, reconstruction и scheduling получают отдельную attribution. На sender сохраняются inter-ACK, cumulative progress, duplicate/SACK, cwnd, pacing и burst distribution.

Прямая loss/recovery — отдельный сценарий. Goodput связывается с offered load и fairness. Authenticated application completion и user-visible result идут после transport. Rollback и alternate path проверяют причинность.

Тест считается полным не тогда, когда все клетки зелёные, а когда каждая заявленная граница имеет наблюдаемый результат и владельца.

Граница доказательства

RFC 3449 не доказывает текущее поведение конкретного access network, satellite, radio, cable, TCP stack или congestion controller. k = 8 — механизм. Поздние TCP RFC меняют динамику, но не устраняют ACK и recovery evidence.

Принципы Heng Lu о минимальной начальной спецификации и приоритете running code — заявленные редакционные линзы. Они поддерживают ограниченные и локально доказанные изменения, но не поставляют deployment facts.

Источники