TCP Performance Implications of Network Path Asymmetry
RFC 3449 описывает ухудшение производительности TCP в сетях с асимметричными прямым и обратным путями, включая различия пропускной способности и влияние MAC-протоколов. Основная причина — несовершенная и изменчивая обратная связь ACK: ACK могут задерживаться, теряться, сжиматься во времени или поступать редко, что нарушает самотактирование TCP и вызывает всплески передачи. Документ рассматривает сквозные, канального уровня и подсетевые методы смягчения этих эффектов, а также их ограничения. Рекомендации разделены на рекомендуемые, нерекомендуемые и экспериментальные; для части методов на момент публикации отсутствовал достаточный эксплуатационный опыт.
Рабочая группа по сетям H. Balakrishnan
Запрос комментариев: 3449 MIT LCS
BCP: 69 V. N. Padmanabhan
Категория: Лучшая современная практика Microsoft Research
G. Fairhurst
M. Sooriyabandara
University of Aberdeen, U.K.
Декабрь 2002
Влияние асимметрии сетевого пути
на производительность TCP
Статус данного меморандума
Этот документ определяет Лучшую современную практику Интернета для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение данного меморандума не ограничено.
Уведомление об авторском праве
Copyright (C) The Internet Society (2002). Все права защищены.
Аннотация
Этот документ описывает проблемы производительности TCP, возникающие
вследствие асимметричных воздействий. Эти проблемы возникают в
нескольких сетях доступа, включая сети с асимметричной пропускной
способностью и подсети пакетной радиосвязи, по различным лежащим в их
основе причинам. Однако итоговое влияние на производительность TCP в
обоих случаях одинаково: производительность часто значительно
ухудшается из-за несовершенства и изменчивости обратной связи ACK от
получателя к отправителю.
В документе подробно рассматриваются несколько мер смягчения этих
воздействий, которые либо предлагались, либо оценивались в литературе,
либо в настоящее время развернуты в сетях. Эти решения используют
сочетание локальных методов канального уровня, механизмов подсети и
сквозных механизмов, состоящее из: (i) методов управления каналом,
используемым для восходящего узкого места, переносящего ACK, обычно с
применением сжатия заголовков или уменьшения частоты TCP ACK, (ii)
методов обработки этой сниженной частоты ACK для сохранения
самотактирования TCP-отправителя, запускаемого подтверждениями, и
(iii) методов планирования пакетов данных и ACK в обратном направлении
для повышения производительности при наличии двунаправленного трафика.
Каждый метод описан вместе с известными проблемами и рекомендациями по
применению. В конце документа приведена сводка рекомендаций.
Balakrishnan et. al. Лучшая современная практика [Страница 1]
RFC 3449 PILC — асимметричные каналы Декабрь 2002
Содержание
1. Условные обозначения, используемые в этом документе ............3
2. Мотивация ....................................................4
2.1 Асимметрия вследствие различий в пропускной способности
передачи и приема ...........................................4
2.2 Асимметрия вследствие совместно используемой среды в
обратном направлении ........................................5
2.3 Общая проблема ..............................................5
3. Как асимметрия ухудшает производительность TCP? ................5
3.1 Асимметричная пропускная способность ........................5
3.2 Взаимодействия протоколов MAC ...............................7
3.3 Двунаправленный трафик ......................................8
3.4 Потери на асимметричных сетевых путях ......................10
4. Повышение производительности TCP с использованием мер на
стороне хоста .................................................10
4.1 Модифицированные отложенные ACK ............................11
4.2 Использование большого MSS .................................12
4.3 Управление перегрузкой ACK .................................13
4.4 Механизм прогнозирования окна ..............................14
4.5 Подтверждение на основе оценки Cwnd ........................14
4.6 Регулирование темпа TCP-отправителя ........................14
4.7 Подсчет байтов TCP .........................................15
4.8 Обратное давление ..........................................16
5. Повышение производительности TCP с использованием прозрачных
модификаций ...................................................17
5.1 ТИП 0: Сжатие заголовков ...................................18
5.1.1 Сжатие заголовков TCP .................................18
5.1.2 Альтернативные надежные алгоритмы сжатия заголовков ....19
5.2 ТИП 1: Управление пропускной способностью обратного канала .19
5.2.1 Фильтрация ACK ........................................20
5.2.2 Прореживание ACK ......................................21
5.3 ТИП 2: Обработка редких ACK ...............................22
5.3.1 Реконструкция ACK .....................................23
5.3.2 Уплотнение и компандирование ACK ......................25
5.3.3 Смягчение всплесков TCP-пакетов, создаваемых
редкими ACK ...........................................26
5.4 ТИП 3: Планирование восходящего канала .....................27
5.4.1 Очереди для каждого потока на восходящем канале —
узком месте ...........................................27
5.4.2 Планирование «сначала ACK» ............................28
6. Соображения безопасности ......................................29
7. Сводка ........................................................30
8. Благодарности .................................................32
9. Ссылки ........................................................32
10. Соображения IANA .............................................37
Приложение: Примеры подсетей, демонстрирующих асимметрию
сетевого пути ........................................38
Адреса авторов ...................................................40
Полное заявление об авторском праве ..............................41
Balakrishnan et. al. Лучшая современная практика [Страница 2]
RFC 3449 PILC — асимметричные каналы Декабрь 2002
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]. Состояние истекает
по прошествии некоторого времени (то есть его не требуется явно удалять
после завершения сеанса) и непрерывно обновляется, пока поток
продолжается (то есть утраченное состояние может быть реконструировано
без необходимости обмена дополнительными управляющими сообщениями).
Balakrishnan et. al. Лучшая современная практика [Страница 3]
RFC 3449 PILC — асимметричные каналы Декабрь 2002
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]).
При наличии нескольких восходящих каналов асимметрия может быть снижена
разделением восходящего трафика между несколькими доступными восходящими
каналами.
Balakrishnan et. al. Лучшая современная практика [Страница 4]
RFC 3449 PILC — асимметричные каналы Декабрь 2002
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
Balakrishnan et. al. Best Current Practice [Страница 6]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
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 может требовать экспоненциальной отсрочки повторной попытки, когда удалённый узел занят (например, ведёт обмен с другим узлом). Это приводит к большим и переменным задержкам связи в пакетных радиосетях.
Balakrishnan et. al. Best Current Practice [Страница 7]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
Асимметричная нагрузка (больше нисходящего, чем восходящего трафика) может приводить к постановке 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-соединение в каждом направлении. Во многих практических случаях нескольким одновременным соединениям необходимо совместно использовать доступную пропускную способность, повышая уровень перегрузки.
Balakrishnan et. al. Best Current Practice [Страница 8]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
Двунаправленный трафик делает эффекты, рассмотренные в разделе 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 соединения прямого направления.
Balakrishnan et. al. Best Current Practice [Страница 9]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
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].
Balakrishnan et. al. Best Current Practice [Page 10]
RFC 3449 PILC - Asymmetric Links December 2002
Обычно предполагается, что эти изменения будут выполняться на конечных хостах, использующих асимметричный путь, однако они могли и фактически применялись в промежуточном устройстве (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-приёмника хоста и осведомлённости принимающего хоста о том, что он использует соединение с асимметричным путём. Такое изменение имеет множество недостатков в общем случае и в настоящее время не рекомендуется для использования в Интернете.
Balakrishnan et. al. Best Current Practice [Page 11]
RFC 3449 PILC - Asymmetric Links December 2002
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-фрагментации в маршрутизаторах не рекомендуется.
Balakrishnan et. al. Best Current Practice [Page 12]
RFC 3449 PILC - Asymmetric Links December 2002
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.
Balakrishnan et. al. Best Current Practice [Page 13]
RFC 3449 PILC - Asymmetric Links December 2002
РЕКОМЕНДАЦИЯ: 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].
Balakrishnan et. al. Best Current Practice [Page 14]
RFC 3449 PILC - Asymmetric Links December 2002
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 на стороне получателя).
Balakrishnan et. al. Лучшая современная практика [Страница 15]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
Основная проблема состоит в том, что подсчёт байтов 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.
Обратное давление может быть несправедливым к соединению в обратном направлении и делать его пропускную способность сильно чувствительной к динамике соединения (соединений) в прямом направлении.
РЕКОМЕНДАЦИЯ: Обратное давление требует экспериментального изменения стека протоколов отправителя хоста, непосредственно подключённого к восходящему узкому звену. Использование обратного давления является вопросом реализации, а не вопросом сетевого протокола. Там, где реализовано обратное давление, оптимизации, описанные в этом разделе, могут быть желательны и могут приносить пользу двунаправленному трафику для хостов.
Balakrishnan et. al. Лучшая современная практика [Страница 16]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
Определение безопасных алгоритмов для обеспечения обратного давления всё ещё является предметом продолжающихся исследований. Этот метод не рекомендуется для использования в Интернете в его текущей форме.
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].
Balakrishnan et. al. Лучшая современная практика [Страница 17]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
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,
Balakrishnan et. al. Лучшая современная практика [Страница 18]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
и/или заголовки туннельной инкапсуляции). Эта схема широко реализована, развёрнута и используется на линиях Интернета. Она рекомендуется для улучшения производительности 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. Один набор методов реализуется только в одной точке пути обратного направления — внутри маршрутизатора/хоста, подключённого к восходящему узкому звену. Они используют класс потока или очереди для каждого потока на интерфейсе восходящей линии для управления очередью пакетов, ожидающих передачи по узкой восходящей линии.
Balakrishnan et. al. Лучшая современная практика [Страница 19]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
Этот тип методов ограничивает размер очереди буфера восходящей линии и использует алгоритм для удаления (отбрасывания) избыточных 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 в очередь.
Balakrishnan et. al. Best Current Practice [Page 20]
RFC 3449 PILC - Asymmetric Links December 2002
В будущих схемах могут использоваться более развитые правила, допускающие удаление выбранных 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 и пакетов данных. Повышенная скорость передачи в прямом направлении достигается на асимметричных каналах
Balakrishnan et. al. Best Current Practice [Page 21]
RFC 3449 PILC - Asymmetric Links December 2002
за счёт повышенной скорости 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, был переслан обратным путём. Кроме того, пытаясь восстановить
Balakrishnan et. al. Best Current Practice [Page 22]
RFC 3449 PILC - Asymmetric Links December 2002
интервалы между 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.
Balakrishnan et. al. Best Current Practice [Page 23]
RFC 3449 PILC - Asymmetric Links December 2002
Чтобы уменьшить размер всплеска отправителя 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 используются сами по себе. Она требует изменения оборудования после восходящего канала (включая поддержание мягкого состояния для каждого потока). Схема вводит неявные предположения о сетевом пути и имеет
Balakrishnan et. al. Best Current Practice [Page 24]
RFC 3449 PILC - Asymmetric Links December 2002
потенциальные уязвимости Denial-of-Service (то есть действует как усилитель пакетов); их необходимо лучше изучить и устранить с помощью надлежащих техник безопасности.
Выбор подходящих алгоритмов для распределения ACK-трафика во времени остаётся открытым исследовательским вопросом. В настоящее время также имеется мало опыта последствий использования таких техник в Интернете, и поэтому рекомендуется, чтобы эта техника не использовалась в Интернете в её текущем виде.
5.3.2 Уплотнение и компандирование ACKACK 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] расширитель может быть совмещён с маршрутизатором передачи).
Balakrishnan et. al. Best Current Practice [Page 25]
RFC 3449 PILC - Asymmetric Links December 2002
Расширение 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). Эти
Balakrishnan et. al. Best Current Practice [Page 26]
RFC 3449 PILC - Asymmetric Links December 2002
методы требуют поддерживать в маршрутизаторе мягкое состояние для каждого потока и увеличивают накладные расходы на обработку каждого пакета. Для постановки в очередь формируемых пакетов требуется некоторая дополнительная буферная ёмкость.
Для выполнения 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].
Balakrishnan et. al. Best Current Practice [Page 27]
RFC 3449 PILC - Asymmetric Links December 2002
На медленной восходящей линии передача больших пакетов данных перед 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-соединения или поддерживал для них состояние.
Balakrishnan et. al. Best Current Practice [Page 28]
RFC 3449 PILC - Asymmetric Links December 2002
Планирование 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, но исключает создание промежуточными узлами новых
Balakrishnan et. al. Best Current Practice [Page 29]
RFC 3449 PILC - Asymmetric Links December 2002
пакетов (например, 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. Эти методы включают как сквозные, так и локальные канального уровня и подсетевые схемы. Многие из этих методов были подробно оценены посредством анализа, моделирования и/или реализации в асимметричных подсетях, являющихся частью Интернета. Однако для некоторых методов пока недостаточно эксплуатационного опыта, и поэтому в настоящее время они остаются предметами продолжающихся исследований и экспериментов.
Balakrishnan et. al. Best Current Practice [Страница 30]
RFC 3449 PILC - Asymmetric Links December 2002
Следующая таблица обобщает текущие рекомендации. Механизмы классифицируются как рекомендуемые (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 обозначает принимающий интерфейс после восходящего узкого места канала).
Balakrishnan et. al. Best Current Practice [Страница 31]
RFC 3449 PILC - Asymmetric Links December 2002
+------------------------+-------------+------------+--------+
| Механизм | Использование| Раздел | Тип |
+------------------------+-------------+------------+--------+
| 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/.
Balakrishnan et. al. Best Current Practice [Страница 32]
RFC 3449 PILC - Asymmetric Links December 2002
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.
Balakrishnan et. al. Best Current Practice [Страница 33]
RFC 3449 PILC - Asymmetric Links December 2002
[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.
Balakrishnan et. al. Best Current Practice [Страница 34]
RFC 3449 PILC - Asymmetric Links December 2002
[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.
Balakrishnan et. al. Best Current Practice [Страница 35]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
[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.
Balakrishnan et. al. Best Current Practice [Страница 36]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
[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.
Balakrishnan et. al. Best Current Practice [Страница 37]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
Приложение — Примеры подсетей с асимметрией сетевого пути
В этом приложении приведён список некоторых подсетей, для которых
известно наличие асимметрии сетевого пути. Асимметрия ёмкости этих
сетевых путей может потребовать мер смягчения для обеспечения
приемлемой совокупной производительности. Примеры включают следующее:
- IP-сервис в некоторых глобальных и локальных беспроводных сетях.
В таких сетях преобладающая асимметрия сетевого пути обусловлена
архитектурой сети «концентратор и лучи» (например, одна базовая
станция, взаимодействующая с несколькими мобильными станциями);
для этого требуются протокол Ready To Send / Clear To Send (RTS/CTS)
и протокол Medium Access Control (MAC), который должен учитывать
значительное время переключения направления передачи радиостанций.
Большие накладные расходы на передачу каждого пакета могут привести
к значительной асимметрии сетевого пути.
- IP-сервис по прямому спутниковому каналу, использующему передачу
Digital Video Broadcast (DVB) [EN97] (например, 38-45 Mbps), и по
более медленному восходящему каналу, использующему наземную сетевую
технологию (например, коммутируемый модем, микроволновая связь в
пределах прямой видимости, сотовая радиосвязь) [CLC99]. Асимметрия
сетевого пути возникает из-за различия пропускной способности
восходящего и нисходящего каналов.
- Некоторые военные сети [KSG98], предоставляющие доступ в Интернет
узлам в пути или изолированным узлам [Seg00], используют спутниковый
нисходящий канал высокой пропускной способности (например, 2-3 Mbps)
с узкополосным восходящим каналом (например, 2.4-9.6 kbps),
использующим либо Demand Assigned Multiple Access (DAMA), либо
спутниковые каналы с фиксированной скоростью. Главный фактор,
вносящий вклад в асимметрию сетевого пути, — различие пропускной
способности восходящего и нисходящего каналов. Некоторые различия
между прямым и обратным путями могут возникать вследствие способа
распределения пропускной способности восходящего канала.
- Большинство передач данных по сетям кабельного телевидения (например,
DOCSIS [ITU01, DS00]), где аналоговые каналы, назначенные для
восходящей связи (то есть в обратном направлении), уже и могут быть
более шумными, чем каналы, назначенные для нисходящего канала.
Вследствие этого восходящий и нисходящий каналы различаются скоростью
передачи. Например, в DOCSIS 1.0 [DS00] скорость передачи в
нисходящем направлении составляет либо 27, либо 52 Mbps. Скорости
передачи в восходящем направлении могут динамически выбираться из
ряда скоростей в диапазоне от 166 kbps до 9 Mbps. Операторы могут
назначать несколько восходящих каналов на один нисходящий канал.
Накладные расходы физического уровня (PHY), сопровождающие передачи в
восходящем направлении, но отсутствующие в нисходящем канале, также
могут увеличить асимметрию сетевого пути. Сервис Best Effort, который
обычно используется для передачи TCP, применяет MAC-протокол
состязательного доступа/резервирования. Кабельный модем (CM),
отправляющий отдельный пакет (такой как TCP ACK) по восходящему
каналу, должен состязаться с другими CM при запросе пропускной
способности у центральной системы завершения кабельных модемов
(CMTS). Затем CMTS выделяет CM временные слоты для передачи в
восходящем направлении. CM может «прикреплять» ("piggyback")
последующие запросы к пакетам восходящего направления, избегая
циклов состязательного доступа; в результате интервалы между TCP ACK
могут существенно изменяться из-за небольших вариаций нагрузки сети
передачи данных по кабелю и интервалов поступления TCP DATA-пакетов.
Многочисленные другие сложности могут увеличивать либо уменьшать
асимметрию скорости и задержки доступа, испытываемую пакетами,
отправляемыми по восходящему каналу, относительно нисходящих пакетов
в DOCSIS. Асимметрия, испытываемая конечными узлами, также может
динамически изменяться (например, с нагрузкой сети), а также когда
сервисы Best Effort совместно используют пропускную способность с
сервисами, имеющими симметричную зарезервированную пропускную
способность (например, IP-телефония по сервису Unsolicited Grant)
[ITU01].
Balakrishnan et. al. Best Current Practice [Страница 38]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
- Asymmetric Digital Subscriber Line (ADSL) по определению предлагает
скорость передачи в нисходящем канале, более высокую, чем в восходящем
канале. Доступные скорости зависят от качества канала и конфигурации
системы. Например, одна широко развёрнутая технология ADSL [ITU02,
ANS01] работает на скоростях, кратных 32 kbps (до 6.144 Mbps), в
нисходящем канале и до 640 kbps — в восходящем канале. Асимметрия
сетевого пути, испытываемая конечными узлами, может дополнительно
увеличиваться, когда сервисы Best Effort, например доступ в Интернет
по ADSL, совместно используют доступную пропускную способность
восходящего канала с зарезервированными сервисами (например,
телефонией с постоянной скоростью передачи голоса).
Balakrishnan et. al. Best Current Practice [Страница 39]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
Адреса авторов
Hari Balakrishnan
Laboratory for Computer Science
200 Technology Square
Massachusetts Institute of Technology
Cambridge, MA 02139
USA
Phone: +1-617-253-8713
EMail: hari@lcs.mit.edu
Web: http://nms.lcs.mit.edu/~hari/
Venkata N. Padmanabhan
Microsoft Research
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1-425-705-2790
EMail: padmanab@microsoft.com
Web: http://www.research.microsoft.com/~padmanab/
Godred Fairhurst
Department of Engineering
Fraser Noble Building
University of Aberdeen
Aberdeen AB24 3UE
UK
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Mahesh Sooriyabandara
Department of Engineering
Fraser Noble Building
University of Aberdeen
Aberdeen AB24 3UE
UK
EMail: mahesh@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/mahesh
Balakrishnan et. al. Best Current Practice [Страница 40]
RFC 3449 PILC - Asymmetric Links Декабрь 2002
Полное заявление об авторских правах
Copyright (C) The Internet Society (2002). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, комментирующие или иным образом
разъясняющие его либо содействующие его реализации, могут создаваться,
копироваться, публиковаться и распространяться полностью или частично,
без каких-либо ограничений, при условии, что указанное выше уведомление
об авторских правах и настоящий абзац включаются во все такие копии и
производные работы. Однако сам этот документ не может быть каким-либо
образом изменён, например путём удаления уведомления об авторских
правах или ссылок на Internet Society либо другие организации Интернета,
кроме случаев, когда это необходимо для разработки стандартов Интернета,
при которой должны соблюдаться процедуры об авторских правах, определённые
процессом разработки стандартов Интернета, или когда это требуется для
перевода его на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не
будут отозваны Internet Society, её правопреемниками или лицами, которым
она передала права.
Этот документ и содержащаяся в нём информация предоставляются по
принципу «КАК ЕСТЬ», И THE INTERNET SOCIETY, И THE INTERNET ENGINEERING
TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ИЛИ ЛЮБЫЕ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ
ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время обеспечивается
Internet Society.
Balakrishnan et. al. Best Current Practice [Страница 41]
Network Working Group H. Balakrishnan
Request for Comments: 3449 MIT LCS
BCP: 69 V. N. Padmanabhan
Category: Best Current Practice Microsoft Research
G. Fairhurst
M. Sooriyabandara
University of Aberdeen, U.K.
December 2002
TCP Performance Implications
of Network Path Asymmetry
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes TCP performance problems that arise because
of asymmetric effects. These problems arise in several access
networks, including bandwidth-asymmetric networks and packet radio
subnetworks, for different underlying reasons. However, the end
result on TCP performance is the same in both cases: performance
often degrades significantly because of imperfection and variability
in the ACK feedback from the receiver to the sender.
The document details several mitigations to these effects, which have
either been proposed or evaluated in the literature, or are currently
deployed in networks. These solutions use a combination of local
link-layer techniques, subnetwork, and end-to-end mechanisms,
consisting of: (i) techniques to manage the channel used for the
upstream bottleneck link carrying the ACKs, typically using header
compression or reducing the frequency of TCP ACKs, (ii) techniques to
handle this reduced ACK frequency to retain the TCP sender's
acknowledgment-triggered self-clocking and (iii) techniques to
schedule the data and ACK packets in the reverse direction to improve
performance in the presence of two-way traffic. Each technique is
described, together with known issues, and recommendations for use.
A summary of the recommendations is provided at the end of the
document.
Balakrishnan et. al. Best Current Practice [Page 1]
RFC 3449 PILC - Asymmetric Links December 2002
Table of Contents
1. Conventions used in this Document ...............................3
2. Motivation ....................................................4
2.1 Asymmetry due to Differences in Transmit
and Receive Capacity .........................................4
2.2 Asymmetry due to Shared Media in the Reverse Direction .......5
2.3 The General Problem ..........................................5
3. How does Asymmetry Degrade TCP Performance? .....................5
3.1 Asymmetric Capacity ..........................................5
3.2 MAC Protocol Interactions ....................................7
3.3 Bidirectional Traffic ........................................8
3.4 Loss in Asymmetric Network Paths ............................10
4. Improving TCP Performance using Host Mitigations ...............10
4.1 Modified Delayed ACKs .......................................11
4.2 Use of Large MSS ............................................12
4.3 ACK Congestion Control ......................................13
4.4 Window Prediction Mechanism .................................14
4.5 Acknowledgement based on Cwnd Estimation. ...................14
4.6 TCP Sender Pacing ...........................................14
4.7 TCP Byte Counting ...........................................15
4.8 Backpressure ................................................16
5. Improving TCP performance using Transparent Modifications ......17
5.1 TYPE 0: Header Compression ..................................18
5.1.1 TCP Header Compression ..................................18
5.1.2 Alternate Robust Header Compression Algorithms ..........19
5.2 TYPE 1: Reverse Link Bandwidth Management ...................19
5.2.1 ACK Filtering ...........................................20
5.2.2 ACK Decimation ..........................................21
5.3 TYPE 2: Handling Infrequent ACKs ............................22
5.3.1 ACK Reconstruction ......................................23
5.3.2 ACK Compaction and Companding ...........................25
5.3.3 Mitigating TCP packet bursts generated by
Infrequent ACKs .........................................26
5.4 TYPE 3: Upstream Link Scheduling ............................27
5.4.1 Per-Flow queuing at the Upstream Bottleneck Link ........27
5.4.2 ACKs-first Scheduling ...................................28
6. Security Considerations ........................................29
7. Summary ........................................................30
8. Acknowledgments ................................................32
9. References .....................................................32
10. IANA Considerations ...........................................37
Appendix: Examples of Subnetworks Exhibiting Network Path
Asymmetry ...............................................38
Authors' Addresses ................................................40
Full Copyright Statement ..........................................41
Balakrishnan et. al. Best Current Practice [Page 2]
RFC 3449 PILC - Asymmetric Links December 2002
1. Conventions used in this Document
FORWARD DIRECTION: The dominant direction of data transfer over an
asymmetric network path. It corresponds to the direction with better
characteristics in terms of capacity, latency, error rate, etc. Data
transfer in the forward direction is called "forward transfer".
Packets travelling in the forward direction follow the forward path
through the IP network.
REVERSE DIRECTION: The direction in which acknowledgments of a
forward TCP transfer flow. Data transfer could also happen in this
direction (and is termed "reverse transfer"), but it is typically
less voluminous than that in the forward direction. The reverse
direction typically exhibits worse characteristics than the forward
direction. Packets travelling in the reverse direction follow the
reverse path through the IP network.
UPSTREAM LINK: The specific bottleneck link that normally has much
less capability than the corresponding downstream link. Congestion
is not confined to this link alone, and may also occur at any point
along the forward and reverse directions (e.g., due to sharing with
other traffic flows).
DOWNSTREAM LINK: A link on the forward path, corresponding to the
upstream link.
ACK: A cumulative TCP acknowledgment [RFC791]. In this document,
this term refers to a TCP segment that carries a cumulative
acknowledgement (ACK), but no data.
DELAYED ACK FACTOR, d: The number of TCP data segments acknowledged
by a TCP ACK. The minimum value of d is 1, since at most one ACK
should be sent for each data packet [RFC1122, RFC2581].
STRETCH ACK: Stretch ACKs are acknowledgements that cover more than 2
segments of previously unacknowledged data (d>2) [RFC2581]. Stretch
ACKs can occur by design (although this is not standard), due to
implementation bugs [All97b, RFC2525], or due to ACK loss [RFC2760].
NORMALIZED BANDWIDTH RATIO, k: The ratio of the raw bandwidth
(capacity) of the forward direction to the return direction, divided
by the ratio of the packet sizes used in the two directions [LMS97].
SOFTSTATE: Per-flow state established in a network device that is
used by the protocol [Cla88]. The state expires after a period of
time (i.e., is not required to be explicitly deleted when a session
Balakrishnan et. al. Best Current Practice [Page 3]
RFC 3449 PILC - Asymmetric Links December 2002
expires), and is continuously refreshed while a flow continues (i.e.,
lost state may be reconstructed without needing to exchange
additional control messages).
2. Motivation
Asymmetric characteristics are exhibited by several network
technologies, including cable data networks, (e.g., DOCSIS cable TV
networks [DS00, DS01]), direct broadcast satellite (e.g., an IP
service using Digital Video Broadcast, DVB, [EN97] with an
interactive return channel), Very Small Aperture satellite Terminals
(VSAT), Asymmetric Digital Subscriber Line (ADSL) [ITU02, ANS01], and
several packet radio networks. These networks are increasingly being
deployed as high-speed Internet access networks, and it is therefore
highly desirable to achieve good TCP performance. However, the
asymmetry of the network paths often makes this challenging.
Examples of some networks that exhibit asymmetry are provided in the
Appendix.
Asymmetry may manifest itself as a difference in transmit and receive
capacity, an imbalance in the packet loss rate, or differences
between the transmit and receive paths [RFC3077]. For example, when
capacity is asymmetric, such that there is reduced capacity on
reverse path used by TCP ACKs, slow or infrequent ACK feedback
degrades TCP performance in the forward direction. Similarly,
asymmetry in the underlying Medium Access Control (MAC) and Physical
(PHY) protocols could make it expensive to transmit TCP ACKs
(disproportionately to their size), even when capacity is symmetric.
2.1 Asymmetry due to Differences in Transmit and Receive Capacity
Network paths may be asymmetric because the upstream and downstream
links operate at different rates and/or are implemented using
different technologies.
The asymmetry in capacity may be substantially increased when best
effort IP flows carrying TCP ACKs share the available upstream
capacity with other traffic flows, e.g., telephony, especially flows
that have reserved upstream capacity. This includes service
guarantees at the IP layer (e.g., the Guaranteed Service [RFC2212])
or at the subnet layer (e.g., support of Voice over IP [ITU01] using
the Unsolicited Grant service in DOCSIS [DS01], or CBR virtual
connections in ATM over ADSL [ITU02, ANS01]).
When multiple upstream links exist the asymmetry may be reduced by
dividing upstream traffic between a number of available upstream
links.
Balakrishnan et. al. Best Current Practice [Page 4]
RFC 3449 PILC - Asymmetric Links December 2002
2.2 Asymmetry due to Shared Media in the Reverse Direction
In networks employing centralized multiple access control, asymmetry
may be a fundamental consequence of the hub-and-spokes architecture
of the network (i.e., a single base node communicating with multiple
downstream nodes). The central node often incurs less transmission
overhead and does not incur latency in scheduling its own downstream
transmissions. In contrast, upstream transmission is subject to
additional overhead and latency (e.g., due to guard times between
transmission bursts, and contention intervals). This can produce
significant network path asymmetry.
Upstream capacity may be further limited by the requirement that each
node must first request per-packet bandwidth using a contention MAC
protocol (e.g., DOCSIS 1.0 MAC restricts each node to sending at most
a single packet in each upstream time-division interval [DS00]). A
satellite network employing dynamic Bandwidth on Demand (BoD), also
consumes MAC resources for each packet sent (e.g., [EN00]). In these
schemes, the available uplink capacity is a function of the MAC
algorithm. The MAC and PHY schemes also introduce overhead per
upstream transmission which could be so significant that transmitting
short packets (including TCP ACKs) becomes as costly as transmitting
MTU-sized data packets.
2.3 The General Problem
Despite the technological differences between capacity-dependent and
MAC-dependent asymmetries, both kinds of network path suffer reduced
TCP performance for the same fundamental reason: the imperfection and
variability of ACK feedback. This document discusses the problem in
detail and describes several techniques that may reduce or eliminate
the constraints.
3. How does Asymmetry Degrade TCP Performance?
This section describes the implications of network path asymmetry on
TCP performance. The reader is referred to [BPK99, Bal98, Pad98,
FSS01, Sam99] for more details and experimental results.
3.1 Asymmetric Capacity
The problems that degrade unidirectional transfer performance when
the forward and return paths have very different capacities depend on
the characteristics of the upstream link. Two types of situations
arise for unidirectional traffic over such network paths: when the
upstream bottleneck link has sufficient queuing to prevent packet
(ACK) losses, and when the upstream bottleneck link has a small
buffer. Each is considered in turn.
Balakrishnan et. al. Best Current Practice [Page 5]
RFC 3449 PILC - Asymmetric Links December 2002
If the upstream bottleneck link has deep queues, so that this does
not drop ACKs in the reverse direction, then performance is a strong
function of the normalized bandwidth ratio, k. For example, for a 10
Mbps downstream link and a 50 Kbps upstream link, the raw capacity
ratio is 200. With 1000-byte data packets and 40-byte ACKs, the
ratio of the packet sizes is 25. This implies that k is 200/25 = 8.
Thus, if the receiver acknowledges more frequently than one ACK every
8 (k) data packets, the upstream link will become saturated before
the downstream link, limiting the throughput in the forward
direction. Note that, the achieved TCP throughput is determined by
the minimum of the receiver advertised window or TCP congestion
window, cwnd [RFC2581].
If ACKs are not dropped (at the upstream bottleneck link) and k > 1
or k > 0.5 when delayed ACKs are used [RFC1122], TCP ACK-clocking
breaks down. Consider two data packets transmitted by the sender in
quick succession. En route to the receiver, these packets get spaced
apart according to the capacity of the smallest bottleneck link in
the forward direction. The principle of ACK clocking is that the
ACKs generated in response to receiving these data packets reflects
this temporal spacing all the way back to the sender, enabling it to
transmit new data packets that maintain the same spacing [Jac88]. ACK
clocking with delayed ACKs, reflects the spacing between data packets
that actually trigger ACKs. However, the limited upstream capacity
and queuing at the upstream bottleneck router alters the inter-ACK
spacing of the reverse path, and hence that observed at the sender.
When ACKs arrive at the upstream bottleneck link at a faster rate
than the link can support, they get queued behind one another. The
spacing between them when they emerge from the link is dilated with
respect to their original spacing, and is a function of the upstream
bottleneck capacity. Thus the TCP sender clocks out new data packets
at a slower rate than if there had been no queuing of ACKs. The
performance of the connection is no longer dependent on the
downstream bottleneck link alone; instead, it is throttled by the
rate of arriving ACKs. As a side effect, the sender's rate of cwnd
growth also slows down.
A second side effect arises when the upstream bottleneck link on the
reverse path is saturated. The saturated link causes persistent
queuing of packets, leading to an increasing path Round Trip Time
(RTT) [RFC2998] observed by all end hosts using the bottleneck link.
This can impact the protocol control loops, and may also trigger
false time out (underestimation of the path RTT by the sending host).
A different situation arises when the upstream bottleneck link has a
relatively small amount of buffer space to accommodate ACKs. As the
transmission window grows, this queue fills, and ACKs are dropped. If
the receiver were to acknowledge every packet, only one of every k
Balakrishnan et. al. Best Current Practice [Page 6]
RFC 3449 PILC - Asymmetric Links December 2002
ACKs would get through to the sender, and the remaining (k-1) are
dropped due to buffer overflow at the upstream link buffer (here k is
the normalized bandwidth ratio as before). In this case, the reverse
bottleneck link capacity and slow ACK arrival rate are not directly
responsible for any degraded performance. However, the infrequency
of ACKs leads to three reasons for degraded performance:
1. The sender transmits data in large bursts of packets, limited only
by the available cwnd. If the sender receives only one ACK in k,
it transmits data in bursts of k (or more) packets because each
ACK shifts the sliding window by at least k (acknowledged) data
packets (TCP data segments). This increases the likelihood of
data packet loss along the forward path especially when k is
large, because routers do not handle large bursts of packets well.
2. Current TCP sender implementations increase their cwnd by counting
the number of ACKs they receive and not by how much data is
actually acknowledged by each ACK. The later approach, also known
as byte counting (section 4.7), is a standard implementation
option for cwnd increase during the congestion avoidance period
[RFC2581]. Thus fewer ACKs imply a slower rate of growth of the
cwnd, which degrades performance over long-delay connections.
3. The sender TCP's Fast Retransmission and Fast Recovery algorithms
[RFC2581] are less effective when ACKs are lost. The sender may
possibly not receive the threshold number of duplicate ACKs even
if the receiver transmits more than the DupACK threshold (> 3
DupACKs) [RFC2581]. Furthermore, the sender may possibly not
receive enough duplicate ACKs to adequately inflate its cwnd
during Fast Recovery.
3.2 MAC Protocol Interactions
The interaction of TCP with MAC protocols may degrade end-to-end
performance. Variable round-trip delays and ACK queuing are the main
symptoms of this problem.
One example is the impact on terrestrial wireless networks [Bal98]. A
high per-packet overhead may arise from the need for communicating
link nodes to first synchronise (e.g., via a Ready To Send / Clear to
Send (RTS/CTS) protocol) before communication and the significant
turn-around time for the wireless channel. This overhead is
variable, since the RTS/CTS exchange may need to back-off
exponentially when the remote node is busy (e.g., engaged in a
conversation with a different node). This leads to large and
variable communication latencies in packet-radio networks.
Balakrishnan et. al. Best Current Practice [Page 7]
RFC 3449 PILC - Asymmetric Links December 2002
An asymmetric workload (more downstream than upstream traffic) may
cause ACKs to be queued in some wireless nodes (especially in the end
host modems), exacerbating the variable latency. Queuing may also
occur in other shared media, e.g., cable modem uplinks, BoD access
systems often employed on shared satellite channels.
Variable latency and ACK queuing reduces the smoothness of the TCP
data flow. In particular, ACK traffic can interfere with the flow of
data packets, increasing the traffic load of the system.
TCP measures the path RTT, and from this calculates a smoothed RTT
estimate (srtt) and a linear deviation, rttvar. These are used to
estimate a path retransmission timeout (RTO) [RFC2988], set to srtt +
4*rttvar. For most wired TCP connections, the srtt remains constant
or has a low linear deviation. The RTO therefore tracks the path
RTT, and the TCP sender will respond promptly when multiple losses
occur in a window. In contrast, some wireless networks exhibit a
high variability in RTT, causing the RTO to significantly increase
(e.g., on the order of 10 seconds). Paths traversing multiple
wireless hops are especially vulnerable to this effect, because this
increases the probability that the intermediate nodes may already be
engaged in conversation with other nodes. The overhead in most MAC
schemes is a function of both the number and size of packets.
However, the MAC contention problem is a significant function of the
number of packets (e.g., ACKs) transmitted rather than their size.
In other words, there is a significant cost to transmitting a packet
regardless of packet size.
Experiments conducted on the Ricochet packet radio network in 1996
and 1997 demonstrated the impact of radio turnarounds and the
corresponding increased RTT variability, resulting in degraded TCP
performance. It was not uncommon for TCP connections to experience
timeouts of 9 - 12 seconds, with the result that many connections
were idle for a significant fraction of their lifetime (e.g.,
sometimes 35% of the total transfer time). This leads to under-
utilization of the available capacity. These effects may also occur
in other wireless subnetworks.
3.3 Bidirectional Traffic
Bidirectional traffic arises when there are simultaneous TCP
transfers in the forward and reverse directions over an asymmetric
network path, e.g., a user who sends an e-mail message in the reverse
direction while simultaneously receiving a web page in the forward
direction. To simplify the discussion, only one TCP connection in
each direction is considered. In many practical cases, several
simultaneous connections need to share the available capacity,
increasing the level of congestion.
Balakrishnan et. al. Best Current Practice [Page 8]
RFC 3449 PILC - Asymmetric Links December 2002
Bidirectional traffic makes the effects discussed in section 3.1 more
pronounced, because part of the upstream link bandwidth is consumed
by the reverse transfer. This effectively increases the degree of
bandwidth asymmetry. Other effects also arise due to the interaction
between data packets of the reverse transfer and ACKs of the forward
transfer. Suppose at the time the forward TCP connection is
initiated, the reverse TCP connection has already saturated the
bottleneck upstream link with data packets. There is then a high
probability that many ACKs of the new forward TCP connection will
encounter a full upstream link buffer and hence get dropped. Even
after these initial problems, ACKs of the forward connection could
get queued behind large data packets of the reverse connection. The
larger data packets may have correspondingly long transmission times
(e.g., it takes about 280 ms to transmit a 1 Kbyte data packet over a
28.8 kbps line). This causes the forward transfer to stall for long
periods of time. It is only at times when the reverse connection
loses packets (due to a buffer overflow at an intermediate router)
and slows down, that the forward connection gets the opportunity to
make rapid progress and build up its cwnd.
When ACKs are queued behind other traffic for appreciable periods of
time, the burst nature of TCP traffic and self-synchronizing effects
can result in an effect known as ACK Compression [ZSC91], which
reduces the throughput of TCP. It occurs when a series of ACKs, in
one direction are queued behind a burst of other packets (e.g., data
packets traveling in the same direction) and become compressed in
time. This results in an intense burst of data packets in the other
direction, in response to the burst of compressed ACKs arriving at
the server. This phenomenon has been investigated in detail for
bidirectional traffic, and recent analytical work [LMS97] has
predicted ACK Compression may also result from bi-directional
transmission with asymmetry, and was observed in practical asymmetric
satellite subnetworks [FSS01]. In the case of extreme asymmetry
(k>>1), the inter-ACK spacing can increase due to queuing (section
3.1), resulting in ACK dilation.
In summary, sharing of the upstream bottleneck link by multiple flows
(e.g., IP flows to the same end host, or flows to a number of end
hosts sharing a common upstream link) increases the level of ACK
Congestion. The presence of bidirectional traffic exacerbates the
constraints introduced by bandwidth asymmetry because of the adverse
interaction between (large) data packets of a reverse direction
connection and the ACKs of a forward direction connection.
Balakrishnan et. al. Best Current Practice [Page 9]
RFC 3449 PILC - Asymmetric Links December 2002
3.4 Loss in Asymmetric Network Paths
Loss may occur in either the forward or reverse direction. For data
transfer in the forward direction this results respectively in loss
of data packets and ACK packets. Loss of ACKs is less significant
than loss of data packets, because it generally results in stretch
ACKs [CR98, FSS01].
In the case of long delay paths, a slow upstream link [RFC3150] can
lead to another complication when the end host uses TCP large windows
[RFC1323] to maximize throughput in the forward direction. Loss of
data packets on the forward path, due to congestion, or link loss,
common for some wireless links, will generate a large number of
back-to-back duplicate ACKs (or TCP SACK packets [RFC2018]), for each
correctly received data packet following a loss. The TCP sender
employs Fast Retransmission and Recovery [RFC2581] to recover from
the loss, but even if this is successful, the ACK to the
retransmitted data segment may be significantly delayed by other
duplicate ACKs still queued at the upstream link buffer. This can
ultimately lead to a timeout [RFC2988] and a premature end to the TCP
Slow Start [RFC2581]. This results in poor forward path throughput.
Section 5.3 describes some mitigations to counter this.
4. Improving TCP Performance using Host Mitigations
There are two key issues that need to be addressed to improve TCP
performance over asymmetric networks. The first is to manage the
capacity of the upstream bottleneck link, used by ACKs and possibly
other traffic. A number of techniques exist which work by reducing
the number of ACKs that flow in the reverse direction. This has the
side effect of potentially destroying the desirable self-clocking
property of the TCP sender where transmission of new data packets is
triggered by incoming ACKs. Thus, the second issue is to avoid any
adverse impact of infrequent ACKs.
Each of these issues can be handled by local link-layer solutions
and/or by end-to-end techniques. This section discusses end-to-end
modifications. Some techniques require TCP receiver changes
(sections 4.1 4.4, 4.5), some require TCP sender changes (sections
4.6, 4.7), and a pair requires changes to both the TCP sender and
receiver (sections 4.2, 4.3). One technique requires a sender
modification at the receiving host (section 4.8). The techniques may
be used independently, however some sets of techniques are
complementary, e.g., pacing (section 4.6) and byte counting (section
4.7) which have been bundled into a single TCP Sender Adaptation
scheme [BPK99].
Balakrishnan et. al. Best Current Practice [Page 10]
RFC 3449 PILC - Asymmetric Links December 2002
It is normally envisaged that these changes would occur in the end
hosts using the asymmetric path, however they could, and have, been
used in a middle-box or Protocol Enhancing Proxy (PEP) [RFC3135]
employing split TCP. This document does not discuss the issues
concerning PEPs. Section 4 describes several techniques, which do
not require end-to-end changes.
4.1 Modified Delayed ACKs
There are two standard methods that can be used by TCP receivers to
generate acknowledgments. The method outlined in [RFC793] generates
an ACK for each incoming data segment (i.e., d=1). [RFC1122] states
that hosts should use "delayed acknowledgments". Using this
algorithm, an ACK is generated for at least every second full-sized
segment (d=2), or if a second full-sized segment does not arrive
within a given timeout (which must not exceed 500 ms [RFC1122], and
is typically less than 200 ms). Relaxing the latter constraint
(i.e., allowing d>2) may generate Stretch ACKs [RFC2760]. This
provides a possible mitigation, which reduces the rate at which ACKs
are returned by the receiver. An implementer should only deviate
from this requirement after careful consideration of the implications
[RFC2581].
Reducing the number of ACKs per received data segment has a number of
undesirable effects including:
(i) Increased path RTT
(ii) Increased time for TCP to open the cwnd
(iii) Increased TCP sender burst size, since cwnd opens in larger
steps
In addition, a TCP receiver is often unable to determine an optimum
setting for a large d, since it will normally be unaware of the
details of the properties of the links that form the path in the
reverse direction.
RECOMMENDATION: A TCP receiver must use the standard TCP algorithm
for sending ACKs as specified in [RFC2581]. That is, it may delay
sending an ACK after it receives a data segment [RFC1122]. When ACKs
are delayed, the receiver must generate an ACK within 500 ms and the
ACK should be generated for at least every second full sized segment
(MSS) of received data [RFC2581]. This will result in an ACK delay
factor (d) that does not exceed a value of 2. Changing the algorithm
would require a host modification to the TCP receiver and awareness
by the receiving host that it is using a connection with an
asymmetric path. Such a change has many drawbacks in the general
case and is currently not recommended for use within the Internet.
Balakrishnan et. al. Best Current Practice [Page 11]
RFC 3449 PILC - Asymmetric Links December 2002
4.2 Use of Large MSS
A TCP sender that uses a large Maximum Segment Size (MSS) reduces the
number of ACKs generated per transmitted byte of data.
Although individual subnetworks may support a large MTU, the majority
of current Internet links employ an MTU of approx 1500 bytes (that of
Ethernet). By setting the Don't Fragment (DF) bit in the IP header,
Path MTU (PMTU) discovery [RFC1191] may be used to determine the
maximum packet size (and hence MSS) a sender can use on a given
network path without being subjected to IP fragmentation, and
provides a way to automatically select a suitable MSS for a specific
path. This also guarantees that routers will not perform IP
fragmentation of normal data packets.
By electing not to use PMTU Discovery, an end host may choose to use
IP fragmentation by routers along the path in the forward direction
[RFC793]. This allows an MSS larger than smallest MTU along the
path. However, this increases the unit of error recovery (TCP
segment) above the unit of transmission (IP packet). This is not
recommended, since it can increase the number of retransmitted
packets following loss of a single IP packet, leading to reduced
efficiency, and potentially aggravating network congestion [Ken87].
Choosing an MSS larger than the forward path minimum MTU also permits
the sender to transmit more initial packets (a burst of IP fragments
for each TCP segment) when a session starts or following RTO expiry,
increasing the aggressiveness of the sender compared to standard TCP
[RFC2581]. This can adversely impact other standard TCP sessions
that share a network path.
RECOMMENDATION:
A larger forward path MTU is desirable for paths with bandwidth
asymmetry. Network providers may use a large MTU on links in the
forward direction. TCP end hosts using Path MTU discovery may be
able to take advantage of a large MTU by automatically selecting an
appropriate larger MSS, without requiring modification. The use of
Path MTU discovery [RFC1191] is therefore recommended.
Increasing the unit of error recovery and congestion control (MSS)
above the unit of transmission and congestion loss (the IP packet) by
using a larger end host MSS and IP fragmentation in routers is not
recommended.
Balakrishnan et. al. Best Current Practice [Page 12]
RFC 3449 PILC - Asymmetric Links December 2002
4.3 ACK Congestion Control
ACK Congestion Control (ACC) is an experimental technique that
operates end to end. ACC extends congestion control to ACKs, since
they may make non-negligible demands on resources (e.g., packet
buffers, and MAC transmission overhead) at an upstream bottleneck
link. It has two parts: (a) a network mechanism indicating to the
receiver that the ACK path is congested, and (b) the receiver's
response to such an indication.
A router feeding an upstream bottleneck link may detect incipient
congestion, e.g., using an algorithm based on RED (Random Early
Detection) [FJ93]. This may track the average queue size over a time
window in the recent past. If the average exceeds a threshold, the
router may select a packet at random. If the packet IP header has
the Explicit Congestion Notification Capable Transport (ECT) bit set,
the router may mark the packet, i.e., sets an Explicit Congestion
Notification (ECN) [RFC3168] bit(s) in the IP header, otherwise the
packet is normally dropped. The ECN notification received by the end
host is reflected back to the sending TCP end host, to trigger
congestion avoidance [RFC3168]. Note that routers implementing RED
with ECN, do not eliminate packet loss, and may drop a packet (even
when the ECT bit is set). It is also possible to use an algorithm
other than RED to decide when to set the ECN bit.
ACC extends ECN so that both TCP data packets and ACKs set the ECT
bit and are thus candidates for being marked with an ECN bit.
Therefore, upon receiving an ACK with the ECN bit set [RFC3168], a
TCP receiver reduces the rate at which it sends ACKs. It maintains a
dynamically varying delayed-ACK factor, d, and sends one ACK for
every d data packets received. When it receives a packet with the
ECN bit set, it increases d multiplicatively, thereby
multiplicatively decreasing the frequency of ACKs. For each
subsequent RTT (e.g., determined using the TCP RTTM option [RFC1323])
during which it does not receive an ECN, it linearly decreases the
factor d, increasing the frequency of ACKs. Thus, the receiver
mimics the standard congestion control behavior of TCP senders in the
manner in which it sends ACKs.
The maximum value of d is determined by the TCP sender window size,
which could be conveyed to the receiver in a new (experimental) TCP
option. The receiver should send at least one ACK (preferably more)
for each window of data from the sender (i.e., d < (cwnd/mss)) to
prevent the sender from stalling until the receiver's delayed ACK
timer triggers an ACK to be sent.
Balakrishnan et. al. Best Current Practice [Page 13]
RFC 3449 PILC - Asymmetric Links December 2002
RECOMMENDATION: ACK Congestion Control (ACC) is an experimental
technique that requires TCP sender and receiver modifications. There
is currently little experience of using such techniques in the
Internet. Future versions of TCP may evolve to include this or
similar techniques. These are the subject of ongoing research. ACC
is not recommended for use within the Internet in its current form.
4.4 Window Prediction Mechanism
The Window Prediction Mechanism (WPM) is a TCP receiver side
mechanism [CLP98] that uses a dynamic ACK delay factor (varying d)
resembling the ACC scheme (section 4.3). The TCP receiver
reconstructs the congestion control behavior of the TCP sender by
predicting a cwnd value. This value is used along with the allowed
window to adjust the receiver's value of d. WPM accommodates for
unnecessary retransmissions resulting from losses due to link errors.
RECOMMENDATION: Window Prediction Mechanism (WPM) is an experimental
TCP receiver side modification. There is currently little experience
of using such techniques in the Internet. Future versions of TCP may
evolve to include this or similar techniques. These are the subjects
of ongoing research. WPM is not recommended for use within the
Internet in its current form.
4.5 Acknowledgement based on Cwnd Estimation.
Acknowledgement based on Cwnd Estimation (ACE) [MJW00] attempts to
measure the cwnd at the TCP receiver and maintain a varying ACK delay
factor (d). The cwnd is estimated by counting the number of packets
received during a path RTT. The technique may improve accuracy of
prediction of a suitable cwnd.
RECOMMENDATION: Acknowledgement based on Cwnd Estimation (ACE) is an
experimental TCP receiver side modification. There is currently
little experience of using such techniques in the Internet. Future
versions of TCP may evolve to include this or similar techniques.
These are the subject of ongoing research. ACE is not recommended
for use within the Internet in its current form.
4.6 TCP Sender Pacing
Reducing the frequency of ACKs may alleviate congestion of the
upstream bottleneck link, but can lead to increased size of TCP
sender bursts (section 4.1). This may slow the growth of cwnd, and
is undesirable when used over shared network paths since it may
significantly increase the maximum number of packets in the
bottleneck link buffer, potentially resulting in an increase in
network congestion. This may also lead to ACK Compression [ZSC91].
Balakrishnan et. al. Best Current Practice [Page 14]
RFC 3449 PILC - Asymmetric Links December 2002
TCP Pacing [AST00], generally referred to as TCP Sender pacing,
employs an adapted TCP sender to alleviating transmission burstiness.
A bound is placed on the maximum number of packets the TCP sender can
transmit back-to-back (at local line rate), even if the window(s)
allow the transmission of more data. If necessary, more bursts of
data packets are scheduled for later points in time computed based on
the transmission rate of the TCP connection. The transmission rate
may be estimated from the ratio cwnd/srtt. Thus, large bursts of
data packets get broken up into smaller bursts spread over time.
A subnetwork may also provide pacing (e.g., Generic Traffic Shaping
(GTS)), but implies a significant increase in the per-packet
processing overhead and buffer requirement at the router where
shaping is performed (section 5.3.3).
RECOMMENDATIONS: TCP Sender Pacing requires a change to
implementation of the TCP sender. It may be beneficial in the
Internet and will significantly reduce the burst size of packets
transmitted by a host. This successfully mitigates the impact of
receiving Stretch ACKs. TCP Sender Pacing implies increased
processing cost per packet, and requires a prediction algorithm to
suggest a suitable transmission rate. There are hence performance
trade-offs between end host cost and network performance.
Specification of efficient algorithms remains an area of ongoing
research. Use of TCP Sender Pacing is not expected to introduce new
problems. It is an experimental mitigation for TCP hosts that may
control the burstiness of transmission (e.g., resulting from Type 1
techniques, section 5.1.2), however it is not currently widely
deployed. It is not recommended for use within the Internet in its
current form.
4.7 TCP Byte Counting
The TCP sender can avoid slowing growth of cwnd by taking into
account the volume of data acknowledged by each ACK, rather than
opening the cwnd based on the number of received ACKs. So, if an ACK
acknowledges d data packets (or TCP data segments), the cwnd would
grow as if d separate ACKs had been received. This is called TCP
Byte Counting [RFC2581, RFC2760]. (One could treat the single ACK as
being equivalent to d/2, instead of d ACKs, to mimic the effect of
the TCP delayed ACK algorithm.) This policy works because cwnd
growth is only tied to the available capacity in the forward
direction, so the number of ACKs is immaterial.
This may mitigate the impact of asymmetry when used in combination
with other techniques (e.g., a combination of TCP Pacing
(section4.6), and ACC (section 4.3) associated with a duplicate ACK
threshold at the receiver.)
Balakrishnan et. al. Best Current Practice [Page 15]
RFC 3449 PILC - Asymmetric Links December 2002
The main issue is that TCP byte counting may generate undesirable
long bursts of TCP packets at the sender host line rate. An
implementation must also consider that data packets in the forward
direction and ACKs in the reverse direction may both travel over
network paths that perform some amount of packet reordering.
Reordering of IP packets is currently common, and may arise from
various causes [BPS00].
RECOMMENDATION: TCP Byte Counting requires a small TCP sender
modification. In its simplest form, it can generate large bursts of
TCP data packets, particularly when Stretch ACKs are received.
Unlimited byte counting is therefore not allowed [RFC2581] for use
within the Internet.
It is therefore strongly recommended [RFC2581, RFC2760] that any byte
counting scheme should include a method to mitigate the potentially
large bursts of TCP data packets the algorithm can cause (e.g., TCP
Sender Pacing (section 4.6), ABC [abc-ID]). If the burst size or
sending rate of the TCP sender can be controlled then the scheme may
be beneficial when Stretch ACKs are received. Determining safe
algorithms remain an area of ongoing research. Further
experimentation will then be required to assess the success of these
safeguards, before they can be recommended for use in the Internet.
4.8 Backpressure
Backpressure is a technique to enhance the performance of
bidirectional traffic for end hosts directly connected to the
upstream bottleneck link [KVR98]. A limit is set on how many data
packets of upstream transfers can be enqueued at the upstream
bottleneck link. In other words, the bottleneck link queue exerts
'backpressure' on the TCP (sender) layer. This requires a modified
implementation, compared to that currently deployed in many TCP
stacks. Backpressure ensures that ACKs of downstream connections do
not get starved at the upstream bottleneck, thereby improving
performance of the downstream connections. Similar generic schemes
that may be implemented in hosts/routers are discussed in section
5.4.
Backpressure can be unfair to a reverse direction connection and make
its throughput highly sensitive to the dynamics of the forward
connection(s).
RECOMMENDATION: Backpressure requires an experimental modification to
the sender protocol stack of a host directly connected to an upstream
bottleneck link. Use of backpressure is an implementation issue,
rather than a network protocol issue. Where backpressure is
implemented, the optimizations described in this section could be
Balakrishnan et. al. Best Current Practice [Page 16]
RFC 3449 PILC - Asymmetric Links December 2002
desirable and can benefit bidirectional traffic for hosts.
Specification of safe algorithms for providing backpressure is still
a subject of ongoing research. The technique is not recommended for
use within the Internet in its current form.
5. Improving TCP performance using Transparent Modifications
Various link and network layer techniques have been suggested to
mitigate the effect of an upstream bottleneck link. These techniques
may provide benefit without modification to either the TCP sender or
receiver, or may alternately be used in conjunction with one or more
of the schemes identified in section 4. In this document, these
techniques are known as "transparent" [RFC3135], because at the
transport layer, the TCP sender and receiver are not necessarily
aware of their existence. This does not imply that they do not
modify the pattern and timing of packets as observed at the network
layer. The techniques are classified here into three types based on
the point at which they are introduced.
Most techniques require the individual TCP connections passing over
the bottleneck link(s) to be separately identified and imply that
some per-flow state is maintained for active TCP connections. A link
scheduler may also be employed (section 5.4). The techniques (with
one exception, ACK Decimation (section 5.2.2) require:
(i) Visibility of an unencrypted IP and TCP packet header (e.g., no
use of IPSec with payload encryption [RFC2406]).
(ii) Knowledge of IP/TCP options and ability to inspect packets with
tunnel encapsulations (e.g., [RFC2784]) or to suspend
processing of packets with unknown formats.
(iii) Ability to demultiplex flows (by using address/protocol/port
number, or an explicit flow-id).
[RFC3135] describes a class of network device that provides more than
forwarding of packets, and which is known as a Protocol Enhancing
Proxy (PEP). A large spectrum of PEP devices exists, ranging from
simple devices (e.g., ACK filtering) to more sophisticated devices
(e.g., stateful devices that split a TCP connection into two separate
parts). The techniques described in section 5 of this document
belong to the simpler type, and do not inspect or modify any TCP or
UDP payload data. They also do not modify port numbers or link
addresses. Many of the risks associated with more complex PEPs do
not exist for these schemes. Further information about the operation
and the risks associated with using PEPs are described in [RFC3135].
Balakrishnan et. al. Best Current Practice [Page 17]
RFC 3449 PILC - Asymmetric Links December 2002
5.1 TYPE 0: Header Compression
A client may reduce the volume of bits used to send a single ACK by
using compression [RFC3150, RFC3135]. Most modern dial-up modems
support ITU-T V.42 bulk compression. In contrast to bulk
compression, header compression is known to be very effective at
reducing the number of bits sent on the upstream link [RFC1144]. This
relies on the observation that most TCP packet headers vary only in a
few bit positions between successive packets in a flow, and that the
variations can often be predicted.
5.1.1 TCP Header Compression
TCP header compression [RFC1144] (sometimes known as V-J compression)
is a Proposed Standard describing use over low capacity links running
SLIP or PPP [RFC3150]. It greatly reduces the size of ACKs on the
reverse link when losses are infrequent (a situation that ensures
that the state of the compressor and decompressor are synchronized).
However, this alone does not address all of the asymmetry issues:
(i) In some (e.g., wireless) subnetworks there is a significant
per-packet MAC overhead that is independent of packet size
(section 3.2).
(ii) A reduction in the size of ACKs does not prevent adverse
interaction with large upstream data packets in the presence
of bidirectional traffic (section 3.3).
(iii) TCP header compression cannot be used with packets that have
IP or TCP options (including IPSec [RFC2402, RFC2406], TCP
RTTM [RFC1323], TCP SACK [RFC2018], etc.).
(iv) The performance of header compression described by RFC1144 is
significantly degraded when compressed packets are lost. An
improvement, which can still incur significant penalty on
long network paths is described in [RFC2507]. This suggests
it should only be used on links (or paths) that experience a
low level of packet loss [RFC3150].
(v) The normal implementation of Header Compression inhibits
compression when IP is used to support tunneling (e.g., L2TP,
GRE [RFC2794], IP-in-IP). The tunnel encapsulation
complicates locating the appropriate packet headers. Although
GRE allows Header Compression on the inner (tunneled) IP
header [RFC2784], this is not recommended, since loss of a
packet (e.g., due to router congestion along the tunnel path)
will result in discard of all packets for one RTT [RFC1144].
RECOMMENDATION: TCP Header Compression is a transparent modification
performed at both ends of the upstream bottleneck link. It offers no
benefit for flows employing IPSec [RFC2402, RFC2406], or when
additional protocol headers are present (e.g., IP or TCP options,
Balakrishnan et. al. Best Current Practice [Page 18]
RFC 3449 PILC - Asymmetric Links December 2002
and/or tunnel encapsulation headers). The scheme is widely
implemented and deployed and used over Internet links. It is
recommended to improve TCP performance for paths that have a low-to-
medium bandwidth asymmetry (e.g., k<10).
In the form described in [RFC1144], TCP performance is degraded when
used over links (or paths) that may exhibit appreciable rates of
packet loss [RFC3150]. It may also not provide significant
improvement for upstream links with bidirectional traffic. It is
therefore not desirable for paths that have a high bandwidth
asymmetry (e.g., k>10).
5.1.2 Alternate Robust Header Compression Algorithms
TCP header compression [RFC1144] and IP header compression [RFC2507]
do not perform well when subject to packet loss. Further, they do
not compress packets with TCP option fields (e.g., SACK [RFC2018] and
Timestamp (RTTM) [RFC1323]). However, recent work on more robust
schemes suggest that a new generation of compression algorithms may
be developed which are much more robust. The IETF ROHC working group
has specified compression techniques for UDP-based traffic [RFC3095]
and is examining a number of schemes that may provide improve TCP
header compression. These could be beneficial for asymmetric network
paths.
RECOMMENDATION: Robust header compression is a transparent
modification that may be performed at both ends of an upstream
bottleneck link. This class of techniques may also be suited to
Internet paths that suffer low levels of re-ordering. The techniques
benefit paths with a low-to-medium bandwidth asymmetry (e.g., k>10)
and may be robust to packet loss.
Selection of suitable compression algorithms remains an area of
ongoing research. It is possible that schemes may be derived which
support IPSec authentication, but not IPSec payload encryption. Such
schemes do not alone provide significant improvement in asymmetric
networks with a high asymmetry and/or bidirectional traffic.
5.2 TYPE 1: Reverse Link Bandwidth Management
Techniques beyond Type 0 header compression are required to address
the performance problems caused by appreciable asymmetry (k>>1). One
set of techniques is implemented only at one point on the reverse
direction path, within the router/host connected to the upstream
bottleneck link. These use flow class or per-flow queues at the
upstream link interface to manage the queue of packets waiting for
transmission on the bottleneck upstream link.
Balakrishnan et. al. Best Current Practice [Page 19]
RFC 3449 PILC - Asymmetric Links December 2002
This type of technique bounds the upstream link buffer queue size,
and employs an algorithm to remove (discard) excess ACKs from each
queue. This relies on the cumulative nature of ACKs (section 4.1).
Two approaches are described which employ this type of mitigation.
5.2.1 ACK Filtering
ACK Filtering (AF) [DMT96, BPK99] (also known as ACK Suppression
[SF98, Sam99, FSS01]) is a TCP-aware link-layer technique that
reduces the number of ACKs sent on the upstream link. This technique
has been deployed in specific production networks (e.g., asymmetric
satellite networks [ASB96]). The challenge is to ensure that the
sender does not stall waiting for ACKs, which may happen if ACKs are
indiscriminately removed.
When an ACK from the receiver is about to be enqueued at a upstream
bottleneck link interface, the router or the end host link layer (if
the host is directly connected to the upstream bottleneck link)
checks the transmit queue(s) for older ACKs belonging to the same TCP
connection. If ACKs are found, some (or all of them) are removed
from the queue, reducing the number of ACKs.
Some ACKs also have other functions in TCP [RFC1144], and should not
be deleted to ensure normal operation. AF should therefore not
delete an ACK that has any data or TCP flags set (SYN, RST, URG, and
FIN). In addition, it should avoid deleting a series of 3 duplicate
ACKs that indicate the need for Fast Retransmission [RFC2581] or ACKs
with the Selective ACK option (SACK)[RFC2018] from the queue to avoid
causing problems to TCP's data-driven loss recovery mechanisms.
Appropriate treatment is also needed to preserve correct operation of
ECN feedback (carried in the TCP header) [RFC3168].
A range of policies to filter ACKs may be used. These may be either
deterministic or random (similar to a random-drop gateway, but should
take into consideration the semantics of the items in the queue).
Algorithms have also been suggested to ensure a minimum ACK rate to
guarantee the TCP sender window is updated [Sam99, FSS01], and to
limit the number of data packets (TCP segments) acknowledged by a
Stretch ACK. Per-flow state needs to be maintained only for
connections with at least one packet in the queue (similar to FRED
[LM97]). This state is soft [Cla88], and if necessary, can easily be
reconstructed from the contents of the queue.
The undesirable effect of delayed DupACKs (section 3.4) can be
reduced by deleting duplicate ACKs above a threshold value [MJW00,
CLP98] allowing Fast Retransmission, but avoiding early TCP timeouts,
which may otherwise result from excessive queuing of DupACKs.
Balakrishnan et. al. Best Current Practice [Page 20]
RFC 3449 PILC - Asymmetric Links December 2002
Future schemes may include more advanced rules allowing removal of
selected SACKs [RFC2018]. Such a scheme could prevent the upstream
link queue from becoming filled by back-to-back ACKs with SACK
blocks. Since a SACK packet is much larger than an ACK, it would
otherwise add significantly to the path delay in the reverse
direction. Selection of suitable algorithms remains an ongoing area
of research.
RECOMMENDATION: ACK Filtering requires a modification to the upstream
link interface. The scheme has been deployed in some networks where
the extra processing overhead (per ACK) may be compensated for by
avoiding the need to modify TCP. ACK Filtering can generate Stretch
ACKs resulting in large bursts of TCP data packets. Therefore on its
own, it is not recommended for use in the general Internet.
ACK Filtering when used in combination with a scheme to mitigate the
effect of Stretch ACKs (i.e., control TCP sender burst size) is
recommended for paths with appreciable asymmetry (k>1) and/or with
bidirectional traffic. Suitable algorithms to support IPSec
authentication, SACK, and ECN remain areas of ongoing research.
5.2.2 ACK Decimation
ACK Decimation is based on standard router mechanisms. By using an
appropriate configuration of (small) per-flow queues and a chosen
dropping policy (e.g., Weighted Fair Queuing, WFQ) at the upstream
bottleneck link, a similar effect to AF (section 5.2.1) may be
obtained, but with less control of the actual packets which are
dropped.
In this scheme, the router/host at the bottleneck upstream link
maintains per-flow queues and services them fairly (or with
priorities) by queuing and scheduling of ACKs and data packets in the
reverse direction. A small queue threshold is maintained to drop
excessive ACKs from the tail of each queue, in order to reduce ACK
Congestion. The inability to identify special ACK packets (c.f., AF)
introduces some major drawbacks to this approach, such as the
possibility of losing DupACKs, FIN/ACK, RST packets, or packets
carrying ECN information [RFC3168]. Loss of these packets does not
significantly impact network congestion, but does adversely impact
the performance of the TCP session observing the loss.
A WFQ scheduler may assign a higher priority to interactive traffic
(providing it has a mechanism to identify such traffic) and provide a
fair share of the remaining capacity to the bulk traffic. In the
presence of bidirectional traffic, and with a suitable scheduling
policy, this may ensure fairer sharing for ACK and data packets. An
increased forward transmission rate is achieved over asymmetric links
Balakrishnan et. al. Best Current Practice [Page 21]
RFC 3449 PILC - Asymmetric Links December 2002
by an increased ACK Decimation rate, leading to generation of Stretch
ACKs. As in AF, TCP sender burst size increases when Stretch ACKs
are received unless other techniques are used in combination with
this technique.
This technique has been deployed in specific networks (e.g., a
network with high bandwidth asymmetry supporting high-speed data
services to in-transit mobile hosts [Seg00]). Although not optimal,
it offered a potential mitigation applicable when the TCP header is
difficult to identify or not visible to the link layer (e.g., due to
IPSec encryption).
RECOMMENDATION: ACK Decimation uses standard router mechanisms at the
upstream link interface to constrain the rate at which ACKs are fed
to the upstream link. The technique is beneficial with paths having
appreciable asymmetry (k>1). It is however suboptimal, in that it
may lead to inefficient TCP error recovery (and hence in some cases
degraded TCP performance), and provides only crude control of link
behavior. It is therefore recommended that where possible, ACK
Filtering should be used in preference to ACK Decimation.
When ACK Decimation is used on paths with an appreciable asymmetry
(k>1) (or with bidirectional traffic) it increases the burst size of
the TCP sender, use of a scheme to mitigate the effect of Stretch
ACKs or control burstiness is therefore strongly recommended.
5.3 TYPE 2: Handling Infrequent ACKs
TYPE 2 mitigations perform TYPE 1 upstream link bandwidth management,
but also employ a second active element which mitigates the effect of
the reduced ACK rate and burstiness of ACK transmission. This is
desirable when end hosts use standard TCP sender implementations
(e.g., those not implementing the techniques in sections 4.6, 4.7).
Consider a path where a TYPE 1 scheme forwards a Stretch ACK covering
d TCP packets (i.e., where the acknowledgement number is d*MSS larger
than the last ACK received by the TCP sender). When the TCP sender
receives this ACK, it can send a burst of d (or d+1) TCP data
packets. The sender is also constrained by the current cwnd.
Received ACKs also serve to increase cwnd (by at most one MSS).
A TYPE 2 scheme mitigates the impact of the reduced ACK frequency
resulting when a TYPE 1 scheme is used. This is achieved by
interspersing additional ACKs before each received Stretch ACK. The
additional ACKs, together with the original ACK, provide the TCP
sender with sufficient ACKs to allow the TCP cwnd to open in the same
way as if each of the original ACKs sent by the TCP receiver had been
forwarded by the reverse path. In addition, by attempting to restore
Balakrishnan et. al. Best Current Practice [Page 22]
RFC 3449 PILC - Asymmetric Links December 2002
the spacing between ACKs, such a scheme can also restore the TCP
self-clocking behavior, and reduce the TCP sender burst size. Such
schemes need to ensure conservative behavior (i.e., should not
introduce more ACKs than were originally sent) and reduce the
probability of ACK Compression [ZSC91].
The action is performed at two points on the return path: the
upstream link interface (where excess ACKs are removed), and a point
further along the reverse path (after the bottleneck upstream
link(s)), where replacement ACKs are inserted. This attempts to
reconstruct the ACK stream sent by the TCP receiver when used in
combination with AF (section 5.2.1), or ACK Decimation (section
5.2.2).
TYPE 2 mitigations may be performed locally at the receive interface
directly following the upstream bottleneck link, or may alternatively
be applied at any point further along the reverse path (this is not
necessarily on the forward path, since asymmetric routing may employ
different forward and reverse internet paths). Since the techniques
may generate multiple ACKs upon reception of each individual Stretch
ACK, it is strongly recommended that the expander implements a scheme
to prevent exploitation as a "packet amplifier" in a Denial-of-
Service (DoS) attack (e.g., to verify the originator of the ACK).
Identification of the sender could be accomplished by appropriately
configured packet filters and/or by tunnel authentication procedures
(e.g., [RFC2402, RFC2406]). A limit on the number of reconstructed
ACKs that may be generated from a single packet may also be
desirable.
5.3.1 ACK Reconstruction
ACK Reconstruction (AR) [BPK99] is used in conjunction with AF
(section 5.2.1). AR deploys a soft-state [Cla88] agent called an ACK
Reconstructor on the reverse path following the upstream bottleneck
link. The soft-state can be regenerated if lost, based on received
ACKs. When a Stretch ACK is received, AR introduces additional ACKs
by filling gaps in the ACK sequence. Some potential Denial-of-
Service vulnerabilities may arise (section 6) and need to be
addressed by appropriate security techniques.
The Reconstructor determines the number of additional ACKs, by
estimating the number of filtered ACKs. This uses implicit
information present in the received ACK stream by observing the ACK
sequence number of each received ACK. An example implementation
could set an ACK threshold, ackthresh, to twice the MSS (this assumes
the chosen MSS is known by the link). The factor of two corresponds
Balakrishnan et. al. Best Current Practice [Page 23]
RFC 3449 PILC - Asymmetric Links December 2002
to standard TCP delayed-ACK policy (d=2). Thus, if successive ACKs
arrive separated by delta, the Reconstructor regenerates a maximum of
((delta/ackthresh) - 2) ACKs.
To reduce the TCP sender burst size and allow the cwnd to increase at
a rate governed by the downstream link, the reconstructed ACKs must
be sent at a consistent rate (i.e., temporal spacing between
reconstructed ACKs). One method is for the Reconstructor to measure
the arrival rate of ACKs using an exponentially weighted moving
average estimator. This rate depends on the output rate from the
upstream link and on the presence of other traffic sharing the link.
The output of the estimator indicates the average temporal spacing
for the ACKs (and the average rate at which ACKs would reach the TCP
sender if there were no further losses or delays). This may be used
by the Reconstructor to set the temporal spacing of reconstructed
ACKs. The scheme may also be used in combination with TCP sender
adaptation (e.g., a combination of the techniques in sections 4.6 and
4.7).
The trade-off in AR is between obtaining less TCP sender burstiness,
and a better rate of cwnd increase, with a reduction in RTT
variation, versus a modest increase in the path RTT. The technique
cannot perform reconstruction on connections using IPSec (AH
[RFC2402] or ESP [RFC2406]), since it is unable to generate
appropriate security information. It also cannot regenerate other
packet header information (e.g., the exact pattern of bits carried in
the IP packet ECN field [RFC3168] or the TCP RTTM option [RFC1323]).
An ACK Reconstructor operates correctly (i.e., generates no spurious
ACKs and preserves the end-to-end semantics of TCP), providing:
(i) the TCP receiver uses ACK Delay (d=2) [RFC2581]
(ii) the Reconstructor receives only in-order ACKs
(iii) all ACKs are routed via the Reconstructor
(iv) the Reconstructor correctly determines the TCP MSS used by
the session
(v) the packets do not carry additional header information (e.g.,
TCP RTTM option [RFC1323], IPSec using AH [RFC2402]or ESP
[RFC2406]).
RECOMMENDATION: ACK Reconstruction is an experimental transparent
modification performed on the reverse path following the upstream
bottleneck link. It is designed to be used in conjunction with a
TYPE 1 mitigation. It reduces the burst size of TCP transmission in
the forward direction, which may otherwise increase when TYPE 1
schemes are used alone. It requires modification of equipment after
the upstream link (including maintaining per-flow soft state). The
scheme introduces implicit assumptions about the network path and has
Balakrishnan et. al. Best Current Practice [Page 24]
RFC 3449 PILC - Asymmetric Links December 2002
potential Denial-of-Service vulnerabilities (i.e., acting as a packet
amplifier); these need to be better understood and addressed by
appropriate security techniques.
Selection of appropriate algorithms to pace the ACK traffic remains
an open research issue. There is also currently little experience of
the implications of using such techniques in the Internet, and
therefore it is recommended that this technique should not be used
within the Internet in its current form.
5.3.2 ACK Compaction and Companding
ACK Compaction and ACK Companding [SAM99, FSS01] are techniques that
operate at a point on the reverse path following the constrained ACK
bottleneck. Like AR (section 5.3.1), ACK Compaction and ACK
Companding are both used in conjunction with an AF technique (section
5.2.1) and regenerate filtered ACKs, restoring the ACK stream.
However, they differ from AR in that they use a modified AF (known as
a compactor or compressor), in which explicit information is added to
all Stretch ACKs generated by the AF. This is used to explicitly
synchronize the reconstruction operation (referred to here as
expansion).
The modified AF combines two modifications: First, when the
compressor deletes an ACK from the upstream bottleneck link queue, it
appends explicit information (a prefix) to the remaining ACK (this
ACK is marked to ensure it is not subsequently deleted). The
additional information contains details the conditions under which
ACKs were previously filtered. A variety of information may be
encoded in the prefix. This includes the number of ACKs deleted by
the AF and the average number of bytes acknowledged. This may
subsequently be used by an expander at the remote end of the tunnel.
Further timing information may also be added to control the pacing of
the regenerated ACKs [FSS01]. The temporal spacing of the filtered
ACKs may also be encoded.
To encode the prefix requires the subsequent expander to recognize a
modified ACK header. This would normally limit the expander to
link-local operation (at the receive interface of the upstream
bottleneck link). If remote expansion is needed further along the
reverse path, a tunnel may be used to pass the modified ACKs to the
remote expander. The tunnel introduces extra overhead, however
networks with asymmetric capacity and symmetric routing frequently
already employ such tunnels (e.g., in a UDLR network [RFC3077], the
expander may be co-located with the feed router).
Balakrishnan et. al. Best Current Practice [Page 25]
RFC 3449 PILC - Asymmetric Links December 2002
ACK expansion uses a stateless algorithm to expand the ACK (i.e.,
each received packet is processed independently of previously
received packets). It uses the prefix information together with the
acknowledgment field in the received ACK, to produce an equivalent
number of ACKs to those previously deleted by the compactor. These
ACKs are forwarded to the original destination (i.e., the TCP
sender), preserving normal TCP ACK clocking. In this way, ACK
Compaction, unlike AR, is not reliant on specific ACK policies, nor
must it see all ACKs associated with the reverse path (e.g., it may
be compatible with schemes such as DAASS [RFC2760]).
Some potential Denial-of-Service vulnerabilities may arise (section
6) and need to be addressed by appropriate security techniques. The
technique cannot perform reconstruction on connections using IPSec,
since they are unable to regenerate appropriate security information.
It is possible to explicitly encode IPSec security information from
suppressed packets, allowing operation with IPSec AH, however this
remains an open research issue, and implies an additional overhead
per ACK.
RECOMMENDATION: ACK Compaction and Companding are experimental
transparent modifications performed on the reverse path following the
upstream bottleneck link. They are designed to be used in
conjunction with a modified TYPE 1 mitigation and reduce the burst
size of TCP transmission in the forward direction, which may
otherwise increase when TYPE 1 schemes are used alone.
The technique is desirable, but requires modification of equipment
after the upstream bottleneck link (including processing of a
modified ACK header). Selection of appropriate algorithms to pace
the ACK traffic also remains an open research issue. Some potential
Denial-of-Service vulnerabilities may arise with any device that may
act as a packet amplifier. These need to be addressed by appropriate
security techniques. There is little experience of using the scheme
over Internet paths. This scheme is a subject of ongoing research
and is not recommended for use within the Internet in its current
form.
5.3.3 Mitigating TCP packet bursts generated by Infrequent ACKs
The bursts of data packets generated when a Type 1 scheme is used on
the reverse direction path may be mitigated by introducing a router
supporting Generic Traffic Shaping (GTS) on the forward path [Seg00].
GTS is a standard router mechanism implemented in many deployed
routers. This technique does not eliminate the bursts of data
generated by the TCP sender, but attempts to smooth out the bursts by
employing scheduling and queuing techniques, producing traffic which
resembles that when TCP Pacing is used (section 4.6). These
Balakrishnan et. al. Best Current Practice [Page 26]
RFC 3449 PILC - Asymmetric Links December 2002
techniques require maintaining per-flow soft-state in the router, and
increase per-packet processing overhead. Some additional buffer
capacity is needed to queue packets being shaped.
To perform GTS, the router needs to select appropriate traffic
shaping parameters, which require knowledge of the network policy,
connection behavior and/or downstream bottleneck characteristics. GTS
may also be used to enforce other network policies and promote
fairness between competing TCP connections (and also UDP and
multicast flows). It also reduces the probability of ACK Compression
[ZSC91].
The smoothing of packet bursts reduces the impact of the TCP
transmission bursts on routers and hosts following the point at which
GTS is performed. It is therefore desirable to perform GTS near to
the sending host, or at least at a point before the first forward
path bottleneck router.
RECOMMENDATIONS: Generic Traffic Shaping (GTS) is a transparent
technique employed at a router on the forward path. The algorithms
to implement GTS are available in widely deployed routers and may be
used on an Internet link, but do imply significant additional per-
packet processing cost.
Configuration of a GTS is a policy decision of a network service
provider. When appropriately configured the technique will reduce
size of TCP data packet bursts, mitigating the effects of Type 1
techniques. GTS is recommended for use in the Internet in
conjunction with type 1 techniques such as ACK Filtering (section
5.2.1) and ACK Decimation (section 5.2.2).
5.4 TYPE 3: Upstream Link Scheduling
Many of the above schemes imply using per flow queues (or per
connection queues in the case of TCP) at the upstream bottleneck
link. Per-flow queuing (e.g., FQ, CBQ) offers benefit when used on
any slow link (where the time to transmit a packet forms an
appreciable part of the path RTT) [RFC3150]. Type 3 schemes offer
additional benefit when used with one of the above techniques.
5.4.1 Per-Flow queuing at the Upstream Bottleneck Link
When bidirectional traffic exists in a bandwidth asymmetric network
competing ACK and packet data flows along the return path may degrade
the performance of both upstream and downstream flows [KVR98].
Therefore, it is highly desirable to use a queuing strategy combined
with a scheduling mechanism at the upstream link. This has also been
called priority-based multiplexing [RFC3135].
Balakrishnan et. al. Best Current Practice [Page 27]
RFC 3449 PILC - Asymmetric Links December 2002
On a slow upstream link, appreciable jitter may be introduced by
sending large data packets ahead of ACKs [RFC3150]. A simple scheme
may be implemented using per-flow queuing with a fair scheduler
(e.g., round robin service to all flows, or priority scheduling). A
modified scheduler [KVR98] could place a limit on the number of ACKs
a host is allowed to transmit upstream before transmitting a data
packet (assuming at least one data packet is waiting in the upstream
link queue). This guarantees at least a certain minimum share of the
capacity to flows in the reverse direction, while enabling flows in
the forward direction to improve TCP throughput.
Bulk (payload) compression, a small MTU, link level transparent
fragmentation [RFC1991, RFC2686] or link level suspend/resume
capability (where higher priority frames may pre-empt transmission of
lower priority frames) may be used to mitigate the impact (jitter) of
bidirectional traffic on low speed links [RFC3150]. More advanced
schemes (e.g., WFQ) may also be used to improve the performance of
transfers with multiple ACK streams such as http [Seg00].
RECOMMENDATION: Per-flow queuing is a transparent modification
performed at the upstream bottleneck link. Per-flow (or per-class)
scheduling does not impact the congestion behavior of the Internet,
and may be used on any Internet link. The scheme has particular
benefits for slow links. It is widely implemented and widely
deployed on links operating at less than 2 Mbps. This is recommended
as a mitigation on its own or in combination with one of the other
described techniques.
5.4.2 ACKs-first Scheduling
ACKs-first Scheduling is an experimental technique to improve
performance of bidirectional transfers. In this case data packets
and ACKs compete for resources at the upstream bottleneck link
[RFC3150]. A single First-In First-Out, FIFO, queue for both data
packets and ACKs could impact the performance of forward transfers.
For example, if the upstream bottleneck link is a 28.8 kbps dialup
line, the transmission of a 1 Kbyte sized data packet would take
about 280 ms. So even if just two such data packets get queued ahead
of ACKs (not an uncommon occurrence since data packets are sent out
in pairs during slow start), they would shut out ACKs for well over
half a second. If more than two data packets are queued up ahead of
an ACK, the ACKs would be delayed by even more [RFC3150].
A possible approach to alleviating this is to schedule data and ACKs
differently from FIFO. One algorithm, in particular, is ACKs-first
scheduling, which accords a higher priority to ACKs over data
packets. The motivation for such scheduling is that it minimizes the
idle time for the forward connection by minimizing the time that ACKs
Balakrishnan et. al. Best Current Practice [Page 28]
RFC 3449 PILC - Asymmetric Links December 2002
spend queued behind data packets at the upstream link. At the same
time, with Type 0 techniques such as header compression [RFC1144],
the transmission time of ACKs becomes small enough that the impact on
subsequent data packets is minimal. (Subnetworks in which the per-
packet overhead of the upstream link is large, e.g., packet radio
subnetworks, are an exception, section 3.2.) This scheduling scheme
does not require the upstream bottleneck router/host to explicitly
identify or maintain state for individual TCP connections.
ACKs-first scheduling does not help avoid a delay due to a data
packet in transmission. Link fragmentation or suspend/resume may be
beneficial in this case.
RECOMMENDATION: ACKs-first scheduling is an experimental transparent
modification performed at the upstream bottleneck link. If it is
used without a mechanism (such as ACK Congestion Control (ACC),
section 4.3) to regulate the volume of ACKs, it could lead to
starvation of data packets. This is a performance penalty
experienced by end hosts using the link and does not modify Internet
congestion behavior. Experiments indicate that ACKs-first scheduling
in combination with ACC is promising. However, there is little
experience of using the technique in the wider Internet. Further
development of the technique remains an open research issue, and
therefore the scheme is not currently recommended for use within the
Internet.
6. Security Considerations
The recommendations contained in this document do not impact the
integrity of TCP, introduce new security implications to the TCP
protocol, or applications using TCP.
Some security considerations in the context of this document arise
from the implications of using IPSec by the end hosts or routers
operating along the return path. Use of IPSec prevents, or
complicates, some of the mitigations. For example:
(i) When IPSec ESP [RFC2406] is used to encrypt the IP payload, the
TCP header can neither be read nor modified by intermediate
entities. This rules out header compression, ACK Filtering, ACK
Reconstruction, and the ACK Compaction.
(ii) The TCP header information may be visible, when some forms of
network layer security are used. For example, using IPSec AH
[RFC2402], the TCP header may be read, but not modified, by
intermediaries. This may in future allow extensions to support
ACK Filtering, but rules out the generation of new
Balakrishnan et. al. Best Current Practice [Page 29]
RFC 3449 PILC - Asymmetric Links December 2002
packets by intermediaries (e.g., ACK Reconstruction). The
enhanced header compression scheme discussed in [RFC2507] would
also work with IPSec AH.
There are potential Denial-of-Service (DoS) implications when using
Type 2 schemes. Unless additional security mechanisms are used, a
Reconstructor/expander could be exploited as a packet amplifier. A
third party may inject unauthorized Stretch ACKs into the reverse
path, triggering the generation of additional ACKs. These ACKs would
consume capacity on the return path and processing resources at the
systems along the path, including the destination host. This
provides a potential platform for a DoS attack. The usual
precautions must be taken to verify the correct tunnel end point, and
to ensure that applications cannot falsely inject packets that expand
to generate unwanted traffic. Imposing a rate limit and bound on the
delayed ACK factor(d) would also lessen the impact of any undetected
exploitation.
7. Summary
This document considers several TCP performance constraints that
arise from asymmetry in the properties of the forward and reverse
paths across an IP network. Such performance constraints arise,
e.g., as a result of both bandwidth (capacity) asymmetry, asymmetric
shared media in the reverse direction, and interactions with Media
Access Control (MAC) protocols. Asymmetric capacity may cause TCP
Acknowledgments (ACKs) to be lost or become inordinately delayed
(e.g., when a bottleneck link is shared between many flows, or when
there is bidirectional traffic). This effect may be exacerbated with
media-access delays (e.g., in certain multi-hop radio subnetworks,
satellite Bandwidth on Demand access). Asymmetry, and particular
high asymmetry, raises a set of TCP performance issues.
A set of techniques providing performance improvement is surveyed.
These include techniques to alleviate ACK Congestion and techniques
that enable a TCP sender to cope with infrequent ACKs without
destroying TCP self-clocking. These techniques include both end-to-
end, local link-layer, and subnetwork schemes. Many of these
techniques have been evaluated in detail via analysis, simulation,
and/or implementation on asymmetric subnetworks forming part of the
Internet. There is however as yet insufficient operational
experience for some techniques, and these therefore currently remain
items of on-going research and experimentation.
Balakrishnan et. al. Best Current Practice [Page 30]
RFC 3449 PILC - Asymmetric Links December 2002
The following table summarizes the current recommendations.
Mechanisms are classified as recommended (REC), not recommended (NOT
REC) or experimental (EXP). Experimental techniques may not be well
specified. These techniques will require further operational
experience before they can be recommended for use in the public
Internet.
The recommendations for end-to-end host modifications are summarized
in table 1. This lists each technique, the section in which each
technique is discussed, and where it is applied (S denotes the host
sending TCP data packets in the forward direction, R denotes the host
which receives these data packets).
+------------------------+-------------+------------+--------+
| Technique | Use | Section | Where |
+------------------------+-------------+------------+--------+
| 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 |
+------------------------+-------------+------------+--------+
Table 1: Recommendations concerning host modifications.
*1 Implementation of the technique may require changes to the
internal design of the protocol stack in end hosts.
*2 Dependent on a scheme for preventing excessive TCP transmission
burst.
The recommendations for techniques that do not require the TCP sender
and receiver to be aware of their existence (i.e., transparent
techniques) are summarized in table 2. Each technique is listed
along with the section in which each mechanism is discussed, and
where the technique is applied (S denotes the sending interface prior
to the upstream bottleneck link, R denotes receiving interface
following the upstream bottleneck link).
Balakrishnan et. al. Best Current Practice [Page 31]
RFC 3449 PILC - Asymmetric Links December 2002
+------------------------+-------------+------------+--------+
| Mechanism | Use | Section | Type |
+------------------------+-------------+------------+--------+
| 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 |
+------------------------+-------------+------------+--------+
Table 2: Recommendations concerning transparent modifications.
*1 At high asymmetry these schemes may degrade TCP performance, but
are not considered harmful to the Internet.
*2 Standardisation of new TCP compression protocols is the subject of
ongoing work within the ROHC WG, refer to other IETF RFCs on the
use of these techniques.
*3 Use in the Internet is dependent on a scheme for preventing
excessive TCP transmission burst.
*4 Performed at a point along the reverse path after the upstream
bottleneck link.
*5 Performed at a point along the forward path.
8. Acknowledgments
This document has benefited from comments from the members of the
Performance Implications of Links (PILC) Working Group. In
particular, the authors would like to thank John Border, Spencer
Dawkins, Aaron Falk, Dan Grossman, Randy Katz, Jeff Mandin, Rod
Ragland, Ramon Segura, Joe Touch, and Lloyd Wood for their useful
comments. They also acknowledge the data provided by Metricom Inc.,
concerning operation of their packet data network.
9. References
References of the form RFCnnnn are Internet Request for Comments
(RFC) documents available online at http://www.rfc-editor.org/.
Balakrishnan et. al. Best Current Practice [Page 32]
RFC 3449 PILC - Asymmetric Links December 2002
9.1 Normative References
[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 Informative References
[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.
Balakrishnan et. al. Best Current Practice [Page 33]
RFC 3449 PILC - Asymmetric Links December 2002
[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.
Balakrishnan et. al. Best Current Practice [Page 34]
RFC 3449 PILC - Asymmetric Links December 2002
[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.
Balakrishnan et. al. Best Current Practice [Page 35]
RFC 3449 PILC - Asymmetric Links December 2002
[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.
Balakrishnan et. al. Best Current Practice [Page 36]
RFC 3449 PILC - Asymmetric Links December 2002
[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 Considerations
There are no IANA considerations associated with this document.
Balakrishnan et. al. Best Current Practice [Page 37]
RFC 3449 PILC - Asymmetric Links December 2002
Appendix - Examples of Subnetworks Exhibiting Network Path Asymmetry
This appendix provides a list of some subnetworks which are known to
experience network path asymmetry. The asymmetry in capacity of
these network paths can require mitigations to provide acceptable
overall performance. Examples include the following:
- IP service over some wide area and local area wireless networks.
In such networks, the predominant network path asymmetry arises
from the hub-and-spokes architecture of the network (e.g., a
single base station that communicates with multiple mobile
stations), this requires a Ready To Send / Clear To Send (RTS/CTS)
protocol and a Medium Access Control (MAC) protocol which needs to
accommodate the significant turn-around time for the radios. A
high per-packet transmission overhead may lead to significant
network path asymmetry.
- IP service over a forward satellite link utilizing Digital Video
Broadcast (DVB) transmission [EN97] (e.g., 38-45 Mbps), and a
slower upstream link using terrestrial network technology (e.g.,
dial-up modem, line of sight microwave, cellular radio) [CLC99].
Network path asymmetry arises from a difference in the upstream
and downstream link capacities.
- Certain military networks [KSG98] providing Internet access to
in-transit or isolated hosts [Seg00] using a high capacity
downstream satellite link (e.g., 2-3 Mbps) with a narrowband
upstream link (e.g., 2.4-9.6 kbps) using either Demand Assigned
Multiple Access (DAMA) or fixed rate satellite links. The main
factor contributing to network path asymmetry is the difference in
the upstream and downstream link capacities. Some differences
between forward and reverse paths may arise from the way in which
upstream link capacity is allocated.
- Most data over cable TV networks (e.g., DOCSIS [ITU01, DS00]),
where the analogue channels assigned for upstream communication
(i.e., in the reverse direction) are narrower and may be more
noisy than those assigned for the downstream link. As a
consequence, the upstream and downstream links differ in their
transmission rate. For example, in DOCSIS 1.0 [DS00], the
downstream transmission rate is either 27 or 52 Mbps. Upstream
transmission rates may be dynamically selected to be one of a
series of rates which range between 166 kbps to 9 Mbps. Operators
may assign multiple upstream channels per downstream channel.
Physical layer (PHY) overhead (which accompanies upstream
transmissions, but is not present in the downstream link) can also
increase the network path asymmetry. The Best Effort service,
which is typically used to carry TCP, uses a
Balakrishnan et. al. Best Current Practice [Page 38]
RFC 3449 PILC - Asymmetric Links December 2002
contention/reservation MAC protocol. A cable modem (CM) sending
an isolated packet (such as a TCP ACK) on the upstream link must
contend with other CMs to request capacity from the central cable
modem termination system (CMTS). The CMTS then grants timeslots
to a CM for the upstream transmission. The CM may "piggyback"
subsequent requests onto upstream packets, avoiding contention
cycles; as a result, spacing of TCP ACKs can be dramatically
altered due to minor variations in load of the cable data network
and inter-arrival times of TCP DATA packets. Numerous other
complexities may add to, or mitigate, the asymmetry in rate and
access latency experienced by packets sent on the upstream link
relative to downstream packets in DOCSIS. The asymmetry
experienced by end hosts may also change dynamically (e.g., with
network load), and when best effort services share capacity with
services that have symmetric reserved capacity (e.g., IP telephony
over the Unsolicited Grant service) [ITU01].
- Asymmetric Digital Subscriber Line (ADSL), by definition, offers a
downstream link transmission rate that is higher than that of the
upstream link. The available rates depend upon channel quality
and system configuration. For example, one widely deployed ADSL
technology [ITU02, ANS01] operates at rates that are multiples of
32 kbps (up to 6.144 Mbps) in the downstream link, and up to 640
kbps for the upstream link. The network path asymmetry
experienced by end hosts may be further increased when best effort
services, e.g., Internet access over ADSL, share the available
upstream capacity with reserved services (e.g., constant bit rate
voice telephony).
Balakrishnan et. al. Best Current Practice [Page 39]
RFC 3449 PILC - Asymmetric Links December 2002
Authors' Addresses
Hari Balakrishnan
Laboratory for Computer Science
200 Technology Square
Massachusetts Institute of Technology
Cambridge, MA 02139
USA
Phone: +1-617-253-8713
EMail: hari@lcs.mit.edu
Web: http://nms.lcs.mit.edu/~hari/
Venkata N. Padmanabhan
Microsoft Research
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1-425-705-2790
EMail: padmanab@microsoft.com
Web: http://www.research.microsoft.com/~padmanab/
Godred Fairhurst
Department of Engineering
Fraser Noble Building
University of Aberdeen
Aberdeen AB24 3UE
UK
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Mahesh Sooriyabandara
Department of Engineering
Fraser Noble Building
University of Aberdeen
Aberdeen AB24 3UE
UK
EMail: mahesh@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/mahesh
Balakrishnan et. al. Best Current Practice [Page 40]
RFC 3449 PILC - Asymmetric Links December 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Balakrishnan et. al. Best Current Practice [Page 41]