Как медленный запуск TCP увеличивает пропускную способность?

Question

Медленный запуск TCP произошел в то время, когда Интернет начал испытывать "коллапс перегрузки". Необычный пример из статьи Ван Якобсона и Майкла Карелса гласит:

During this period, the data throughput from LBL to UC Berkeley (sites separated
by 400 yards and two IMP hops) dropped from 32 Kbps to 40 bps.

Проблема перегрузки часто описывается как вызванная переходом от высокоскоростного канала к медленному каналу и наращиванием / отбрасыванием пакетов в буфере в этом узком месте.
Я пытаюсь понять, как такое наращивание может вызвать снижение сквозной пропускной способности, а не просто вызывать избыточную активность / повторные передачи в высокоскоростной части канала, ведущей в полный буфер. В качестве примера рассмотрим следующую сеть:

    fast       slow       fast
A ======== B -------- C ======== D

A и D - конечные точки, а B и C - буферы пакетов при переходе от высокоскоростной сети к низкоскоростной. Так, например, соединение между A/B и C/D составляет 10 Мбит / с, а соединение между B/C - 56 Кбит / с. Теперь, если A передает большое (скажем, теоретически бесконечное) сообщение D, то я пытаюсь понять, почему ему понадобится больше времени, чтобы пройти через него, если он просто забивает TCP-соединение данными, а не адаптируется к более медленной скорости соединения в середине соединения. Я предполагаю, что B - это просто нечто, чей буфер истощается с фиксированной скоростью 56 Кбит / с, независимо от того, насколько сильно его буфер забивается A, и независимо от того, сколько пакетов он должен отбросить из-за полного буфера. Таким образом, если A всегда сохраняет буфер B заполненным (или переполненным, как может быть в случае), и B всегда передает со своей максимальной скоростью 56 Кбит / с, как будет улучшаться пропускная способность, если вместо этого использовать медленный запуск?

Единственное, о чем я мог подумать, было то, что те же самые пакеты D, которые уже были получены, должны были быть повторно переданы по медленной линии B/C в условиях перегрузки, и это блокировало новые пакеты. Но разве у D обычно не было ACK-пакетов, которые он получил, поэтому повторно передаваемые пакеты должны быть в основном теми, которые законно не были получены D, потому что они были отброшены в буфере B?

Answer 1

Помните, что сети предполагают совместное использование ресурсов несколькими компьютерами. Проще говоря, медленный запуск необходим, чтобы избежать исчерпания буфера маршрутизатора небольшим количеством сеансов TCP (на вашей диаграмме это наиболее вероятно в точках B и C)

Из RFC 2001, Раздел 1:

Старые протоколы TCP запускают соединение с отправителем, внедряющим в сеть несколько сегментов, вплоть до размера окна, объявленного получателем. Хотя это нормально, когда два хоста находятся в одной и той же локальной сети, если существуют маршрутизаторы и более медленные соединения между отправителем и получателем, могут возникнуть проблемы. Некоторый промежуточный маршрутизатор должен ставить пакеты в очередь, и для этого маршрутизатора может быть недостаточно свободного места. [2] показывает, как этот наивный подход может резко снизить пропускную способность TCP-соединения.

...

[2]  V. Jacobson, "Congestion Avoidance and Control," Computer
    Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
    ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

Маршрутизаторы должны иметь конечные буферы. Чем больше несоответствие скорости между ссылками, тем больше вероятность исчерпания буфера без медленного запуска. После исчерпания буфера средняя пропускная способность TCP снижается, поскольку буферизация увеличивает способность TCP использовать ссылки (предотвращая ненужные отбрасывания для мгновенного насыщения канала).

Обратите внимание, что RFC 2001 выше был заменен RFC 5681; однако RFC 2001 предлагает более цитируемый ответ на ваш вопрос.

Из вашего ОП...

Теперь, если A передает большое (скажем, теоретически бесконечное) сообщение D, то я пытаюсь понять, почему ему понадобится больше времени, чтобы пройти через него, если он просто забивает TCP-соединение данными, а не адаптируется к более медленной скорости соединения в середине соединения.

Во-первых, в TCP нет такого понятия, как бесконечное сообщение. TCP был ограничен начальным размером окна, прежде чем появился медленный запуск.

Итак, скажем, начальный сегмент TCP был длиной 64 КБ. Если весь сегмент TCP заполняет tx-буфер маршрутизатора в точке B, TCP использует меньшее количество канала с течением времени из-за динамики, связанной с потерей пакетов, ACK и откатом TCP. Давайте посмотрим на отдельные ситуации:

• Tx_buffer B < 64 КБ: вы автоматически потеряли время для повторных передач, потому что TCP A посылает быстрее, чем B может удалить пакеты из очереди
• Tx_buffer > B = 64 КБ: пока A является единственной передающей станцией, отрицательных эффектов нет (при условии, что D правильно выполняет ACK); однако, если есть несколько хостов, передающих по локальной сети A, пытающихся пройти через канал 56K, вероятно, есть проблемы, потому что требуется 200 миллисекунд для удаления одного 1500-байтового пакета на 56K. Если у вас есть 44 1500-байтовых пакета из начального окна A размером 64 КБ (44*1460=64 КБ; вы получаете только 1460 байтов полезной нагрузки TCP), маршрутизатор имеет насыщенную связь в течение почти 9 секунд, обрабатывающих трафик A.

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

Кстати, я никогда не видел маршрутизатор с 9-секундной буферизацией на интерфейсе. Ни один пользователь не потерпит такой задержки. Большинство маршрутизаторов имеют максимум 1-2 секунды, и это было много лет назад на скоростях T-1. По ряду причин буферы сегодня еще меньше.