О документе
Рабочая группа по сетям H. Balakrishnan
Запрос комментариев: 3449 MIT LCS
BCP: 69 V. N. Padmanabhan
Категория: Лучшая современная практика Microsoft Research
G. Fairhurst
M. Sooriyabandara
University of Aberdeen, U.K.
Декабрь 2002
Влияние асимметрии сетевого пути
на производительность TCP
1. Условные обозначения, используемые в этом документе
ПРЯМОЕ НАПРАВЛЕНИЕ: Преобладающее направление передачи данных по
асимметричному сетевому пути. Оно соответствует направлению с лучшими
характеристиками с точки зрения пропускной способности, задержки,
частоты ошибок и т. д. Передача данных в прямом направлении называется
«прямой передачей». Пакеты, движущиеся в прямом направлении, следуют по
прямому пути через IP-сеть.
ОБРАТНОЕ НАПРАВЛЕНИЕ: Направление, в котором передаются подтверждения
прямой TCP-передачи. Передача данных также может происходить в этом
направлении (и называется «обратной передачей»), но обычно ее объем
меньше, чем в прямом направлении. Обратное направление обычно обладает
худшими характеристиками, чем прямое направление. Пакеты, движущиеся в
обратном направлении, следуют по обратному пути через IP-сеть.
ВОСХОДЯЩИЙ КАНАЛ: Конкретный канал — узкое место, который обычно имеет
значительно меньшую пропускную способность, чем соответствующий
нисходящий канал. Перегрузка не ограничивается только этим каналом и
также может возникать в любой точке прямого и обратного направлений
(например, вследствие совместного использования с другими потоками
трафика).
НИСХОДЯЩИЙ КАНАЛ: Канал на прямом пути, соответствующий восходящему
каналу.
ACK: Накопительное TCP-подтверждение [RFC791]. В этом документе этот
термин обозначает сегмент TCP, который несет накопительное
подтверждение (ACK), но не данные.
КОЭФФИЦИЕНТ ОТЛОЖЕННОГО ACK, d: Число сегментов данных TCP, на которые
отправляется одно TCP ACK. Минимальное значение d равно 1, поскольку
для каждого пакета данных следует (should) отправлять не более одного
ACK [RFC1122, RFC2581].
РАСТЯНУТОЕ ACK: Растянутые ACK — это подтверждения, охватывающие более
2 сегментов ранее неподтвержденных данных (d>2) [RFC2581]. Растянутые
ACK могут возникать намеренно (хотя это не является стандартом),
вследствие ошибок реализации [All97b, RFC2525] либо вследствие потери
ACK [RFC2760].
НОРМАЛИЗОВАННОЕ ОТНОШЕНИЕ ПРОПУСКНОЙ СПОСОБНОСТИ, k: Отношение
номинальной («raw») пропускной способности (ёмкости) прямого
направления к обратному направлению, деленное на отношение размеров
пакетов, используемых в двух направлениях [LMS97].
МЯГКОЕ СОСТОЯНИЕ: Состояние для каждого потока, установленное в
сетевом устройстве и используемое протоколом [Cla88]. Состояние истекает
по прошествии некоторого времени (то есть его не требуется явно удалять
после завершения сеанса) и непрерывно обновляется, пока поток
продолжается (то есть утраченное состояние может быть реконструировано
без необходимости обмена дополнительными управляющими сообщениями).
2. Мотивация
Асимметричные характеристики демонстрируют несколько сетевых
технологий, включая кабельные сети передачи данных (например, сети
кабельного телевидения DOCSIS [DS00, DS01]), спутниковое прямое вещание
(например, IP-служба, использующая Digital Video Broadcast, DVB,
[EN97] с интерактивным обратным каналом), спутниковые терминалы Very
Small Aperture (VSAT), Asymmetric Digital Subscriber Line (ADSL)
[ITU02, ANS01] и несколько сетей пакетной радиосвязи. Эти сети все чаще
развертываются как высокоскоростные сети доступа в Интернет, поэтому
крайне желательно обеспечить хорошую производительность TCP. Однако
асимметрия сетевых путей часто усложняет эту задачу. Примеры некоторых
сетей, демонстрирующих асимметрию, приведены в Приложении.
Асимметрия может проявляться как различие в пропускной способности
передачи и приема, дисбаланс частоты потерь пакетов или различия между
путями передачи и приема [RFC3077]. Например, когда пропускная
способность асимметрична, так что на обратном пути, используемом TCP
ACK, пропускная способность снижена, медленная или редкая обратная
связь ACK ухудшает производительность TCP в прямом направлении.
Аналогично, асимметрия в базовых протоколах управления доступом к среде
(MAC) и физического уровня (PHY) может делать передачу TCP ACK дорогой
(несоразмерно их размеру), даже если пропускная способность симметрична.
2.1 Асимметрия вследствие различий в пропускной способности передачи и приема
Сетевые пути могут быть асимметричными, поскольку восходящий и
нисходящий каналы работают на разных скоростях и/или реализованы с
применением разных технологий.
Асимметрия пропускной способности может существенно возрастать, когда
IP-потоки с обслуживанием по мере возможности, переносящие TCP ACK,
совместно используют доступную пропускную способность восходящего
канала с другими потоками трафика, например телефонией, особенно с
потоками, для которых зарезервирована пропускная способность восходящего
канала. Это включает гарантии обслуживания на IP-уровне (например,
Guaranteed Service [RFC2212]) или на уровне подсети (например, поддержку
Voice over IP [ITU01] с использованием службы Unsolicited Grant в
DOCSIS [DS01] либо виртуальных соединений CBR в ATM поверх ADSL
[ITU02, ANS01]).
При наличии нескольких восходящих каналов асимметрия может быть снижена
разделением восходящего трафика между несколькими доступными восходящими
каналами.
2.2 Асимметрия вследствие совместно используемой среды в обратном направлении
В сетях, использующих централизованное управление множественным
доступом, асимметрия может быть фундаментальным следствием архитектуры
сети «звезда с лучами» (то есть один базовый узел взаимодействует с
несколькими нисходящими узлами). Центральный узел часто несет меньшие
накладные расходы передачи и не испытывает задержки при планировании
собственных нисходящих передач. Напротив, восходящая передача подвержена
дополнительным накладным расходам и задержке (например, вследствие
защитных интервалов между всплесками передачи и интервалов конкуренции).
Это может создавать значительную асимметрию сетевого пути.
Пропускная способность восходящего канала может быть дополнительно
ограничена требованием, согласно которому каждый узел должен сначала
запрашивать пропускную способность для каждого пакета с использованием
конкурентного MAC-протокола (например, DOCSIS 1.0 ограничивает каждый
узел отправкой не более одного пакета в каждом восходящем интервале
временного разделения [DS00]). Спутниковая сеть, использующая
динамическую пропускную способность по требованию (BoD), также
потребляет ресурсы MAC для каждого отправленного пакета (например,
[EN00]). В этих схемах доступная пропускная способность восходящего
канала является функцией алгоритма MAC. Схемы MAC и PHY также вносят
накладные расходы на каждую восходящую передачу, которые могут быть
настолько значительными, что передача коротких пакетов (включая TCP ACK)
становится столь же дорогостоящей, как передача пакетов данных размера
MTU.
2.3 Общая проблема
Несмотря на технологические различия между асимметриями, зависящими от
пропускной способности, и асимметриями, зависящими от MAC, оба вида
сетевых путей страдают от снижения производительности TCP по одной и
той же фундаментальной причине: несовершенства и изменчивости обратной
связи ACK. В этом документе проблема подробно обсуждается и описываются
несколько методов, которые могут уменьшить или устранить ограничения.
3. Как асимметрия ухудшает производительность TCP?
В этом разделе описываются последствия асимметрии сетевого пути для
производительности TCP. За дополнительными сведениями и
экспериментальными результатами читатель отсылается к [BPK99, Bal98,
Pad98, FSS01, Sam99].
3.1 Асимметричная пропускная способность
Проблемы, ухудшающие производительность однонаправленной передачи, когда
прямой и обратный пути имеют очень разную пропускную способность, зависят
от характеристик восходящего канала. Для однонаправленного трафика по
таким сетевым путям возникают два типа ситуаций: когда восходящий канал
— узкое место имеет достаточную очередь, чтобы предотвратить потери
пакетов (ACK), и когда восходящий канал — узкое место имеет небольшой
буфер. Каждая из них рассматривается по очереди.
Если восходящее узкое звено имеет глубокие очереди, так что ACK в обратном направлении не отбрасываются, производительность сильно зависит от нормализованного отношения пропускных способностей k. Например, для нисходящего звена 10 Mbps и восходящего звена 50 Kbps исходное отношение пропускных способностей равно 200. При пакетах данных размером 1000 байт и ACK размером 40 байт отношение размеров пакетов равно 25. Это означает, что k равно 200/25 = 8. Следовательно, если получатель подтверждает чаще, чем одним ACK на каждые 8 (k) пакетов данных, восходящее звено станет насыщенным раньше нисходящего звена, ограничивая пропускную способность в прямом направлении. Следует отметить, что достигнутая пропускная способность TCP определяется минимумом из рекламируемого получателем окна или окна перегрузки TCP, cwnd [RFC2581].
Если ACK не отбрасываются (на восходящем узком звене) и k > 1 либо k > 0.5 при использовании отложенных ACK [RFC1122], тактирование TCP по ACK нарушается. Рассмотрим два пакета данных, переданных отправителем быстро один за другим. По пути к получателю эти пакеты разделяются во времени в соответствии с пропускной способностью наименьшего узкого звена в прямом направлении. Принцип тактирования по ACK состоит в том, что ACK, сформированные в ответ на получение этих пакетов данных, отражают это временное разнесение на всём пути обратно к отправителю, позволяя ему передавать новые пакеты данных с тем же разнесением [Jac88]. Тактирование по ACK с отложенными ACK отражает разнесение между пакетами данных, которые фактически вызывают ACK. Однако ограниченная восходящая пропускная способность и постановка в очередь на маршрутизаторе восходящего узкого звена изменяют интервалы между ACK на обратном пути и, следовательно, интервалы, наблюдаемые отправителем. Когда ACK поступают на восходящее узкое звено с большей скоростью, чем это звено способно поддерживать, они выстраиваются в очередь друг за другом. Интервалы между ними при выходе из звена увеличиваются относительно исходных интервалов и зависят от пропускной способности восходящего узкого звена. Поэтому отправитель TCP выдаёт новые пакеты данных с меньшей скоростью, чем при отсутствии очереди ACK. Производительность соединения больше не зависит только от нисходящего узкого звена; вместо этого она ограничивается скоростью поступления ACK. Побочным эффектом также является замедление скорости роста cwnd у отправителя.
Второй побочный эффект возникает, когда восходящее узкое звено на обратном пути насыщено. Насыщенное звено вызывает постоянное нахождение пакетов в очереди, что ведёт к увеличению времени прохождения туда и обратно (RTT) [RFC2998], наблюдаемого всеми конечными хостами, использующими узкое звено. Это может влиять на контуры управления протокола, а также вызывать ложное срабатывание тайм-аута (недооценку RTT пути отправляющим хостом).
Иная ситуация возникает, когда восходящее узкое звено имеет сравнительно небольшой объём буферного пространства для размещения ACK. По мере роста окна передачи эта очередь заполняется, и ACK отбрасываются. Если бы получатель подтверждал каждый пакет, до отправителя доходил бы лишь один ACK из каждых k
ACK, а остальные (k-1) отбрасывались бы вследствие переполнения буфера восходящего звена (здесь k — то же нормализованное отношение пропускных способностей, что и ранее). В этом случае пропускная способность обратного узкого звена и медленная скорость поступления ACK непосредственно не ответственны за ухудшение производительности. Однако редкость ACK приводит к трём причинам ухудшения производительности:
1. Отправитель передаёт данные большими пачками пакетов, ограниченными только доступным cwnd. Если отправитель получает лишь один ACK из k, он передаёт данные пачками из k (или более) пакетов, поскольку каждый ACK сдвигает скользящее окно как минимум на k подтверждённых пакетов данных (сегментов данных TCP). Это повышает вероятность потери пакетов данных на прямом пути, особенно при большом k, поскольку маршрутизаторы плохо обрабатывают большие пачки пакетов.
2. Текущие реализации отправителя TCP увеличивают cwnd, подсчитывая число получаемых ACK, а не объём данных, фактически подтверждённых каждым ACK. Последний подход, также известный как подсчёт байтов (раздел 4.7), является стандартным вариантом реализации увеличения cwnd в период предотвращения перегрузки [RFC2581]. Поэтому меньшее число ACK означает более медленный рост cwnd, что ухудшает производительность соединений с большой задержкой.
3. Алгоритмы Fast Retransmission и Fast Recovery TCP отправителя [RFC2581] менее эффективны при потере ACK. Отправитель может не получить пороговое число дублирующих ACK, даже если получатель передаёт больше порогового значения DupACK (> 3 DupACK) [RFC2581]. Кроме того, отправитель может не получить достаточно дублирующих ACK для адекватного увеличения cwnd во время Fast Recovery.
3.2 Взаимодействие с протоколами MAC
Взаимодействие TCP с протоколами MAC может ухудшать сквозную производительность. Основные признаки этой проблемы — переменные задержки прохождения туда и обратно и постановка ACK в очередь.
Один из примеров — влияние на наземные беспроводные сети [Bal98]. Значительные накладные расходы на каждый пакет могут возникать из-за необходимости узлам звена связи сначала синхронизироваться (например, посредством протокола Ready To Send / Clear to Send (RTS/CTS)) перед обменом и из-за значительного времени разворота беспроводного канала. Эти накладные расходы переменны, поскольку обмен RTS/CTS может требовать экспоненциальной отсрочки повторной попытки, когда удалённый узел занят (например, ведёт обмен с другим узлом). Это приводит к большим и переменным задержкам связи в пакетных радиосетях.
Асимметричная нагрузка (больше нисходящего, чем восходящего трафика) может приводить к постановке ACK в очередь в некоторых беспроводных узлах (особенно в модемах конечных хостов), усугубляя переменную задержку. Постановка в очередь также может происходить в других совместно используемых средах, например в восходящих каналах кабельных модемов, системах доступа BoD, часто применяемых на совместно используемых спутниковых каналах.
Переменная задержка и постановка ACK в очередь уменьшают плавность потока данных TCP. В частности, трафик ACK может мешать потоку пакетов данных, увеличивая нагрузку на систему.
TCP измеряет RTT пути и на его основе вычисляет сглаженную оценку RTT (srtt) и линейное отклонение rttvar. Они используются для оценки тайм-аута повторной передачи по пути (RTO) [RFC2988], устанавливаемого равным srtt + 4*rttvar. Для большинства проводных TCP-соединений srtt остаётся постоянным либо имеет малое линейное отклонение. Поэтому RTO отслеживает RTT пути, и отправитель TCP оперативно реагирует, когда в одном окне происходят множественные потери. Напротив, некоторые беспроводные сети характеризуются высокой изменчивостью RTT, вызывающей существенное увеличение RTO (например, порядка 10 секунд). Пути, проходящие через несколько беспроводных переходов, особенно подвержены этому эффекту, поскольку повышается вероятность того, что промежуточные узлы уже ведут обмен с другими узлами. Накладные расходы в большинстве схем MAC зависят и от числа, и от размера пакетов. Однако проблема конкуренции за MAC в значительной мере зависит от числа передаваемых пакетов (например, ACK), а не от их размера. Иными словами, передача пакета имеет существенную стоимость независимо от размера пакета.
Эксперименты, проведённые в пакетной радиосети Ricochet в 1996 и 1997 годах, продемонстрировали влияние разворотов радиоканала и соответствующего увеличения изменчивости RTT, приводящее к ухудшению производительности TCP. Для TCP-соединений нередки были тайм-ауты продолжительностью 9–12 секунд, вследствие чего многие соединения бездействовали значительную часть своего срока существования (например, иногда 35% общего времени передачи). Это приводит к недоиспользованию доступной пропускной способности. Эти эффекты могут также возникать в других беспроводных подсетях.
3.3 Двунаправленный трафик
Двунаправленный трафик возникает при одновременных передачах TCP в прямом и обратном направлениях по асимметричному сетевому пути, например когда пользователь отправляет сообщение электронной почты в обратном направлении, одновременно получая веб-страницу в прямом направлении. Для упрощения обсуждения рассматривается только одно TCP-соединение в каждом направлении. Во многих практических случаях нескольким одновременным соединениям необходимо совместно использовать доступную пропускную способность, повышая уровень перегрузки.
Двунаправленный трафик делает эффекты, рассмотренные в разделе 3.1, более выраженными, поскольку часть пропускной способности восходящего звена потребляется обратной передачей. Это фактически повышает степень асимметрии пропускной способности. Другие эффекты также возникают из-за взаимодействия пакетов данных обратной передачи и ACK прямой передачи. Предположим, что к моменту инициирования прямого TCP-соединения обратное TCP-соединение уже насытило узкое восходящее звено пакетами данных. Тогда существует высокая вероятность того, что многие ACK нового прямого TCP-соединения встретят заполненный буфер восходящего звена и потому будут отброшены. Даже после этих первоначальных проблем ACK прямого соединения могут ожидать в очереди за большими пакетами данных обратного соединения. Большие пакеты данных могут иметь соответственно длительное время передачи (например, передача пакета данных размером 1 Kbyte по линии 28.8 kbps занимает около 280 ms). Это вызывает остановку прямой передачи на длительные периоды. Только когда обратное соединение теряет пакеты (из-за переполнения буфера на промежуточном маршрутизаторе) и замедляется, прямое соединение получает возможность быстро продвинуться и нарастить свой cwnd.
Когда ACK ожидают в очереди за другим трафиком заметные промежутки времени, пачечный характер трафика TCP и эффекты самосинхронизации могут приводить к эффекту, известному как ACK Compression [ZSC91], который снижает пропускную способность TCP. Он возникает, когда серия ACK в одном направлении ожидает в очереди за пачкой других пакетов (например, пакетов данных, следующих в том же направлении) и сжимается во времени. Это приводит к интенсивной пачке пакетов данных в другом направлении в ответ на пачку сжатых ACK, поступающих на сервер. Это явление подробно исследовано для двунаправленного трафика; недавняя аналитическая работа [LMS97] предсказала, что ACK Compression может также быть следствием двунаправленной передачи при асимметрии, и оно наблюдалось в практически используемых асимметричных спутниковых подсетях [FSS01]. В случае крайней асимметрии (k>>1) интервалы между ACK могут увеличиваться из-за постановки в очередь (раздел 3.1), что приводит к растяжению ACK.
Итак, совместное использование восходящего узкого звена множественными потоками (например, IP-потоками к одному конечному хосту либо потоками к нескольким конечным хостам, совместно использующим общее восходящее звено) повышает уровень перегрузки ACK. Наличие двунаправленного трафика усугубляет ограничения, вносимые асимметрией пропускной способности, вследствие неблагоприятного взаимодействия (больших) пакетов данных соединения обратного направления и ACK соединения прямого направления.
3.4 Потери на асимметричных сетевых путях
Потери могут происходить как в прямом, так и в обратном направлении. Для передачи данных в прямом направлении это соответственно приводит к потере пакетов данных и пакетов ACK. Потеря ACK менее существенна, чем потеря пакетов данных, поскольку обычно приводит к растянутым ACK [CR98, FSS01].
В случае путей с большой задержкой медленное восходящее звено [RFC3150] может привести к ещё одному осложнению, когда конечный хост использует большие окна TCP [RFC1323] для максимизации пропускной способности в прямом направлении. Потеря пакетов данных на прямом пути вследствие перегрузки или потерь на звене, обычных для некоторых беспроводных звеньев, сформирует большое число последовательных дублирующих ACK (либо пакетов TCP SACK [RFC2018]) для каждого корректно полученного пакета данных, следующего за потерей. Отправитель TCP использует Fast Retransmission и Recovery [RFC2581] для восстановления после потери, но, даже если это успешно, ACK для повторно переданного сегмента данных может быть значительно задержан другими дублирующими ACK, всё ещё находящимися в очереди буфера восходящего звена. В конечном итоге это может привести к тайм-ауту [RFC2988] и преждевременному завершению TCP Slow Start [RFC2581]. Это приводит к низкой пропускной способности прямого пути. В разделе 5.3 описаны некоторые меры противодействия этому.
4. Улучшение производительности TCP с использованием мер на хосте
Для улучшения производительности TCP в асимметричных сетях необходимо решить две ключевые проблемы. Первая состоит в управлении пропускной способностью восходящего узкого звена, используемого ACK и, возможно, другим трафиком. Существует ряд методов, работающих за счёт уменьшения числа ACK, проходящих в обратном направлении. Их побочным эффектом может стать разрушение желательного свойства самотактирования отправителя TCP, при котором передача новых пакетов данных запускается входящими ACK. Поэтому вторая проблема состоит в том, чтобы избежать любого неблагоприятного влияния редких ACK.
Каждая из этих проблем может быть устранена решениями локального канального уровня и/или сквозными методами. В этом разделе рассматриваются сквозные модификации. Некоторые методы требуют изменений TCP-приёмника (разделы 4.1, 4.4, 4.5), некоторые требуют изменений TCP-отправителя (разделы 4.6, 4.7), а пара требует изменений как TCP-отправителя, так и TCP-приёмника (разделы 4.2, 4.3). Один метод требует модификации отправителя на принимающем хосте (раздел 4.8). Методы могут использоваться независимо, однако некоторые наборы методов являются взаимодополняющими, например pacing (раздел 4.6) и подсчёт байтов (раздел 4.7), которые были объединены в единую схему TCP Sender Adaptation [BPK99].
Обычно предполагается, что эти изменения будут выполняться на конечных хостах, использующих асимметричный путь, однако они могли и фактически применялись в промежуточном устройстве (middle-box) или Protocol Enhancing Proxy (PEP) [RFC3135], использующем split TCP. В настоящем документе не рассматриваются вопросы, касающиеся PEP. В разделе 4 описывается несколько методов, не требующих сквозных изменений.
4.1 Модифицированные отложенные ACK
Существуют два стандартных метода, которые TCP-приёмники могут использовать для формирования подтверждений. Метод, изложенный в [RFC793], формирует ACK для каждого входящего сегмента данных (то есть d=1). В [RFC1122] указано, что хостам следует использовать «отложенные подтверждения». При использовании этого алгоритма ACK формируется как минимум для каждого второго полноразмерного сегмента (d=2), либо если второй полноразмерный сегмент не поступает в течение заданного тайм-аута (который не должен превышать 500 мс [RFC1122] и обычно составляет менее 200 мс). Ослабление последнего ограничения (то есть допущение d>2) может формировать Stretch ACK [RFC2760]. Это обеспечивает возможную меру смягчения, снижающую частоту возврата ACK приёмником. Реализатору следует отклоняться от этого требования только после тщательного рассмотрения последствий [RFC2581].
Уменьшение числа ACK на полученный сегмент данных имеет ряд нежелательных последствий, включая:
(i) увеличение RTT пути
(ii) увеличение времени, необходимого TCP для открытия cwnd
(iii) увеличение размера всплеска TCP-отправителя, поскольку cwnd открывается более крупными шагами
Кроме того, TCP-приёмник часто не способен определить оптимальную настройку для большого d, поскольку обычно он не знает подробностей свойств каналов, образующих путь в обратном направлении.
РЕКОМЕНДАЦИЯ: TCP-приёмник должен использовать стандартный алгоритм TCP для отправки ACK, определённый в [RFC2581]. То есть он может задерживать отправку ACK после получения сегмента данных [RFC1122]. Если ACK задерживаются, приёмник должен сформировать ACK в течение 500 мс, и ACK следует формировать как минимум для каждого второго полноразмерного сегмента (MSS) полученных данных [RFC2581]. В результате коэффициент задержки ACK (d) не превышает значения 2. Изменение алгоритма потребовало бы модификации TCP-приёмника хоста и осведомлённости принимающего хоста о том, что он использует соединение с асимметричным путём. Такое изменение имеет множество недостатков в общем случае и в настоящее время не рекомендуется для использования в Интернете.
4.2 Использование большого MSS
TCP-отправитель, использующий большой Maximum Segment Size (MSS), уменьшает число ACK, формируемых на каждый переданный байт данных.
Хотя отдельные подсети могут поддерживать большой MTU, большинство современных каналов Интернета используют MTU приблизительно 1500 байт (как у Ethernet). Установив бит Don't Fragment (DF) в заголовке IP, можно использовать обнаружение Path MTU (PMTU) [RFC1191] для определения максимального размера пакета (и, следовательно, MSS), который отправитель может использовать на заданном сетевом пути, не подвергаясь IP-фрагментации; оно также предоставляет способ автоматически выбрать подходящий MSS для конкретного пути. Это также гарантирует, что маршрутизаторы не будут выполнять IP-фрагментацию обычных пакетов данных.
Решив не использовать обнаружение PMTU, конечный хост может выбрать использование IP-фрагментации маршрутизаторами вдоль пути в прямом направлении [RFC793]. Это допускает MSS, превышающий наименьший MTU вдоль пути. Однако при этом единица восстановления после ошибок (сегмент TCP) становится больше единицы передачи (пакета IP). Это не рекомендуется, поскольку может увеличить число повторно передаваемых пакетов после потери одного пакета IP, снижая эффективность и потенциально усугубляя перегрузку сети [Ken87]. Выбор MSS, превышающего минимальный MTU прямого пути, также позволяет отправителю передавать больше начальных пакетов (всплеск фрагментов IP для каждого сегмента TCP) при запуске сеанса или после истечения RTO, повышая агрессивность отправителя по сравнению со стандартным TCP [RFC2581]. Это может неблагоприятно повлиять на другие сеансы стандартного TCP, совместно использующие сетевой путь.
РЕКОМЕНДАЦИЯ:
Больший MTU прямого пути желателен для путей с асимметрией пропускной способности. Поставщики сети могут использовать большой MTU на каналах в прямом направлении. Конечные TCP-хосты, использующие обнаружение Path MTU, могут быть способны воспользоваться большим MTU, автоматически выбирая подходящий больший MSS без необходимости модификации. Поэтому рекомендуется использование обнаружения Path MTU [RFC1191].
Увеличение единицы восстановления после ошибок и управления перегрузкой (MSS) сверх единицы передачи и потерь при перегрузке (пакета IP) посредством использования большего MSS конечного хоста и IP-фрагментации в маршрутизаторах не рекомендуется.
4.3 Управление перегрузкой ACK
ACK Congestion Control (ACC) — экспериментальный метод, работающий сквозным образом. ACC распространяет управление перегрузкой на ACK, поскольку они могут предъявлять немалые требования к ресурсам (например, буферам пакетов и накладным расходам передачи MAC) на восходящем узком канале. Он состоит из двух частей: (a) сетевого механизма, указывающего приёмнику, что путь ACK перегружен, и (b) реакции приёмника на такое указание.
Маршрутизатор, подающий трафик на восходящий узкий канал, может обнаруживать зарождающуюся перегрузку, например с помощью алгоритма, основанного на RED (Random Early Detection) [FJ93]. Такой алгоритм может отслеживать средний размер очереди на временном окне недавнего прошлого. Если среднее значение превышает порог, маршрутизатор может выбрать пакет случайным образом. Если в IP-заголовке пакета установлен бит Explicit Congestion Notification Capable Transport (ECT), маршрутизатор может пометить пакет, то есть установить бит(ы) Explicit Congestion Notification (ECN) [RFC3168] в IP-заголовке; в противном случае пакет обычно отбрасывается. Уведомление ECN, полученное конечным хостом, возвращается конечному TCP-хосту-отправителю, чтобы инициировать предотвращение перегрузки [RFC3168]. Следует отметить, что маршрутизаторы, реализующие RED с ECN, не устраняют потерю пакетов и могут отбросить пакет (даже когда установлен бит ECT). Также для решения, когда устанавливать бит ECN, возможно использовать алгоритм, отличный от RED.
ACC расширяет ECN таким образом, что и пакеты данных TCP, и ACK имеют установленный бит ECT и поэтому являются кандидатами на пометку битом ECN. Поэтому после получения ACK с установленным битом ECN [RFC3168] TCP-приёмник уменьшает частоту отправки ACK. Он поддерживает динамически изменяемый коэффициент отложенных ACK, d, и отправляет один ACK на каждые d полученных пакетов данных. Когда он получает пакет с установленным битом ECN, он мультипликативно увеличивает d, тем самым мультипликативно уменьшая частоту ACK. Для каждого последующего RTT (например, определяемого с помощью опции TCP RTTM [RFC1323]), в течение которого он не получает ECN, он линейно уменьшает коэффициент d, увеличивая частоту ACK. Таким образом, приёмник имитирует стандартное поведение управления перегрузкой TCP-отправителей способом, которым он отправляет ACK.
Максимальное значение d определяется размером окна TCP-отправителя, который мог бы передаваться приёмнику в новой (экспериментальной) опции TCP. Приёмнику следует отправлять как минимум один ACK (предпочтительно больше) для каждого окна данных от отправителя (то есть d < (cwnd/mss)), чтобы не допустить остановки отправителя до тех пор, пока таймер отложенных ACK приёмника не инициирует отправку ACK.
РЕКОМЕНДАЦИЯ: ACK Congestion Control (ACC) — экспериментальный метод, требующий модификаций TCP-отправителя и приёмника. В настоящее время опыт использования таких методов в Интернете невелик. Будущие версии TCP могут развиться так, чтобы включать этот или сходные методы. Они являются предметом продолжающихся исследований. ACC не рекомендуется для использования в Интернете в его текущей форме.
4.4 Механизм прогнозирования окна
Window Prediction Mechanism (WPM) — механизм на стороне TCP-приёмника [CLP98], использующий динамический коэффициент задержки ACK (изменяющийся d), аналогичный схеме ACC (раздел 4.3). TCP-приёмник воссоздаёт поведение управления перегрузкой TCP-отправителя путём прогнозирования значения cwnd. Это значение используется вместе с допустимым окном для корректировки значения d приёмника. WPM учитывает избыточные повторные передачи, возникающие из-за потерь вследствие ошибок канала.
РЕКОМЕНДАЦИЯ: Window Prediction Mechanism (WPM) — экспериментальная модификация на стороне TCP-приёмника. В настоящее время опыт использования таких методов в Интернете невелик. Будущие версии TCP могут развиться так, чтобы включать этот или сходные методы. Они являются предметами продолжающихся исследований. WPM не рекомендуется для использования в Интернете в его текущей форме.
4.5 Подтверждение на основе оценки Cwnd.
Acknowledgement based on Cwnd Estimation (ACE) [MJW00] пытается измерить cwnd на TCP-приёмнике и поддерживать изменяющийся коэффициент задержки ACK (d). cwnd оценивается путём подсчёта числа пакетов, полученных за RTT пути. Этот метод может повысить точность прогнозирования подходящего cwnd.
РЕКОМЕНДАЦИЯ: Acknowledgement based on Cwnd Estimation (ACE) — экспериментальная модификация на стороне TCP-приёмника. В настоящее время опыт использования таких методов в Интернете невелик. Будущие версии TCP могут развиться так, чтобы включать этот или сходные методы. Они являются предметом продолжающихся исследований. ACE не рекомендуется для использования в Интернете в его текущей форме.
4.6 Pacing TCP-отправителя
Уменьшение частоты ACK может ослабить перегрузку восходящего узкого канала, однако может привести к увеличению размера всплесков TCP-отправителя (раздел 4.1). Это может замедлить рост cwnd и нежелательно при использовании на совместно используемых сетевых путях, поскольку может существенно увеличить максимальное число пакетов в буфере узкого канала, потенциально приводя к увеличению перегрузки сети. Это также может привести к ACK Compression [ZSC91].
TCP Pacing [AST00], обычно называемый TCP Sender pacing, использует адаптированный TCP-отправитель для ослабления всплескового характера передачи. Устанавливается граница максимального числа пакетов, которые TCP-отправитель может передать подряд (с локальной линейной скоростью), даже если окно (окна) допускает передачу большего объёма данных. При необходимости дополнительные всплески пакетов данных планируются на более поздние моменты времени, вычисляемые на основе скорости передачи TCP-соединения. Скорость передачи может оцениваться по отношению cwnd/srtt. Таким образом, большие всплески пакетов данных разбиваются на меньшие всплески, распределённые во времени.
Подсеть также может предоставлять pacing (например, Generic Traffic Shaping (GTS)), однако это подразумевает существенное увеличение накладных расходов на обработку каждого пакета и требований к буферу в маршрутизаторе, где выполняется формирование трафика (раздел 5.3.3).
РЕКОМЕНДАЦИИ: TCP Sender Pacing требует изменения реализации TCP-отправителя. Он может быть полезен в Интернете и существенно уменьшит размер всплеска пакетов, передаваемых хостом. Это успешно смягчает влияние получения Stretch ACK. TCP Sender Pacing подразумевает увеличение стоимости обработки на пакет и требует алгоритма прогнозирования, предлагающего подходящую скорость передачи. Следовательно, существуют компромиссы производительности между стоимостью конечного хоста и производительностью сети. Спецификация эффективных алгоритмов остаётся областью продолжающихся исследований. Ожидается, что использование TCP Sender Pacing не создаст новых проблем. Это экспериментальная мера смягчения для TCP-хостов, которые могут управлять всплесковым характером передачи (например, возникающим вследствие методов типа 1, раздел 5.1.2), однако в настоящее время она не имеет широкого развёртывания. Она не рекомендуется для использования в Интернете в её текущей форме.
4.7 TCP Byte Counting
Отправитель TCP может избежать замедления роста cwnd, учитывая объём данных, подтверждённых каждым ACK, а не увеличивая cwnd на основе числа полученных ACK. Таким образом, если ACK подтверждает d пакетов данных (или сегментов данных TCP), cwnd будет увеличиваться так, как если бы были получены d отдельных ACK. Это называется TCP Byte Counting [RFC2581, RFC2760]. (Можно было бы рассматривать один ACK как эквивалент d/2, а не d ACK, чтобы имитировать эффект алгоритма отложенных ACK TCP.) Эта политика работает, поскольку рост cwnd связан только с доступной пропускной способностью в прямом направлении, поэтому число ACK несущественно.
Это может смягчить влияние асимметрии при использовании в сочетании с другими методами (например, сочетания TCP Pacing (раздел 4.6) и ACC (раздел 4.3), связанного с порогом дублирующихся ACK на стороне получателя).
Основная проблема состоит в том, что подсчёт байтов TCP может порождать нежелательные длинные всплески пакетов TCP со скоростью линии хоста-отправителя. Реализация также должна учитывать, что пакеты данных в прямом направлении и ACK в обратном направлении могут проходить по сетевым путям, на которых в некоторой степени происходит переупорядочивание пакетов. Переупорядочивание IP-пакетов в настоящее время распространено и может возникать по различным причинам [BPS00].
РЕКОМЕНДАЦИЯ: TCP Byte Counting требует небольшого изменения отправителя TCP. В своей простейшей форме он может порождать большие всплески пакетов данных TCP, особенно при получении Stretch ACK. Поэтому неограниченный подсчёт байтов не допускается [RFC2581] для использования в Интернете.
Поэтому настоятельно рекомендуется [RFC2581, RFC2760], чтобы любая схема подсчёта байтов включала метод смягчения потенциально больших всплесков пакетов данных TCP, которые может вызвать алгоритм (например, TCP Sender Pacing (раздел 4.6), ABC [abc-ID]). Если можно управлять размером всплеска или скоростью отправки отправителя TCP, схема может быть полезной при получении Stretch ACK. Определение безопасных алгоритмов остаётся областью продолжающихся исследований. Затем потребуются дальнейшие эксперименты для оценки успешности этих защитных мер, прежде чем их можно будет рекомендовать для использования в Интернете.
4.8 Обратное давление
Обратное давление — это метод повышения производительности двунаправленного трафика для конечных хостов, непосредственно подключённых к восходящему узкому звену [KVR98]. Устанавливается ограничение на количество пакетов данных восходящих передач, которые могут быть поставлены в очередь на восходящем узком звене. Иными словами, очередь узкого звена оказывает «обратное давление» на уровень TCP (отправителя). Для этого требуется изменённая реализация по сравнению с той, которая в настоящее время развёрнута во многих стеках TCP. Обратное давление обеспечивает, что ACK нисходящих соединений не остаются без обслуживания на восходящем узком звене, тем самым повышая производительность нисходящих соединений. Аналогичные общие схемы, которые могут быть реализованы в хостах/маршрутизаторах, обсуждаются в разделе 5.4.
Обратное давление может быть несправедливым к соединению в обратном направлении и делать его пропускную способность сильно чувствительной к динамике соединения (соединений) в прямом направлении.
РЕКОМЕНДАЦИЯ: Обратное давление требует экспериментального изменения стека протоколов отправителя хоста, непосредственно подключённого к восходящему узкому звену. Использование обратного давления является вопросом реализации, а не вопросом сетевого протокола. Там, где реализовано обратное давление, оптимизации, описанные в этом разделе, могут быть желательны и могут приносить пользу двунаправленному трафику для хостов.
Определение безопасных алгоритмов для обеспечения обратного давления всё ещё является предметом продолжающихся исследований. Этот метод не рекомендуется для использования в Интернете в его текущей форме.
5. Улучшение производительности TCP с использованием прозрачных модификаций
Для смягчения эффекта восходящего узкого звена были предложены различные методы канального и сетевого уровней. Эти методы могут приносить пользу без модификации ни отправителя, ни получателя TCP, либо, альтернативно, могут использоваться совместно с одной или несколькими схемами, определёнными в разделе 4. В настоящем документе эти методы называются «прозрачными» [RFC3135], поскольку на транспортном уровне отправитель и получатель TCP не обязательно осведомлены об их существовании. Это не подразумевает, что они не изменяют структуру и время передачи пакетов, наблюдаемые на сетевом уровне. Здесь методы классифицируются на три типа в зависимости от точки, в которой они вводятся.
Большинство методов требуют отдельной идентификации отдельных TCP-соединений, проходящих через узкое звено (узкие звенья), и подразумевают хранение некоторого состояния для каждого потока активных TCP-соединений. Также может применяться планировщик канала (раздел 5.4). Методы (за одним исключением — ACK Decimation (раздел 5.2.2)) требуют:
(i) видимости незашифрованного заголовка пакета IP и TCP (например, без
использования IPSec с шифрованием полезной нагрузки [RFC2406]).
(ii) знания опций IP/TCP и способности инспектировать пакеты с туннельной
инкапсуляцией (например, [RFC2784]) либо приостанавливать обработку
пакетов с неизвестными форматами.
(iii) способности демультиплексировать потоки (с использованием адреса/
протокола/номера порта либо явного flow-id).
[RFC3135] описывает класс сетевых устройств, которые обеспечивают нечто большее, чем пересылка пакетов, и которые известны как Protocol Enhancing Proxy (PEP). Существует широкий спектр устройств PEP: от простых устройств (например, фильтрации ACK) до более сложных устройств (например, устройств с сохранением состояния, которые разделяют TCP-соединение на две отдельные части). Методы, описанные в разделе 5 настоящего документа, принадлежат к более простому типу и не инспектируют и не изменяют какие-либо данные полезной нагрузки TCP или UDP. Они также не изменяют номера портов или адреса канального уровня. Многие риски, связанные с более сложными PEP, не существуют для этих схем. Дополнительная информация о работе и рисках, связанных с использованием PEP, описана в [RFC3135].
5.1 ТИП 0: Сжатие заголовков
Клиент может уменьшить объём битов, используемых для отправки одного ACK, посредством сжатия [RFC3150, RFC3135]. Большинство современных модемов коммутируемого доступа поддерживают блочное сжатие ITU-T V.42. В отличие от блочного сжатия, сжатие заголовков, как известно, очень эффективно уменьшает число битов, отправляемых по восходящей линии [RFC1144]. Оно основывается на наблюдении, что большинство заголовков пакетов TCP между последовательными пакетами потока различаются лишь в нескольких битовых позициях и что эти различия часто можно предсказать.
5.1.1 Сжатие заголовков TCP
Сжатие заголовков TCP [RFC1144] (иногда называемое V-J compression) — это Proposed Standard, описывающий использование на линиях малой пропускной способности, работающих с SLIP или PPP [RFC3150]. Оно значительно уменьшает размер ACK на обратной линии, когда потери происходят нечасто (ситуация, обеспечивающая синхронизацию состояния компрессора и декомпрессора). Однако само по себе это не решает все проблемы асимметрии:
(i) В некоторых подсетях (например, беспроводных) имеются значительные
накладные расходы MAC на каждый пакет, не зависящие от размера пакета
(раздел 3.2).
(ii) Уменьшение размера ACK не предотвращает неблагоприятное взаимодействие
с большими восходящими пакетами данных при наличии двунаправленного
трафика (раздел 3.3).
(iii) Сжатие заголовков TCP нельзя использовать с пакетами, содержащими опции
IP или TCP (включая IPSec [RFC2402, RFC2406], TCP RTTM [RFC1323], TCP
SACK [RFC2018] и т. д.).
(iv) Производительность сжатия заголовков, описанного RFC1144, значительно
ухудшается при потере сжатых пакетов. Улучшение, которое всё ещё может
приводить к существенному снижению производительности на длинных
сетевых путях, описано в [RFC2507]. Это указывает на то, что его следует
использовать только на линиях (или путях) с низким уровнем потерь
пакетов [RFC3150].
(v) Обычная реализация Header Compression подавляет сжатие, когда IP
используется для поддержки туннелирования (например, L2TP, GRE
[RFC2794], IP-in-IP). Туннельная инкапсуляция осложняет нахождение
подходящих заголовков пакетов. Хотя GRE допускает Header Compression
внутреннего (туннелированного) заголовка IP [RFC2784], это не
рекомендуется, поскольку потеря пакета (например, из-за перегрузки
маршрутизатора вдоль пути туннеля) приведёт к отбрасыванию всех пакетов
в течение одного RTT [RFC1144].
РЕКОМЕНДАЦИЯ: TCP Header Compression — это прозрачная модификация, выполняемая на обоих концах восходящего узкого звена. Она не даёт пользы потокам, использующим IPSec [RFC2402, RFC2406], или когда присутствуют дополнительные заголовки протоколов (например, опции IP или TCP,
и/или заголовки туннельной инкапсуляции). Эта схема широко реализована, развёрнута и используется на линиях Интернета. Она рекомендуется для улучшения производительности TCP на путях с низкой или средней асимметрией пропускной способности (например, k<10).
В форме, описанной в [RFC1144], производительность TCP ухудшается при использовании на линиях (или путях), которые могут демонстрировать заметные уровни потерь пакетов [RFC3150]. Она также может не обеспечивать значительного улучшения для восходящих линий с двунаправленным трафиком. Поэтому она нежелательна для путей с высокой асимметрией пропускной способности (например, k>10).
5.1.2 Альтернативные устойчивые алгоритмы сжатия заголовков
Сжатие заголовков TCP [RFC1144] и сжатие заголовков IP [RFC2507] плохо работают при потерях пакетов. Кроме того, они не сжимают пакеты с полями опций TCP (например, SACK [RFC2018] и Timestamp (RTTM) [RFC1323]). Однако недавняя работа над более устойчивыми схемами предполагает, что может быть разработано новое поколение алгоритмов сжатия, намного более устойчивых. Рабочая группа IETF ROHC определила методы сжатия для трафика на основе UDP [RFC3095] и рассматривает ряд схем, которые могут улучшить сжатие заголовков TCP. Они могут быть полезны для асимметричных сетевых путей.
РЕКОМЕНДАЦИЯ: Устойчивое сжатие заголовков — это прозрачная модификация, которая может выполняться на обоих концах восходящего узкого звена. Этот класс методов также может подходить для путей Интернета, на которых наблюдаются низкие уровни переупорядочивания. Методы приносят пользу путям с низкой или средней асимметрией пропускной способности (например, k>10) и могут быть устойчивы к потерям пакетов.
Выбор подходящих алгоритмов сжатия остаётся областью продолжающихся исследований. Возможно, будут выведены схемы, поддерживающие аутентификацию IPSec, но не шифрование полезной нагрузки IPSec. Такие схемы сами по себе не обеспечивают значительного улучшения в асимметричных сетях с высокой асимметрией и/или двунаправленным трафиком.
5.2 ТИП 1: Управление пропускной способностью обратной линии
Для решения проблем производительности, вызываемых заметной асимметрией (k>>1), требуются методы помимо сжатия заголовков Типа 0. Один набор методов реализуется только в одной точке пути обратного направления — внутри маршрутизатора/хоста, подключённого к восходящему узкому звену. Они используют класс потока или очереди для каждого потока на интерфейсе восходящей линии для управления очередью пакетов, ожидающих передачи по узкой восходящей линии.
Этот тип методов ограничивает размер очереди буфера восходящей линии и использует алгоритм для удаления (отбрасывания) избыточных ACK из каждой очереди. Он опирается на кумулятивную природу ACK (раздел 4.1). Описываются два подхода, использующие этот тип смягчения.
5.2.1 Фильтрация ACK
ACK Filtering (AF) [DMT96, BPK99] (также известная как ACK Suppression [SF98, Sam99, FSS01]) — это учитывающий TCP метод канального уровня, который уменьшает число ACK, отправляемых по восходящей линии. Этот метод был развёрнут в конкретных производственных сетях (например, в асимметричных спутниковых сетях [ASB96]). Задача состоит в том, чтобы гарантировать, что отправитель не остановится в ожидании ACK, что может произойти при неизбирательном удалении ACK.
Когда ACK от получателя должен быть поставлен в очередь на интерфейсе восходящего узкого звена, маршрутизатор или канальный уровень конечного хоста (если хост непосредственно подключён к восходящему узкому звену) проверяет очередь (очереди) передачи на наличие более старых ACK, принадлежащих тому же TCP-соединению. Если ACK найдены, некоторые (или все они) удаляются из очереди, уменьшая число ACK.
Некоторые ACK также выполняют в TCP другие функции [RFC1144], и их не следует удалять, чтобы обеспечить нормальную работу. Поэтому AF не следует удалять ACK, содержащий какие-либо данные или имеющий установленные TCP-флаги (SYN, RST, URG и FIN). Кроме того, ему следует избегать удаления из очереди серии из 3 дублирующих ACK, указывающих на необходимость Fast Retransmission [RFC2581], или ACK с опцией Selective ACK (SACK)[RFC2018], чтобы не вызвать проблем для механизмов восстановления TCP после потерь, управляемых данными. Также необходима надлежащая обработка для сохранения корректной работы обратной связи ECN (передаваемой в заголовке TCP) [RFC3168].
Может использоваться ряд политик для фильтрации ACK. Они могут быть как детерминированными, так и случайными (аналогично шлюзу со случайным отбрасыванием, но следует учитывать семантику элементов в очереди). Также были предложены алгоритмы для обеспечения минимальной частоты ACK, гарантирующей обновление окна отправителя TCP [Sam99, FSS01], и для ограничения числа пакетов данных (TCP-сегментов), подтверждаемых одним Stretch ACK. Состояние для каждого потока необходимо поддерживать только для соединений, имеющих хотя бы один пакет в очереди (аналогично FRED [LM97]). Это состояние является мягким [Cla88] и при необходимости может быть легко восстановлено по содержимому очереди.
Нежелательный эффект задержанных DupACK (раздел 3.4) может быть уменьшен удалением дублирующих ACK сверх порогового значения [MJW00, CLP98], что допускает Fast Retransmission, но предотвращает ранние тайм-ауты TCP, которые иначе могут возникнуть вследствие чрезмерной постановки DupACK в очередь.
В будущих схемах могут использоваться более развитые правила, допускающие удаление выбранных SACK [RFC2018]. Такая схема могла бы предотвратить заполнение очереди восходящего канала следующими непосредственно друг за другом ACK с блоками SACK. Поскольку пакет SACK значительно больше ACK, иначе он существенно увеличивал бы задержку пути в обратном направлении. Выбор подходящих алгоритмов остаётся текущей областью исследований.
РЕКОМЕНДАЦИЯ: ACK Filtering требует изменения интерфейса восходящего канала. Эта схема развёрнута в некоторых сетях, где дополнительные накладные расходы на обработку (на ACK) могут компенсироваться отсутствием необходимости изменять TCP. ACK Filtering может порождать Stretch ACK, приводящие к большим всплескам пакетов данных TCP. Поэтому сама по себе она не рекомендуется для использования в общем Интернете.
ACK Filtering при использовании совместно со схемой для смягчения эффекта Stretch ACK (то есть для управления размером всплеска отправителя TCP) рекомендуется для путей со значительной асимметрией (k>1) и/или с двунаправленным трафиком. Подходящие алгоритмы для поддержки аутентификации IPSec, SACK и ECN остаются областями текущих исследований.
5.2.2 Прореживание ACK
ACK Decimation основано на стандартных механизмах маршрутизатора. Используя соответствующую конфигурацию (малых) очередей для каждого потока и выбранную политику отбрасывания (например, Weighted Fair Queuing, WFQ) на восходящем канале-узком месте, можно получить эффект, аналогичный AF (раздел 5.2.1), но с меньшим контролем над фактически отбрасываемыми пакетами.
В этой схеме маршрутизатор/хост на восходящем канале-узком месте поддерживает очереди для каждого потока и справедливо обслуживает их (или обслуживает с приоритетами), ставя в очередь и планируя ACK и пакеты данных в обратном направлении. Для отбрасывания избыточных ACK с хвоста каждой очереди поддерживается малый порог очереди, чтобы уменьшить ACK Congestion. Невозможность идентифицировать специальные пакеты ACK (ср. с AF) вносит в этот подход несколько существенных недостатков, таких как возможность потери DupACK, FIN/ACK, пакетов RST или пакетов, несущих информацию ECN [RFC3168]. Потеря этих пакетов не оказывает существенного влияния на перегрузку сети, но неблагоприятно влияет на производительность TCP-сеанса, в котором произошла потеря.
Планировщик WFQ может назначить более высокий приоритет интерактивному трафику (при наличии механизма для идентификации такого трафика) и выделить справедливую долю оставшейся ёмкости массовому трафику. При наличии двунаправленного трафика и при подходящей политике планирования это может обеспечить более справедливое распределение для ACK и пакетов данных. Повышенная скорость передачи в прямом направлении достигается на асимметричных каналах
за счёт повышенной скорости ACK Decimation, что приводит к созданию Stretch ACK. Как и в AF, размер всплеска отправителя TCP увеличивается при получении Stretch ACK, если совместно с этой техникой не используются другие методы.
Эта техника была развёрнута в определённых сетях (например, в сети с высокой асимметрией пропускной способности, поддерживающей высокоскоростные службы передачи данных для мобильных хостов в пути [Seg00]). Хотя она не оптимальна, она предлагала возможное смягчение, применимое, когда заголовок TCP трудно идентифицировать или он не виден канальному уровню (например, из-за шифрования IPSec).
РЕКОМЕНДАЦИЯ: ACK Decimation использует стандартные механизмы маршрутизатора на интерфейсе восходящего канала, чтобы ограничить скорость, с которой ACK подаются на восходящий канал. Эта техника полезна для путей, имеющих значительную асимметрию (k>1). Однако она неоптимальна, поскольку может привести к неэффективному восстановлению TCP после ошибок (а следовательно, в некоторых случаях к ухудшению производительности TCP) и обеспечивает лишь грубое управление поведением канала. Поэтому рекомендуется, чтобы там, где это возможно, ACK Filtering использовалась предпочтительно по отношению к ACK Decimation.
Когда ACK Decimation используется на путях со значительной асимметрией (k>1) (или с двунаправленным трафиком), она увеличивает размер всплеска отправителя TCP; поэтому настоятельно рекомендуется использовать схему для смягчения эффекта Stretch ACK или управления всплескообразностью.
5.3 ТИП 2: Обработка редких ACK
Меры смягчения ТИПА 2 выполняют управление пропускной способностью восходящего канала ТИПА 1, но также используют второй активный элемент, смягчающий эффект пониженной частоты ACK и всплескообразности передачи ACK. Это желательно, когда конечные хосты используют стандартные реализации отправителя TCP (например, не реализующие техники из разделов 4.6, 4.7).
Рассмотрим путь, в котором схема ТИПА 1 пересылает Stretch ACK, охватывающий d пакетов TCP (то есть номер подтверждения на d*MSS больше, чем у последнего ACK, полученного отправителем TCP). Когда отправитель TCP получает этот ACK, он может отправить всплеск из d (или d+1) пакетов данных TCP. Отправитель также ограничен текущим cwnd. Полученные ACK также служат для увеличения cwnd (не более чем на один MSS).
Схема ТИПА 2 смягчает влияние пониженной частоты ACK, возникающей при использовании схемы ТИПА 1. Это достигается вставкой дополнительных ACK перед каждым полученным Stretch ACK. Дополнительные ACK вместе с исходным ACK предоставляют отправителю TCP достаточно ACK, чтобы позволить TCP cwnd открываться таким же образом, как если бы каждый исходный ACK, отправленный получателем TCP, был переслан обратным путём. Кроме того, пытаясь восстановить
интервалы между ACK, такая схема может также восстановить поведение самотактирования TCP и уменьшить размер всплеска отправителя TCP. Такие схемы должны обеспечивать консервативное поведение (то есть не следует вводить больше ACK, чем было отправлено изначально) и уменьшать вероятность ACK Compression [ZSC91].
Действие выполняется в двух точках обратного пути: на интерфейсе восходящего канала (где удаляются избыточные ACK) и в точке далее по обратному пути (после восходящего канала-узкого места), где вставляются замещающие ACK. Это пытается реконструировать поток ACK, отправленный получателем TCP, при использовании совместно с AF (раздел 5.2.1) или ACK Decimation (раздел 5.2.2).
Меры смягчения ТИПА 2 могут выполняться локально на интерфейсе приёма непосредственно после восходящего канала-узкого места либо, альтернативно, применяться в любой точке далее по обратному пути (это не обязательно прямой путь, поскольку асимметричная маршрутизация может использовать разные прямой и обратный интернет-пути). Поскольку эти техники могут порождать несколько ACK при приёме каждого отдельного Stretch ACK, настоятельно рекомендуется, чтобы расширитель реализовывал схему предотвращения использования в качестве «усилителя пакетов» при атаке типа Denial-of-Service (DoS) (например, для проверки отправителя ACK). Идентификация отправителя может быть выполнена с помощью надлежащим образом настроенных пакетных фильтров и/или процедур аутентификации туннеля (например, [RFC2402, RFC2406]). Также может быть желательным ограничение числа реконструированных ACK, которые могут быть сгенерированы из одного пакета.
5.3.1 Реконструкция ACK
ACK Reconstruction (AR) [BPK99] используется совместно с AF (раздел 5.2.1). AR развёртывает на обратном пути после восходящего канала-узкого места агента с мягким состоянием [Cla88], называемого ACK Reconstructor. Мягкое состояние может быть восстановлено при его потере на основе полученных ACK. При получении Stretch ACK AR вводит дополнительные ACK, заполняя промежутки в последовательности ACK. Могут возникать некоторые потенциальные уязвимости Denial-of-Service (раздел 6), и их необходимо устранить с помощью надлежащих техник безопасности.
Reconstructor определяет число дополнительных ACK, оценивая число отфильтрованных ACK. Для этого используется неявная информация, присутствующая в полученном потоке ACK, посредством наблюдения за номером последовательности ACK каждого полученного ACK. Пример реализации может установить порог ACK, ackthresh, равным удвоенному MSS (предполагается, что выбранный MSS известен каналу). Коэффициент два соответствует стандартной политике TCP delayed-ACK (d=2). Таким образом, если последовательные ACK прибывают с интервалом delta, Reconstructor восстанавливает максимум ((delta/ackthresh) - 2) ACK.
Чтобы уменьшить размер всплеска отправителя TCP и позволить cwnd увеличиваться со скоростью, определяемой нисходящим каналом, реконструированные ACK должны отправляться с постоянной скоростью (то есть с временными интервалами между реконструированными ACK). Один из методов состоит в том, чтобы Reconstructor измерял скорость поступления ACK, используя оценщик экспоненциально взвешенного скользящего среднего. Эта скорость зависит от выходной скорости восходящего канала и от наличия другого трафика, совместно использующего канал. Выход оценщика указывает средний временной интервал для ACK (и среднюю скорость, с которой ACK достигли бы отправителя TCP, если бы не было дальнейших потерь или задержек). Это может использоваться Reconstructor для задания временных интервалов между реконструированными ACK. Схема также может использоваться совместно с адаптацией отправителя TCP (например, с сочетанием техник из разделов 4.6 и 4.7).
Компромисс в AR состоит в выборе между меньшей всплескообразностью отправителя TCP и лучшей скоростью увеличения cwnd с уменьшением вариации RTT, с одной стороны, и умеренным увеличением RTT пути — с другой. Эта техника не может выполнять реконструкцию для соединений, использующих IPSec (AH [RFC2402] или ESP [RFC2406]), поскольку она не способна генерировать надлежащую информацию безопасности. Она также не может восстанавливать другую информацию заголовка пакета (например, точный шаблон битов, передаваемый в поле ECN IP-пакета [RFC3168], или опцию TCP RTTM [RFC1323]).
ACK Reconstructor работает корректно (то есть не генерирует ложных ACK и сохраняет сквозную семантику TCP) при условии, что:
(i) получатель TCP использует ACK Delay (d=2) [RFC2581]
(ii) Reconstructor получает только ACK по порядку
(iii) все ACK маршрутизируются через Reconstructor
(iv) Reconstructor корректно определяет TCP MSS, используемый
сеансом
(v) пакеты не содержат дополнительной информации заголовка (например,
опцию TCP RTTM [RFC1323], IPSec с использованием AH [RFC2402] или ESP
[RFC2406]).
РЕКОМЕНДАЦИЯ: ACK Reconstruction является экспериментальной прозрачной модификацией, выполняемой на обратном пути после восходящего канала-узкого места. Она предназначена для использования совместно с мерой смягчения ТИПА 1. Она уменьшает размер всплеска передачи TCP в прямом направлении, который иначе может увеличиваться, когда схемы ТИПА 1 используются сами по себе. Она требует изменения оборудования после восходящего канала (включая поддержание мягкого состояния для каждого потока). Схема вводит неявные предположения о сетевом пути и имеет
потенциальные уязвимости Denial-of-Service (то есть действует как усилитель пакетов); их необходимо лучше изучить и устранить с помощью надлежащих техник безопасности.
Выбор подходящих алгоритмов для распределения ACK-трафика во времени остаётся открытым исследовательским вопросом. В настоящее время также имеется мало опыта последствий использования таких техник в Интернете, и поэтому рекомендуется, чтобы эта техника не использовалась в Интернете в её текущем виде.
5.3.2 Уплотнение и компандирование ACK
ACK Compaction и ACK Companding [SAM99, FSS01] — это методы, работающие в точке обратного пути после ограниченного пропускной способностью восходящего узкого места для ACK. Подобно AR (раздел 5.3.1), ACK Compaction и ACK Companding используются совместно с методом AF (раздел 5.2.1) и восстанавливают отфильтрованные ACK, возвращая поток ACK. Однако от AR они отличаются тем, что используют модифицированный AF (называемый компактором или компрессором), в котором ко всем Stretch ACK, созданным AF, добавляется явная информация. Она используется для явной синхронизации операции восстановления (называемой здесь расширением).
Модифицированный AF сочетает два изменения. Во-первых, когда компрессор удаляет ACK из очереди восходящей линии-узкого места, он добавляет явную информацию (префикс) к оставшемуся ACK (этот ACK помечается, чтобы гарантировать, что впоследствии он не будет удалён). Дополнительная информация содержит сведения об условиях, при которых ACK ранее отфильтровывались. В префиксе может быть закодирована различная информация. В том числе количество ACK, удалённых AF, и среднее число подтверждённых байтов. Впоследствии она может использоваться расширителем на удалённом конце туннеля. Для управления распределением во времени восстановленных ACK также может добавляться дополнительная информация о времени [FSS01]. Также может кодироваться временной интервал между отфильтрованными ACK.
Для кодирования префикса необходимо, чтобы последующий расширитель распознавал модифицированный заголовок ACK. Обычно это ограничивало бы расширитель локальной для линии работой (на приёмном интерфейсе восходящей линии-узкого места). Если требуется удалённое расширение дальше по обратному пути, для передачи модифицированных ACK удалённому расширителю может использоваться туннель. Туннель, однако, вносит дополнительные накладные расходы; сети с асимметричной пропускной способностью и симметричной маршрутизацией часто уже используют такие туннели (например, в сети UDLR [RFC3077] расширитель может быть совмещён с маршрутизатором передачи).
Расширение ACK использует алгоритм без состояния для расширения ACK (то есть каждый полученный пакет обрабатывается независимо от ранее полученных пакетов). Он использует информацию из префикса вместе с полем подтверждения в полученном ACK, чтобы создать число ACK, эквивалентное числу ранее удалённых компактором. Эти ACK пересылаются первоначальному назначению, то есть отправителю TCP, сохраняя обычное тактирование TCP по ACK. Таким образом, ACK Compaction, в отличие от AR, не зависит от конкретных политик ACK и не обязан видеть все ACK, связанные с обратным путём (например, он может быть совместим со схемами, подобными DAASS [RFC2760]).
Могут возникать некоторые потенциальные уязвимости типа отказа в обслуживании (раздел 6), и они должны устраняться надлежащими методами безопасности. Метод не может выполнять восстановление для соединений, использующих IPSec, поскольку невозможно восстановить подходящую информацию безопасности. Можно явно кодировать информацию безопасности IPSec из подавленных пакетов, обеспечивая работу с IPSec AH, однако это остаётся открытым исследовательским вопросом и предполагает дополнительные накладные расходы на каждый ACK.
РЕКОМЕНДАЦИЯ: ACK Compaction и Companding являются экспериментальными прозрачными модификациями, выполняемыми на обратном пути после восходящей линии-узкого места. Они предназначены для использования совместно с модифицированным средством смягчения последствий ТИПА 1 и уменьшают размер всплеска TCP-передачи в прямом направлении, который в противном случае может увеличиваться, когда схемы ТИПА 1 используются сами по себе.
Метод желателен, но требует модификации оборудования после восходящей линии-узкого места (включая обработку модифицированного заголовка ACK). Выбор подходящих алгоритмов для распределения ACK-трафика во времени также остаётся открытым исследовательским вопросом. Некоторые потенциальные уязвимости типа отказа в обслуживании могут возникать с любым устройством, способным действовать как усилитель пакетов. Они должны устраняться надлежащими методами безопасности. Опыт использования этой схемы на путях Интернета невелик. Эта схема является предметом продолжающихся исследований и в её текущем виде не рекомендуется для использования в Интернете.
5.3.3 Смягчение всплесков TCP-пакетов, создаваемых нечастыми ACK
Всплески пакетов данных, возникающие при использовании схемы типа 1 на пути в обратном направлении, могут быть смягчены установкой на прямом пути маршрутизатора, поддерживающего Generic Traffic Shaping (GTS) [Seg00]. GTS — это стандартный механизм маршрутизатора, реализованный во многих развёрнутых маршрутизаторах. Этот метод не устраняет всплески данных, создаваемые отправителем TCP, но пытается сгладить их, используя методы планирования и постановки в очередь, создавая трафик, похожий на трафик при использовании TCP Pacing (раздел 4.6). Эти
методы требуют поддерживать в маршрутизаторе мягкое состояние для каждого потока и увеличивают накладные расходы на обработку каждого пакета. Для постановки в очередь формируемых пакетов требуется некоторая дополнительная буферная ёмкость.
Для выполнения GTS маршрутизатору необходимо выбрать подходящие параметры формирования трафика, для чего требуется знание политики сети, поведения соединений и/или характеристик нижележащего узкого места. GTS также может использоваться для принудительного применения других сетевых политик и содействия справедливости между конкурирующими TCP-соединениями (а также потоками UDP и многоадресными потоками). Он также уменьшает вероятность ACK Compression [ZSC91].
Сглаживание всплесков пакетов уменьшает воздействие всплесков TCP-передачи на маршрутизаторы и хосты после точки, в которой выполняется GTS. Поэтому желательно выполнять GTS близко к отправляющему хосту или, по меньшей мере, в точке перед первым маршрутизатором-узким местом прямого пути.
РЕКОМЕНДАЦИИ: Generic Traffic Shaping (GTS) — прозрачный метод, применяемый на маршрутизаторе прямого пути. Алгоритмы для реализации GTS доступны в широко развёрнутых маршрутизаторах и могут использоваться на линии Интернета, но предполагают значительные дополнительные затраты на обработку каждого пакета.
Конфигурирование GTS является решением сетевой политики поставщика сетевых услуг. При надлежащей конфигурации метод уменьшит размер всплесков пакетов данных TCP, смягчая последствия методов типа 1. GTS рекомендуется для использования в Интернете совместно с методами типа 1, такими как ACK Filtering (раздел 5.2.1) и ACK Decimation (раздел 5.2.2).
5.4 ТИП 3: Планирование восходящей линии
Многие из приведённых выше схем предполагают использование очередей для каждого потока (или очередей для каждого соединения в случае TCP) на восходящей линии-узком месте. Постановка в очередь для каждого потока (например, FQ, CBQ) даёт преимущества при использовании на любой медленной линии (где время передачи пакета составляет заметную часть RTT пути) [RFC3150]. Схемы типа 3 дают дополнительное преимущество при использовании с одним из приведённых выше методов.
5.4.1 Постановка в очередь для каждого потока на восходящей линии-узком месте
Когда в сети с асимметричной пропускной способностью существует двунаправленный трафик, конкурирующие потоки ACK и пакетов данных на обратном пути могут ухудшать производительность как восходящих, так и нисходящих потоков [KVR98]. Поэтому крайне желательно использовать на восходящей линии стратегию постановки в очередь в сочетании с механизмом планирования. Это также называлось мультиплексированием на основе приоритетов [RFC3135].
На медленной восходящей линии передача больших пакетов данных перед ACK может вносить заметный джиттер [RFC3150]. Простая схема может быть реализована с использованием очередей для каждого потока и справедливого планировщика (например, обслуживания всех потоков по циклу или планирования по приоритетам). Модифицированный планировщик [KVR98] мог бы ограничивать число ACK, которое хосту разрешено передать в восходящем направлении до передачи пакета данных (при условии, что по меньшей мере один пакет данных ожидает в очереди восходящей линии). Это гарантирует потокам в обратном направлении как минимум определённую минимальную долю пропускной способности, позволяя при этом потокам в прямом направлении повышать пропускную способность TCP.
Сжатие содержимого (полезной нагрузки), малый MTU, прозрачная фрагментация на уровне линии [RFC1991, RFC2686] или возможность приостановки/возобновления на уровне линии (когда кадры с более высоким приоритетом могут прерывать передачу кадров с более низким приоритетом) могут использоваться для смягчения воздействия (джиттера) двунаправленного трафика на низкоскоростных линиях [RFC3150]. Более совершенные схемы (например, WFQ) также могут использоваться для повышения производительности передач с несколькими потоками ACK, таких как http [Seg00].
РЕКОМЕНДАЦИЯ: Постановка в очередь для каждого потока является прозрачной модификацией, выполняемой на восходящей линии-узком месте. Планирование для каждого потока (или каждого класса) не влияет на поведение Интернета при перегрузке и может использоваться на любой линии Интернета. Схема имеет особые преимущества для медленных линий. Она широко реализована и широко развёрнута на линиях, работающих со скоростью менее 2 Мбит/с. Она рекомендуется как самостоятельное средство смягчения последствий или в сочетании с одним из других описанных методов.
5.4.2 Планирование ACK в первую очередь
Планирование ACK в первую очередь является экспериментальным методом повышения производительности двунаправленных передач. В этом случае пакеты данных и ACK конкурируют за ресурсы на восходящей линии-узком месте [RFC3150]. Одна очередь First-In First-Out, FIFO, для пакетов данных и ACK могла бы ухудшить производительность передач в прямом направлении. Например, если восходящая линия-узкое место — это коммутируемая линия 28,8 кбит/с, передача пакета данных размером 1 Кбайт заняла бы около 280 мс. Поэтому, даже если всего два таких пакета данных окажутся в очереди перед ACK (что не является необычным, поскольку во время медленного старта пакеты данных отправляются парами), они исключат передачу ACK значительно более чем на полсекунды. Если перед ACK в очереди окажется более двух пакетов данных, ACK будут задержаны ещё сильнее [RFC3150].
Возможный подход к смягчению этого состоит в планировании пакетов данных и ACK иначе, чем FIFO. Один из алгоритмов, в частности, — планирование ACK в первую очередь, которое предоставляет ACK более высокий приоритет, чем пакетам данных. Мотивация такого планирования заключается в том, что оно минимизирует время простоя прямого соединения, минимизируя время, которое ACK проводят в очереди за пакетами данных на восходящей линии. В то же время при использовании методов типа 0, таких как сжатие заголовков [RFC1144], время передачи ACK становится достаточно малым, и воздействие на последующие пакеты данных минимально. (Исключением являются подсети, в которых накладные расходы восходящей линии на пакет велики, например подсети пакетной радиосвязи; раздел 3.2.) Эта схема планирования не требует, чтобы восходящий маршрутизатор/хост-узкое место явно идентифицировал отдельные TCP-соединения или поддерживал для них состояние.
Планирование ACK в первую очередь не помогает избежать задержки из-за пакета данных, уже передаваемого по линии. В таком случае могут быть полезны фрагментация линии или приостановка/возобновление.
РЕКОМЕНДАЦИЯ: Планирование ACK в первую очередь является экспериментальной прозрачной модификацией, выполняемой на восходящей линии-узком месте. Если оно используется без механизма (такого как ACK Congestion Control (ACC), раздел 4.3) для регулирования объёма ACK, это может привести к голоданию пакетов данных. Это снижение производительности, испытываемое конечными хостами, использующими линию, и оно не изменяет поведение Интернета при перегрузке. Эксперименты показывают, что планирование ACK в первую очередь в сочетании с ACC является перспективным. Однако опыт использования метода в более широком Интернете невелик. Дальнейшая разработка метода остаётся открытым исследовательским вопросом, и поэтому схема в настоящее время не рекомендуется для использования в Интернете.
6. Соображения безопасности
Рекомендации, содержащиеся в этом документе, не влияют на целостность TCP, не вносят новых последствий для безопасности в протокол TCP или в приложения, использующие TCP.
Некоторые соображения безопасности в контексте этого документа обусловлены последствиями использования IPSec конечными хостами или маршрутизаторами, работающими на обратном пути. Использование IPSec предотвращает или усложняет некоторые средства смягчения последствий. Например:
(i) Когда IPSec ESP [RFC2406] используется для шифрования полезной нагрузки IP, промежуточные сущности не могут ни читать, ни изменять заголовок TCP. Это исключает сжатие заголовков, ACK Filtering, ACK Reconstruction и ACK Compaction.
(ii) Информация заголовка TCP может быть видимой при использовании некоторых форм безопасности сетевого уровня. Например, при использовании IPSec AH [RFC2402] заголовок TCP может читаться, но не изменяться промежуточными узлами. Это в будущем может допустить расширения для поддержки ACK Filtering, но исключает создание промежуточными узлами новых
пакетов (например, ACK Reconstruction). Улучшенная схема сжатия заголовков, рассматриваемая в [RFC2507], также работала бы с IPSec AH.
При использовании схем типа 2 возможны последствия, связанные с отказом в обслуживании (DoS). Если не используются дополнительные механизмы безопасности, Reconstructor/expander может быть использован в качестве усилителя пакетов. Третья сторона может внедрять неавторизованные Stretch ACK в обратный путь, вызывая генерацию дополнительных ACK. Эти ACK будут потреблять пропускную способность обратного пути и ресурсы обработки систем вдоль пути, включая хост назначения. Это создаёт потенциальную платформу для DoS-атаки. Необходимо принять обычные меры предосторожности, чтобы проверить правильность конечной точки туннеля и обеспечить, чтобы приложения не могли ложно внедрять пакеты, расширяющиеся с генерацией нежелательного трафика. Установление ограничения скорости и верхней границы для коэффициента задержанных ACK (d) также уменьшило бы последствия любой необнаруженной эксплуатации.
7. Сводка
В настоящем документе рассматривается несколько ограничений производительности TCP, возникающих из-за асимметрии свойств прямого и обратного путей в IP-сети. Такие ограничения производительности возникают, например, вследствие как асимметрии полосы пропускания (ёмкости), так и асимметричных разделяемых сред в обратном направлении, а также взаимодействий с протоколами Media Access Control (MAC). Асимметричная ёмкость может приводить к потере TCP-подтверждений (ACK) или к их чрезмерной задержке (например, когда узкое место канала совместно используется многими потоками либо когда имеется двунаправленный трафик). Этот эффект может усугубляться задержками доступа к среде (например, в некоторых многопереходных радиоподсетях, при спутниковом доступе Bandwidth on Demand). Асимметрия, и в особенности высокая асимметрия, порождает ряд проблем производительности TCP.
Рассматривается набор методов, обеспечивающих улучшение производительности. Они включают методы смягчения перегрузки ACK и методы, позволяющие отправителю TCP работать с редкими ACK без разрушения самотактирования TCP. Эти методы включают как сквозные, так и локальные канального уровня и подсетевые схемы. Многие из этих методов были подробно оценены посредством анализа, моделирования и/или реализации в асимметричных подсетях, являющихся частью Интернета. Однако для некоторых методов пока недостаточно эксплуатационного опыта, и поэтому в настоящее время они остаются предметами продолжающихся исследований и экспериментов.
Следующая таблица обобщает текущие рекомендации. Механизмы классифицируются как рекомендуемые (REC), не рекомендуемые (NOT REC) либо экспериментальные (EXP). Экспериментальные методы могут быть недостаточно специфицированы. Для того чтобы эти методы могли быть рекомендованы для использования в публичном Интернете, потребуется дополнительный эксплуатационный опыт.
Рекомендации по сквозным модификациям хостов приведены в таблице 1. В ней перечислены каждый метод, раздел, в котором обсуждается каждый метод, и место его применения (S обозначает хост, отправляющий пакеты данных TCP в прямом направлении; R обозначает хост, принимающий эти пакеты данных).
+------------------------+-------------+------------+--------+
| Метод | Использование| Раздел | Где |
+------------------------+-------------+------------+--------+
| Modified Delayed ACKs | NOT REC | 4.1 | TCP R |
| Large MSS & NO FRAG | REC | 4.2 | TCP SR |
| Large MSS & IP FRAG | NOT REC | 4.2 | TCP SR |
| ACK Congestion Control | EXP | 4.3 | TCP SR |
| Window Pred. Mech (WPM)| NOT REC | 4.4 | TCP R |
| Window Cwnd. Est. (ACE)| NOT REC | 4.5 | TCP R |
| TCP Sender Pacing | EXP *1 | 4.6 | TCP S |
| Byte Counting | NOT REC *2 | 4.7 | TCP S |
| Backpressure | EXP *1 | 4.8 | TCP R |
+------------------------+-------------+------------+--------+
Таблица 1: Рекомендации относительно модификаций хостов.
*1 Реализация метода может потребовать изменений внутренней конструкции стека протоколов конечных хостов.
*2 Зависит от схемы предотвращения чрезмерного всплеска передачи TCP.
Рекомендации по методам, не требующим, чтобы отправитель и получатель TCP знали об их существовании (то есть прозрачным методам), приведены в таблице 2. Каждый метод указан вместе с разделом, в котором обсуждается каждый механизм, и местом применения метода (S обозначает отправляющий интерфейс перед восходящим узким местом канала; R обозначает принимающий интерфейс после восходящего узкого места канала).
+------------------------+-------------+------------+--------+
| Механизм | Использование| Раздел | Тип |
+------------------------+-------------+------------+--------+
| Header Compr. (V-J) | REC *1 | 5.1.1 | 0 SR |
| Header Compr. (ROHC) | REC *1 *2 | 5.1.2 | 0 SR |
+------------------------+-------------+------------+--------+
| ACK Filtering (AF) | EXP *3 | 5.2.1 | 1 S |
| ACK Decimation | EXP *3 | 5.2.2 | 1 S |
+------------------------+-------------+------------+--------+
| ACK Reconstruction (AR)| NOT REC | 5.3.1 | 2 *4 |
| ACK Compaction/Compand.| EXP | 5.3.2 | 2 S *4 |
| Gen. Traff. Shap. (GTS)| REC | 5.3.3 | 2 *5 |
+------------------------+-------------+------------+--------+
| Fair Queueing (FQ) | REC | 5.4.1 | 3 S |
| ACKs-First Scheduling | NOT REC | 5.4.2 | 3 S |
+------------------------+-------------+------------+--------+
Таблица 2: Рекомендации относительно прозрачных модификаций.
*1 При высокой асимметрии эти схемы могут ухудшать производительность TCP, но не считаются вредными для Интернета.
*2 Стандартизация новых протоколов сжатия TCP является предметом продолжающейся работы в ROHC WG; см. другие RFC IETF по использованию этих методов.
*3 Использование в Интернете зависит от схемы предотвращения чрезмерного всплеска передачи TCP.
*4 Выполняется в точке обратного пути после восходящего узкого места канала.
*5 Выполняется в точке прямого пути.
8. Благодарности
Настоящий документ получил пользу от замечаний членов рабочей группы Performance Implications of Links (PILC). В частности, авторы хотели бы поблагодарить John Border, Spencer Dawkins, Aaron Falk, Dan Grossman, Randy Katz, Jeff Mandin, Rod Ragland, Ramon Segura, Joe Touch и Lloyd Wood за их полезные замечания. Они также выражают признательность Metricom Inc. за предоставленные данные, касающиеся работы их сети пакетной передачи данных.
9. Ссылки
Ссылки вида RFCnnnn являются документами Internet Request for Comments (RFC), доступными в Интернете по адресу http://www.rfc-editor.org/.
9.1 Нормативные ссылки
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March
2000.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
Shelby, "Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations", RFC 3135, June 2001.
9.2 Информационные ссылки
[abc-ID] Allman, M., "TCP Congestion Control with Appropriate Byte
Counting", Work in Progress.
[All97b] Allman, M., "Fixing Two BSD TCP Bugs", Technical Report
CR-204151, NASA Lewis Research Center, October 1997.
[ANS01] ANSI Standard T1.413, "Network to Customer Installation
Interfaces - Asymmetric Digital Subscriber Lines (ADSL)
Metallic Interface", November 1998.
[ASB96] Arora, V., Suphasindhu, N., Baras, J.S. and D. Dillon,
"Asymmetric Internet Access over Satellite-Terrestrial
Networks", Proc. AIAA: 16th International Communications
Satellite Systems Conference and Exhibit, Part 1,
Washington, D.C., February 25-29, 1996, pp.476-482.
[AST00] Aggarwal, A., Savage, S., and T. Anderson, "Understanding
the Performance of TCP Pacing", Proc. IEEE INFOCOM, Tel-
Aviv, Israel, V.3, March 2000, pp. 1157-1165.
[Bal98] Balakrishnan, H., "Challenges to Reliable Data Transport
over Heterogeneous Wireless Networks", Ph.D. Thesis,
University of California at Berkeley, USA, August 1998.
http://nms.lcs.mit.edu/papers/hari-phd/
[BPK99] Balakrishnan, H., Padmanabhan, V. N., and R. H. Katz, "The
Effects of Asymmetry on TCP Performance", ACM Mobile
Networks and Applications (MONET), Vol.4, No.3, 1999, pp.
219-241. An expanded version of a paper published at Proc.
ACM/IEEE Mobile Communications Conference (MOBICOM), 1997.
[BPS00] Bennett, J. C., Partridge, C., and N. Schectman, "Packet
Reordering is Not Pathological Network Behaviour", IEEE/ACM
Transactions on Networking, Vol. 7, Issue. 6, 2000,
pp.789-798.
[Cla88] Clark, D.D, "The Design Philosophy of the DARPA Internet
Protocols", ACM Computer Communications Review (CCR), Vol.
18, Issue 4, 1988, pp.106-114.
[CLC99] Clausen, H., Linder, H., and B. Collini-Nocker, "Internet
over Broadcast Satellites", IEEE Communications Magazine,
Vol. 37, Issue. 6, 1999, pp.146-151.
[CLP98] Calveras, A., Linares, J., and J. Paradells, "Window
Prediction Mechanism for Improving TCP in Wireless
Asymmetric Links". Proc. IEEE Global Communications
Conference (GLOBECOM), Sydney Australia, November 1998,
pp.533-538.
[CR98] Cohen, R., and Ramanathan, S., "Tuning TCP for High
Performance in Hybrid Fiber Coaxial Broad-Band Access
Networks", IEEE/ACM Transactions on Networking, Vol.6,
No.1, 1998, pp.15-29.
[DS00] Cable Television Laboratories, Inc., Data-Over-Cable
Service Interface Specifications---Radio Frequency
Interface Specification SP-RFIv1.1-I04-00407, 2000
[DS01] Data-Over-Cable Service Interface Specifications, Radio
Frequency Interface Specification 1.0, SP-RFI-I05-991105,
Cable Television Laboratories, Inc., November 1999.
[DMT96] Durst, R., Miller, G., and E. Travis, "TCP Extensions for
Space Communications", ACM/IEEE Mobile Communications
Conference (MOBICOM), New York, USA, November 1996, pp.15-
26.
[EN97] "Digital Video Broadcasting (DVB); DVB Specification for
Data Broadcasting", European Standard (Telecommunications
series) EN 301 192, 1997.
[EN00] "Digital Video Broadcasting (DVB); Interaction Channel for
Satellite Distribution Systems", Draft European Standard
(Telecommunications series) ETSI, Draft EN 301 790, v.1.2.1
[FJ93] Floyd, S., and V. Jacobson, "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM Transactions
on Networking, Vol.1, No.4, 1993, pp.397-413.
[FSS01] Fairhurst, G., Samaraweera, N.K.G, Sooriyabandara, M.,
Harun, H., Hodson, K., and R. Donardio, "Performance Issues
in Asymmetric Service Provision using Broadband Satellite",
IEE Proceedings on Communication, Vol.148, No.2, 2001,
pp.95-99.
[ITU01] ITU-T Recommendation E.681, "Traffic Engineering Methods
For IP Access Networks Based on Hybrid Fiber/Coax System",
September 2001.
[ITU02] ITU-T Recommendation G.992.1, "Asymmetrical Digital
Subscriber Line (ADSL) Transceivers", July 1999.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proc. ACM
SIGCOMM, Stanford, CA, ACM Computer Communications Review
(CCR), Vol.18, No.4, 1988, pp.314-329.
[Ken87] Kent C.A., and J. C. Mogul, "Fragmentation Considered
Harmful", Proc. ACM SIGCOMM, USA, ACM Computer
Communications Review (CCR), Vol.17, No.5, 1988, pp.390-
401.
[KSG98] Krout, T., Solsman, M., and J. Goldstein, "The Effects of
Asymmetric Satellite Networks on Protocols", Proc. IEEE
Military Communications Conference (MILCOM), Bradford, MA,
USA, Vol.3, 1998, pp.1072-1076.
[KVR98] Kalampoukas, L., Varma, A., and Ramakrishnan, K.K.,
"Improving TCP Throughput over Two-Way Asymmetric Links:
Analysis and Solutions", Proc. ACM SIGMETRICS, Medison,
USA, 1998, pp.78-89.
[LM97] Lin, D., and R. Morris, "Dynamics of Random Early
Detection", Proc. ACM SIGCOMM, Cannes, France, ACM Computer
Communications Review (CCR), Vol.27, No.4, 1997, pp.78-89.
[LMS97] Lakshman, T.V., Madhow, U., and B. Suter, "Window-based
Error Recovery and Flow Control with a Slow Acknowledgement
Channel: A Study of TCP/IP Performance", Proc. IEEE
INFOCOM, Vol.3, Kobe, Japan, 1997, pp.1199-1209.
[MJW00] Ming-Chit, I.T., Jinsong, D., and W. Wang,"Improving TCP
Performance Over Asymmetric Networks", ACM SIGCOMM, ACM
Computer Communications Review (CCR), Vol.30, No.3, 2000.
[Pad98] Padmanabhan, V.N., "Addressing the Challenges of Web Data
Transport", Ph.D. Thesis, University of California at
Berkeley, USA, September 1998 (also Tech Report UCB/CSD-
98-1016). http://www.cs.berkeley.edu/~padmanab/phd-
thesis.html
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[RFC2018] Mathis, B., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2525] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B.
Volz, "Known TCP Implementation Problems", RFC 2525, March
1999.
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP",
RFC 2686, September 1999.
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson,
T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K.,
Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research
Related to Satellites", RFC 2760, February 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N. and Y.
Zhang, "A link Layer tunneling mechanism for unidirectional
links", RFC 3077, March 2001.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
T., Yoshimura, T. and H. Zheng, "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP ESP and
uncompressed", RFC 3095, July 2001.
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-
to-end Performance Implications of Slow Links", BCP 48, RFC
3150, July 2001.
[RFC3168] Ramakrishnan K., Floyd, S. and D. Black, "A Proposal to add
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[Sam99] Samaraweera, N.K.G, "Return Link Optimization for Internet
Service Provision Using DVB-S Networks", ACM Computer
Communications Review (CCR), Vol.29, No.3, 1999, pp.4-19.
[Seg00] Segura R., "Asymmetric Networking Techniques For Hybrid
Satellite Communications", NC3A, The Hague, Netherlands,
NATO Technical Note 810, August 2000, pp.32-37.
[SF98] Samaraweera, N.K.G., and G. Fairhurst. "High Speed Internet
Access using Satellite-based DVB Networks", Proc. IEEE
International Networks Conference (INC98), Plymouth, UK,
1998, pp.23-28.
[ZSC91] Zhang, L., Shenker, S., and D. D. Clark, "Observations and
Dynamics of a Congestion Control Algorithm: The Effects of
Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer
Communications Review (CCR), Vol 21, No 4, 1991, pp.133-
147.
10. Соображения IANA
С этим документом не связаны какие-либо соображения IANA.