О документе
Рабочая группа Network Working Group S. Dawkins
Запрос комментариев: 3155 G. Montenegro
BCP: 50 M. Kojo
Категория: Лучшая современная практика V. Magret
N. Vaidya
август 2001 г.
Влияние каналов с ошибками на сквозную производительность
1.0 Введение
Доступ к быстро растущему Интернету осуществляется со всё более
широкого набора устройств по всё более разнообразным каналам. По
крайней мере некоторые из этих каналов не обеспечивают ту степень
надёжности, которую ожидают хосты, и это расширение в сторону
ненадёжных каналов приводит к тому, что некоторые интернет-протоколы,
особенно TCP [RFC793], работают плохо.
В частности, управление перегрузкой TCP [RFC2581], хотя и пригодно для
соединений, теряющих трафик преимущественно из-за перегрузки и
исчерпания буферов, плохо взаимодействует с неисправленными ошибками,
когда TCP-соединения проходят через каналы с высокой частотой
неисправленных ошибок. В результате отправляющие TCP могут тратить
чрезмерное количество времени на ожидание подтверждений, которые не
поступают, а затем, хотя эти потери не вызваны исчерпанием буферов,
связанным с перегрузкой, отправляющий TCP передаёт трафик на
существенно сниженном уровне, исследуя сеть для определения
«безопасных» уровней трафика.
Этот документ не рассматривает вопросы, связанные с другими
транспортными протоколами, например UDP.
Предотвращение перегрузки в Интернете основано на предположении, что
большинство потерь пакетов обусловлено перегрузкой. Стратегия
предотвращения перегрузки TCP трактует отсутствие подтверждения как
сигнал перегрузки. Это хорошо работало с момента её введения в 1988
году [VJ-DCAC], поскольку большинство каналов и подсетей имеют
относительно низкую частоту ошибок при нормальной работе, а в этих
средах основной причиной потерь является перегрузка. Однако каналы и
подсети, не обладающие низкими частотами неисправленных ошибок,
становятся всё более распространёнными в некоторых частях Интернета.
В частности, к ним относятся наземные и спутниковые беспроводные
каналы. Пользователи, зависящие от трафика, проходящего через такие
каналы, могут наблюдать низкую производительность, поскольку их
TCP-соединения проводят чрезмерное время в процедурах предотвращения
перегрузки и/или медленного старта, запускаемых потерями пакетов из-за
ошибок передачи.
Рекомендации этого документа направлены на улучшение использования
доступной пропускной способности пути по таким каналам с высокой
частотой ошибок способами, не угрожающими стабильности Интернета.
Приложения используют TCP очень по-разному, и это взаимодействует с
поведением TCP [RFC2861]. Тем не менее возможно сделать некоторые
базовые предположения о потоках TCP. Соответственно, обсуждаемые здесь
механизмы применимы ко всем вариантам использования TCP, хотя и в
разной степени в зависимости от различных сценариев (как отмечено там,
где это уместно).
Эта рекомендация основана на явном предположении, что существенные
изменения всей установленной базы маршрутизаторов и хостов не являются
практически возможными. Это ограничивает любые изменения хостов,
непосредственно затронутых каналами с ошибками.
1.1 Следует ли вам читать эту рекомендацию?
Все известные технологии подсетей предоставляют «несовершенную» услугу
подсети — частота битовых ошибок не равна нулю. Но для конечных станций
нет очевидного способа отличить пакеты, отброшенные из-за перегрузки,
от потерь из-за ошибок передачи.
Если непосредственно подключённая подсеть сообщает хосту об ошибках
передачи, эти сообщения имеют значение, но мы не можем полагаться на
явные сообщения об ошибках передачи, поступающие обоим хостам.
Другой способ решить, следует ли считать подсеть имеющей «высокую
частоту ошибок», — обратиться к математике.
Приближённая формула функции отклика TCP Reno приведена в [PFTK98]:
s
T = --------------------------------------------------
RTT*sqrt(2p/3) + tRTO*(3*sqrt(3p/8))*p*(1 + 32p**2)
где
T = скорость отправки в байтах в секунду
s = размер пакета в байтах
RTT = время кругового пути в секундах
tRTO = значение тайм-аута повторной передачи TCP в секундах
p = установившаяся частота потерь пакетов
Если подставить наблюдаемую частоту потерь пакетов, выполнить вычисления
и затем получить прогнозируемое использование пропускной способности,
превышающее скорость канала, соединение не выиграет от рекомендаций
этого документа, поскольку наблюдаемый уровень потерь пакетов не будет
влиять на способность TCP использовать канал. Однако если
прогнозируемая пропускная способность меньше скорости канала, потери
пакетов влияют на способность TCP использовать канал.
Если дальнейшее исследование обнаружит подсеть со значительными
частотами ошибок передачи, рекомендации этого документа улучшат
способность TCP использовать канал.
При выполнении этого расчёта следует учитывать несколько оговорок:
(1) RTT — это сквозной RTT, а не RTT канала.
(2) В качестве упрощения вместо tRTO можно подставить Max(1.0,
4*RTT).
(3) потери могут происходить всплесками — частота потерь, измеренная
за интервал, включающий несколько событий всплесковых потерь,
может занижать влияние этих событий потерь на скорость отправки.
1.2 Связь этой рекомендации с PEPs
Этот документ обсуждает сквозные механизмы, не требующие осведомлённости
промежуточных узлов об уровне TCP. Это накладывает серьёзные ограничения
на то, что конечные узлы могут знать о характере потерь, происходящих
между ними. Попытки применять эвристики для различения перегрузки и
ошибки передачи не были успешными [BV97, BV98, BV98a]. Это ограничение
смягчается в информационном документе о прокси повышения
производительности (Performance Enhancing Proxies, PEPs) [RFC3135].
Поскольку PEPs могут размещаться на границах, где характеристики сети
резко изменяются, PEPs получают дополнительную возможность улучшать
производительность по каналам с неисправленными ошибками.
Однако обобщённое использование PEPs противоречит сквозному принципу и
крайне нежелательно с учётом их вредных последствий, включающих следующее:
отсутствие совместного разделения судьбы (PEP добавляет третью точку
отказа помимо самих конечных точек), сквозную надёжность и диагностику,
препятствование сквозной безопасности (в особенности безопасности
сетевого уровня, такой как IPsec), мобильность (передачи обслуживания
значительно сложнее, поскольку необходимо передавать состояние),
асимметричную маршрутизацию (PEPs обычно требуют присутствия как на
прямом, так и на обратном путях соединения), масштабируемость (PEPs
добавляют больше состояния, которое необходимо поддерживать),
прозрачность и гарантии QoS.
Не каждый тип PEP обладает всеми перечисленными выше недостатками.
Тем не менее использование PEPs может иметь очень серьёзные последствия,
которые необходимо тщательно взвешивать.
1.3 Связь этой рекомендации с механизмами канального уровня
Эта рекомендация предназначена для использования с TCP поверх уже
развёрнутых технологий подсетей (канальных уровней). Подсети, которые
предназначены для переноса интернет-протоколов, но ещё не были полностью
специфицированы, являются предметом документа о лучшей современной
практике (BCP), который разработан или разрабатывается рабочей группой
Performance Implications of Link Characteristics WG (PILC) [PILC-WEB].
Этот последний документ предназначен для проектировщиков, у которых ещё
есть возможность уменьшить число неисправленных ошибок, с которыми
столкнётся TCP.
2.0 Ошибки и взаимодействия с механизмами TCP
Отправитель TCP адаптирует использование пропускной способности сетевого
пути на основе обратной связи от получателя TCP. Поскольку TCP не способен
различать потери из-за перегрузки и потери из-за неисправленных ошибок,
он не способен точно определить доступную пропускную способность пути при
наличии значительных неисправленных ошибок.
2.1 Медленный старт и предотвращение перегрузки [RFC2581]
Медленный старт и предотвращение перегрузки [RFC2581] необходимы для
текущей стабильности Интернета. Эти механизмы были разработаны для
сетей, не предоставляющих явного уведомления о перегрузке. Хотя
экспериментальные механизмы, такие как [RFC2481], движутся в направлении
явного уведомления о перегрузке, влияние ECN на TCP, осведомлённые об
ECN, по существу такое же, как влияние неявного уведомления о перегрузке
через связанные с перегрузкой потери, за исключением того, что ECN
предоставляет это уведомление до того, как пакеты потеряны и затем
должны быть повторно переданы.
TCP-соединения, испытывающие высокие частоты ошибок на своих путях,
плохо взаимодействуют с медленным стартом и с предотвращением перегрузки,
поскольку высокие частоты ошибок делают интерпретацию потерь неоднозначной
— отправитель не может знать, вызваны ли обнаруженные потери перегрузкой
или повреждением данных. TCP делает «безопасный» выбор и предполагает,
что потери вызваны перегрузкой.
- Всякий раз, когда отправляющие TCP получают три подтверждения с
нарушенным порядком, они предполагают, что сеть слегка перегружена,
и вызывают быструю повторную передачу/быстрое восстановление
(описанные ниже).
- Всякий раз, когда истекает таймер повторной передачи TCP,
отправитель предполагает, что сеть перегружена, и вызывает
медленный старт.
- Менее надёжные канальные уровни часто используют малые MTU канала.
Это замедляет увеличение размера окна отправителя во время
медленного старта, поскольку окно отправителя увеличивается в
единицах сегментов. Малые MTU канала сами по себе не повышают
надёжность. Во избежание фрагментации также необходимо использовать
обнаружение MTU пути [RFC1191]. Обнаружение MTU пути допускает
наиболее быстрое раскрытие размера окна отправителя во время
медленного старта, но для полного раскрытия окна всё ещё может
потребоваться несколько круговых обходов.
Рекомендация: любой TCP, соответствующий стандартам, будет реализовывать
медленный старт и предотвращение перегрузки, которые являются
обязательными требованиями (MUST) в STD 3 [RFC1122]. Рекомендации этого
документа не будут препятствовать этим механизмам.
2.2 Быстрая повторная передача и быстрое восстановление [RFC2581]
TCP обеспечивает надёжную доставку данных приложению в виде потока байтов,
поэтому, когда сегмент потерян (вследствие перегрузки или потери при
передаче), реализация TCP получателя должна ждать доставки данных
принимающему приложению до получения отсутствующих данных. Реализация TCP
получателя обнаруживает отсутствующие сегменты по сегментам, прибывающим с
последовательными номерами в нарушенном порядке.
TCP следует немедленно отправлять подтверждение при получении данных в
нарушенном порядке [RFC2581], указывая без задержки следующий ожидаемый
последовательный номер, чтобы отправитель мог повторно передать требуемые
данные как можно быстрее, а получатель мог возобновить доставку данных
принимающему приложению. Когда подтверждение содержит тот же ожидаемый
последовательный номер, что и подтверждение, уже отправленное для
последнего принятого сегмента в правильном порядке, такие подтверждения
называются «дублирующими ACK».
Поскольку сети IP могут переупорядочивать пакеты, получатель может отправлять дублирующие подтверждения для сегментов, прибывающих не по порядку вследствие изменений маршрутизации, повторной передачи на канальном уровне и т. п. Когда отправитель TCP получает три дублирующих ACK, Fast Retransmit [RFC2581] позволяет ему сделать вывод о потере сегмента. Отправитель повторно передаёт сегмент, который считает потерянным, не дожидаясь полного тайм-аута повторной передачи, тем самым экономя время.
После Fast Retransmit отправитель вдвое уменьшает своё окно перегрузки и запускает алгоритм Fast Recovery [RFC2581], в соответствии с которым он применяет предотвращение перегрузки, начиная с уменьшенного вдвое окна перегрузки, но не запускает медленный старт с окна перегрузки в один сегмент, как он сделал бы после тайм-аута повторной передачи. Поскольку отправитель всё ещё получает дублирующие ACK, он знает, что получатель принимает отправленные пакеты, поэтому полное уменьшение после тайм-аута, когда не было получено никакой связи, не требуется. Эта относительно безопасная оптимизация также экономит время.
Важно реалистично оценивать максимальную пропускную способность, которую TCP может обеспечить в соединении, проходящем через канал с высокой частотой ошибок. В общем случае TCP увеличивает своё окно перегрузки сверх произведения задержки на пропускную способность. Стратегия предотвращения перегрузки TCP состоит в аддитивном увеличении и мультипликативном уменьшении; это означает, что, если до полного восстановления окна перегрузки после уменьшения на 50 процентов встречаются дополнительные ошибки, результатом может стать «нисходящая
спираль» окна перегрузки вследствие дополнительных уменьшений на 50 процентов. Даже при использовании Fast Retransmit/Fast Recovery отправитель будет уменьшать окно перегрузки вдвое каждый раз, когда окно содержит один или несколько потерянных сегментов, и будет вновь открывать окно на один дополнительный сегмент на каждый объём полученных подтверждений, равный окну перегрузки.
Если путь соединения проходит через канал, в котором в этот период восстановления теряется один или несколько сегментов, уменьшение вдвое происходит снова, на этот раз для уже уменьшенного окна перегрузки, — и эта нисходящая спираль будет продолжать удерживать окно перегрузки ниже пропускной способности пути, пока соединение не сможет полностью восстановиться путём аддитивного увеличения без потерь.
Разумеется, нисходящей спирали не возникает, если частота ошибок постоянно высока и окно перегрузки всегда остаётся малым; при мультипликативном увеличении «медленный старт» завершается рано, и окно перегрузки остаётся малым на протяжении TCP-соединения. В каналах с высокой частотой ошибок окно TCP может оставаться довольно малым длительное время.
Не все причины малых окон связаны с ошибками. Например, HTTP/1.0 обычно закрывает TCP-соединения, чтобы обозначить границы между запрошенными ресурсами. Это означает, что такие приложения постоянно закрывают «обученные» TCP-соединения и открывают «необученные» TCP-соединения, которые будут выполнять медленный старт, начиная с одного или двух сегментов. Это может происходить даже с HTTP/1.1, если веб-мастера настраивают свои серверы HTTP/1.1 закрывать соединения вместо ожидания, чтобы определить, будет ли соединение снова полезным.
Малое окно — особенно окно менее четырёх сегментов — фактически не позволяет отправителю воспользоваться преимуществами Fast Retransmit. Кроме того, для эффективного восстановления после множественных потерь в пределах одного окна требуется принятие новых предложений (NewReno [RFC2582]).
Рекомендация: в настоящее время реализуйте Fast Retransmit и Fast Recovery. Это широко реализованная оптимизация, которая в настоящее время имеет статус Proposed Standard. [RFC2488] рекомендует реализацию Fast Retransmit/Fast Recovery в спутниковых средах.
2.3 Выборочные подтверждения [RFC2018, RFC2883]
Выборочные подтверждения [RFC2018] позволяют устранять множественные потери сегментов в одном окне, не требуя одного (или нескольких) обходов туда и обратно для каждой потери.
[RFC2883] предлагает небольшое расширение SACK, позволяющее принимающим TCP предоставлять больше информации о порядке доставки сегментов и обеспечивающее «более устойчивую работу в среде с переупорядоченными пакетами, потерей ACK, дублированием пакетов и/или ранними тайм-аутами повторной передачи». Если явно не указано иное, в этом документе «Выборочные подтверждения» (или «SACK») означает сочетание [RFC2018] и [RFC2883].
Согласно разделу 1.1 [RFC1323], выборочные подтверждения наиболее полезны в LFN («Long Fat Networks») из-за длительных времён обхода туда и обратно, возможных в таких средах, и особенно полезны, если требуются большие окна, поскольку существует более высокая вероятность множественных потерь сегментов в одном окне.
С другой стороны, если частота ошибок в целом низка, но иногда повышается из-за состояния канала, TCP сможет увеличивать своё окно до больших значений в периоды улучшения состояния канала между всплесками ошибок. При возникновении всплесков ошибок вероятны множественные потери в пределах окна. В этом случае SACK обеспечит преимущества, ускоряя восстановление и предотвращая ненужное уменьшение размера окна.
Рекомендация: реализуйте SACK в соответствии с [RFC2018] с обновлениями [RFC2883]; оба документа имеют статус Proposed Standard. В случаях, когда SACK нельзя включить для обеих сторон соединения, отправители TCP могут использовать NewReno [RFC2582] для более эффективной обработки частичных ACK и множественных потерь в пределах одного окна.
3.0 Сводка рекомендаций
В Интернете отсутствует широко доступный механизм обратной связи о потерях, позволяющий TCP различать потерю из-за перегрузки и ошибку передачи. Поскольку перегрузка влияет на весь трафик на пути, тогда как потери при передаче влияют только на конкретный трафик, сталкивающийся с неисправленными ошибками, предотвращение перегрузки должно иметь приоритет над быстрым устранением ошибок передачи. Это означает, что без новых механизмов обратной связи максимум, которого можно достичь, — минимизировать количество времени, без необходимости проводимого в предотвращении перегрузки.
Механизм Fast Retransmit/Fast Recovery позволяет быстро устранять потери, не отказываясь от безопасности предотвращения перегрузки. Чтобы Fast Retransmit/Fast Recovery работал, размер окна должен быть достаточно велик, чтобы заставить получателя отправить три дублирующих подтверждения до истечения интервала тайм-аута повторной передачи, вызывающего полный медленный старт TCP.
Выборочные подтверждения (SACK) распространяют преимущества Fast Retransmit/Fast Recovery на ситуации, когда множественные потери сегментов в окне необходимо устранить быстрее, чем это можно сделать, выполняя Fast Retransmit для каждой потери сегмента, лишь затем чтобы обнаружить потерю следующего сегмента.
Эти механизмы не ограничены беспроводными средами. Они применимы во всех средах.
4.0 Темы для дальнейшей работы
«Limited Transmit» [RFC3042] определён как оптимизация, расширяющая Fast Retransmit/Fast Recovery для TCP-соединений с малыми окнами перегрузки, которые не вызовут трёх дублирующих подтверждений. Эта спецификация считается безопасной и также даёт преимущества TCP-соединениям, в которых происходит значительное количество потерь пакетов (данных или ACK). Реализаторам следует оценить эту спецификацию из линии стандартов для TCP в средах с потерями.
Delayed Duplicate Acknowledgements [MV97, VMPM99] пытается предотвратить повторную передачу на уровне TCP, когда повторная передача на канальном уровне всё ещё выполняется, добавляя в сеть дополнительный трафик. Это предложение заслуживает дополнительного изучения, но в настоящее время не рекомендуется, поскольку неизвестно, как рассчитать подходящие величины задержки для произвольной топологии сети.
Невозможно использовать явное уведомление о перегрузке [RFC2481] как замену явному уведомлению об ошибке передачи (как бы нам этого ни хотелось!). Некоторый механизм явного уведомления об ошибке передачи был бы очень полезен. Его, возможно, легче обеспечить в среде PEP, особенно когда PEP является «первым переходом» на пути соединения, поскольку существующие механизмы контрольных сумм не различают ошибку передачи в полезной нагрузке и ошибку передачи в заголовке. Кроме того, если заголовок повреждён, отправка явного уведомления об ошибке передачи правильной конечной точке проблематична.
Потери в потоке ACK, особенно пока TCP изучает характеристики сети, могут сделать поток данных весьма пачечным (что также приводит к потерям в потоке данных). Было предложено несколько способов ограничить эту пачечность, включая управление темпом передачи TCP у отправителя и управление скоростью ACK в сети.
«Appropriate Byte Counting» (ABC) [ALL99] был предложен как способ открывать окно перегрузки на основе числа байтов, успешно переданных получателю, обеспечивая более подходящее поведение для протоколов приложений, которые инициируют соединения относительно короткими пакетами. Например, для SMTP [RFC2821] клиент может отправить короткий пакет HELO, короткий пакет MAIL, один или несколько коротких пакетов RCPT и короткий пакет DATA — после чего всё тело сообщения отправляется пакетами максимальной длины. Отправитель TCP с ABC не использовал бы ACK каждого из этих коротких пакетов для увеличения окна перегрузки, позволяющего передавать дополнительные пакеты полной длины. ABC заслуживает дополнительного изучения, но в настоящее время не рекомендуется, поскольку ABC может приводить к увеличению пачечности при потере подтверждений.
4.1 Достижение и поддержание больших окон
Рекомендации, описанные в этом документе, помогут TCP вводить пакеты в соединения ERRORed настолько быстро, насколько возможно без дестабилизации Интернета, и тем самым оптимизировать использование доступной пропускной способности.
Помимо этих рекомендаций уровня TCP, остаётся дополнительная работа на уровне приложений, особенно с доминирующим протоколом приложений Всемирной паутины — HTTP.
HTTP/1.0 (и более ранние версии) закрывает TCP-соединения, чтобы сигнализировать получателю, что весь запрошенный ресурс был передан. Поскольку объекты WWW обычно невелики по размеру [MOGUL], TCP, несущие трафик HTTP/1.0, испытывают трудности с «обучением» доступной пропускной способности пути (к моменту выхода TCP из медленного старта уже передана существенная часть передачи).
Для улучшения этого взаимодействия с TCP было введено несколько модификаций HTTP («постоянные соединения» в HTTP/1.0 с улучшениями в HTTP/1.1 [RFC2616]). По разным причинам многие взаимодействия HTTP всё ещё имеют стиль HTTP/1.0 — сравнительно кратковременный.
Предложения, повторно использующие информацию TCP о перегрузке между соединениями, такие как TCP Control Block Interdependence [RFC2140] или более позднее предложение Congestion Manager [BS00], приведут к тому, что несколько параллельных соединений будут воздействовать на сеть так, как если бы они были одним соединением, «обученным» после одного переходного периода запуска. Эти предложения критически важны для долгосрочной устойчивости Интернета, поскольку современные пользователи всегда могут нажать кнопку «reload» в своих браузерах и прервать экспоненциальную отсрочку TCP, заменяя соединения, накапливающие знания о доступной пропускной способности, соединениями, не обладающими никакими знаниями.
5.0 Соображения безопасности
Потенциальная уязвимость, вносимая Fast Retransmit/Fast Recovery, состоит в том (как отмечено в [RFC2581]), что атакующий может заставить TCP-соединения практически остановиться или, что опаснее, вести себя более агрессивно. Последняя возможность может привести к коллапсу перегрузки, по крайней мере в некоторых областях сети.
Считается, что выборочные подтверждения не усиливают и не ослабляют текущие свойства безопасности TCP [RFC2018].
Поскольку рекомендации этого документа выполняются на сквозной основе, они продолжают работать даже при наличии сквозного IPsec. Это прямо противоположно механизмам, таким как PEP, которые реализованы в промежуточных узлах (раздел 1.2).
6.0 Соображения IANA
Этот документ является указателем на другие уже существующие стандарты IETF. Новых соображений IANA нет.
7.0 Благодарности
Эта рекомендация выросла из RFC 2757, «Long Thin Networks», который, в свою очередь, основывался на работе, выполненной в рабочей группе IETF TCPSAT. Авторы признательны активным участникам рабочей группы PILC. В частности, Mark Allman и Lloyd Wood предоставили нам обильные и содержательные отзывы, а Dan Grossman и Jamshid Mahdavi предоставили замены текста.