О документе
Network Working Group G. Fairhurst
Request for Comments: 3366 University of Aberdeen
BCP: 62 L. Wood
Category: Best Current Practice Cisco Systems Ltd
August 2002
Рекомендации разработчикам каналов связи по Automatic Repeat reQuest (ARQ) канального уровня
1. Введение
IP, Internet Protocol [RFC791], образует ядро глобальной сети Internet и определяет простую «бессоединительную» сеть с коммутацией пакетов. На протяжении многих лет Internet-трафик с использованием IP переносился по широкому разнообразию каналов связи с весьма разными пропускной способностью, задержками и характеристиками потерь. Можно ожидать, что в будущем IP-трафик продолжит передаваться по очень широкому разнообразию новых и существующих проектных решений каналов связи, также обладающих различными характеристиками.
Сопутствующий документ [DRAFTKARN02] описывает общие вопросы, связанные с проектированием каналов связи. Этот документ следует читать вместе с ним и с другими документами, подготовленными рабочей группой IETF Performance Implications of Link Characteristics (PILC) [RFC3135, RFC3155].
Этот документ предназначен для трёх различных групп читателей:
a. Разработчиков каналов связи, желающих сконфигурировать (или настроить) канал для IP-трафика, который он будет переносить, используя стандартные механизмы канального уровня, такие как ISO High-level Data Link Control (HDLC) [ISO4335a] или его производные.
b. Реализаторов каналов связи, которые могут захотеть разработать новые механизмы канального уровня, хорошо работающие для IP-трафика.
c. Сообщество людей, использующих или разрабатывающих TCP, UDP и связанные протоколы, которым может быть желательно знать о способах работы каналов связи.
Основными целевыми аудиториями являются группы (a) и (b). Группе (c) не должно требоваться знать точные детали схемы ARQ на одном канале связи, и ей не должно быть необходимо учитывать такие детали при реализации протоколов; значительная часть Internet работает через каналы, не использующие никакой формы ARQ. Однако сообщество TCP/IP всё же должно знать, что протокол IP работает поверх разнообразного набора нижележащих подсетей. Этот документ может помочь повысить это осознание.
Абсолютная надёжность не является требованием для IP-сетей и не является требованием для каналов связи [DRAFTKARN02]. IP-сети могут отбрасывать пакеты по разнообразным причинам, совершенно не связанным с ошибками канала, включая нехватку места в очередях, управление перегрузкой, отказы и изменения маршрутов. Уже давно широко известно, что абсолютная сквозная надёжность может быть обеспечена только на транспортном уровне или выше [SALT81].
Здесь предполагается некоторое знакомство с TCP, Transmission Control Protocol [RFC793, STE94]. TCP предоставляет надёжную транспортную службу потока байтов, основываясь на службе доставки датаграмм с максимальными усилиями, предоставляемой Internet Protocol. TCP достигает этого, разделяя данные на сегменты TCP и перенося эти сегменты в пакетах IP. TCP гарантирует, что сеанс TCP повторно передаст сегменты TCP, содержащиеся в любых пакетах данных, потерянных на пути Internet между оконечными узлами. Обычно TCP выполняет повторную передачу с использованием процедуры Fast Retransmit, но, если потеря не обнаружена (или повторная передача неуспешна), TCP возвращается к повторной передаче по истечении тайм-аута повторной передачи Retransmission Time Out (RTO), используя таймер [RFC2581, RFC2988]. (Протоколы канального уровня также реализуют таймеры для проверки целостности канала и содействия канальному ARQ.) TCP также справляется с любым дублированием или изменением порядка, внесёнными IP-сетью. Существует ряд вариантов TCP с различными уровнями сложности процедур обработки восстановления после потерь и избегания перегрузки. Протокол TCP далеко не является статичным: он сам подвергается непрерывному постепенному уточнению и развитию, например [RFC2488, RFC2760].
Можно обоснованно ожидать, что сети Internet будут переносить трафик от широкого и развивающегося набора приложений. Не все приложения требуют или получают преимущества от использования надёжной службы, предоставляемой TCP. В Internet такие приложения переносятся альтернативными транспортными протоколами, такими как User Datagram Protocol (UDP) [RFC768].
1.1 Канальный ARQ
На канальном уровне ARQ работает с блоками данных, называемыми кадрами, и пытается доставить кадры от отправителя канального уровня получателю канального уровня через канал. Канал предоставляет соединение физического уровня, поверх которого работает протокол канального уровня. В простейшем виде канал может быть прямым соединением физического уровня между двумя узлами канального уровня (например, по отрезку кабеля или через беспроводную среду). ARQ также может использоваться от края до края подсети, где путь включает более одной среды физического уровня. Кадры часто имеют небольшой фиксированный или максимальный размер для удобства обработки протоколами управления доступом к среде (MAC) и канального уровня. Это контрастирует с переменной длиной IP-датаграмм, или «пакетов». Кадр канального уровня может содержать все или часть одного или нескольких IP-пакетов. Механизм канального ARQ полагается на проверку целостности каждого кадра (например, сильный CRC канального уровня [DRAFTKARN02]) для обнаружения ошибок канала и использует процесс повторной передачи для повторной передачи потерянных (то есть отсутствующих или повреждённых) кадров.
Каналы связи могут быть полнодуплексными (допускающими двустороннюю связь по отдельным прямому и обратному каналам), полудуплексными (в которых двусторонняя связь использует общий прямой и обратный канал, например IrDA, IEEE 802.11) или симплексными (в которых один канал допускает связь только в одном направлении).
ARQ требует как прямого, так и обратного пути, поэтому канальный ARQ может использоваться поверх полнодуплексных или полудуплексных каналов связи. Когда канал совместно используется двумя или более узлами канального уровня, необходим протокол MAC канального уровня, чтобы обеспечить всем узлам, которым нужна передача, возможность получить доступ к общему каналу. Такие схемы могут увеличивать задержку (джиттер), связанную с передачей пакетных данных и кадров управления ARQ.
При использовании ARQ поверх канала, где вероятность потери кадра связана с размером кадра, для любой конкретной целевой частоты ошибок канала существует оптимальный размер кадра. Для эффективного использования канала этот максимальный размер кадра канального уровня может быть значительно меньше максимального размера IP-датаграммы, заданного IP Maximum Transmission Unit (MTU). Тогда каждый кадр будет содержать лишь часть IP-пакета, и используется прозрачная неявная фрагментация IP-датаграммы [DRAFTKARN02]. Меньший размер кадра увеличивает накладные расходы заголовка кадра на каждый переданный байт полезной нагрузки.
Явная IP-фрагментация сетевого уровня нежелательна по ряду причин, и её следует избегать [KEN87, DRAFTKARN02]. Её использование можно свести к минимуму с помощью Path MTU discovery [RFC1191, RFC1435, RFC1981].
Другой способ уменьшить частоту потери кадров (или уменьшить мощность передаваемого сигнала при той же частоте потери кадров) — использовать кодирование, например Forward Error Correction (FEC) [LIN93].
FEC обычно включается в проект физического уровня беспроводных каналов связи и может использоваться одновременно с канальным ARQ. Также существуют схемы FEC, сочетающие модуляцию и кодирование; они также могут быть адаптивными. Hybrid ARQ [LIN93] объединяет адаптивный FEC с процедурами канального ARQ, чтобы уменьшить вероятность потери повторно передаваемых кадров. Для уменьшения вероятности потери кадров также может использоваться перемежение, которое распределяет ошибки в канале более широко для улучшения восстановления после ошибок; это добавляет дополнительную задержку к уже существующей задержке распространения в канале.
Документ не рассматривает использование канального ARQ для поддержки широковещательной или многоадресной службы внутри подсети, в которой канал может отправить один пакет более чем одному получателю за одну операцию передачи по каналу. Хотя такие схемы поддерживаются в некоторых подсетях, они порождают ряд дополнительных вопросов, не рассматриваемых здесь.
Каналы, поддерживающие основанное на резервировании с сохранением состояния качество обслуживания (QoS) в соответствии с моделью Integrated Services (intserv), также явно не обсуждаются.
1.2 Причины потери пакетов на канале связи
Не все пакеты, отправленные в канал связи, обязательно успешно принимаются получателем на другом конце канала. Существует ряд возможных причин потери пакетов. Они могут возникать при передаче кадров по каналу связи и включают:
a. Потерю из-за шума в канале, часто характеризуемую случайной потерей кадров. Шум в канале также может быть следствием другого трафика, ухудшающего условия в канале.
b. Потерю кадров вследствие помех в канале. Эти помехи могут быть случайными, структурированными, а в некоторых случаях даже периодическими.
c. Отказ канала связи — период, в течение которого канал теряет все или практически все кадры, пока не будет восстановлен. Это обычная характеристика некоторых типов каналов, например мобильной сотовой радиосвязи.
Другие формы потери пакетов не связаны с условиями в канале, но включают:
i. Потерю кадра, переданного в общем канале, где используется учитывающий конкуренцию протокол MAC (например, вследствие коллизии). Здесь многие протоколы требуют отложить повторную передачу, чтобы способствовать стабильности общего канала (то есть предотвратить чрезмерную конкуренцию за канал). Это далее обсуждается в разделе 1.5.
ii. Отбрасывание пакетов вследствие перегрузки. Очереди в конечном счёте переполнятся, поскольку скорость поступления новых пакетов для отправки продолжает превышать скорость исходящей передачи пакетов по каналу.
iii. Потерю вследствие ошибок реализации, включая аппаратные отказы и программные ошибки. Это признаётся частой причиной повреждения пакетов, обнаруживаемого на оконечных узлах [STONE00].
Скорость потерь и характер наблюдаемых потерь являются функциями конструкции физического и канального уровней. Они значительно различаются для разных конфигураций канала. Производительность конкретной реализации также может существенно различаться в одной и той же конфигурации канала при работе по каналам разных типов.
1.3 Зачем использовать ARQ?
Причины, побуждающие рассмотреть использование ARQ, включают:
a. ARQ на одном канале имеет более быстрый контур управления, чем контур управления подтверждениями TCP, действующий по более длинному сквозному пути, по которому должен работать TCP. Поэтому ARQ может обеспечивать более быструю повторную передачу сегментов TCP, потерянных на канале, по крайней мере при разумном числе повторных попыток [RFC3155, SALT81].
b. Канальный ARQ может работать с отдельными кадрами, используя неявную прозрачную фрагментацию на канальном уровне [DRAFTKARN02]. Кадры могут быть значительно меньше IP-пакетов, и повторная передача меньших кадров, содержащих потерянные или повреждённые части IP-пакета, может повысить эффективность процесса ARQ и эффективность канала.
Процедура канального ARQ может использовать локальную информацию, недоступную конечным узлам, для оптимизации производительности доставки в текущих условиях канала. Эта информация может включать сведения о состоянии канала и среды передачи, например знание текущей доступной скорости передачи, преобладающих условий ошибок или доступной мощности передачи в беспроводных каналах.
1.4 Часто используемые методы ARQ
Протокол канального ARQ использует механизм канального протокола, позволяющий отправителю обнаруживать потерянные или повреждённые кадры и планировать повторную передачу. Обнаружение потери кадра может осуществляться посредством таймера канального протокола, путём обнаружения отсутствующих кадров положительного подтверждения канального уровня, при получении явных кадров отрицательного подтверждения и/или путём опроса состояния приёмника канала.
Независимо от выбранных механизмов существуют две широко используемые и легко описываемые категории процесса повторной передачи ARQ:
1.4.1 ARQ с остановкой и ожиданием
Отправитель, использующий ARQ с остановкой и ожиданием (иногда известный как «Idle ARQ» [LIN93]), передаёт один кадр, а затем ожидает от приёмника подтверждения этого кадра. Затем отправитель либо продолжает передачу следующим кадром, либо повторяет передачу того же кадра, если подтверждение указывает, что исходный кадр был потерян или повреждён.
ARQ с остановкой и ожиданием прост в реализации для разработчиков протоколов, хотя и неэффективен, и поэтому популярен, например tftp [RFC1350] на транспортном уровне. Однако при использовании ARQ с остановкой и ожиданием на канальном уровне он хорошо подходит только для каналов с малым произведением полосы пропускания на задержку. Далее этот метод в настоящем документе не рассматривается.
1.4.2 ARQ со скользящим окном
Протокол, использующий канальный ARQ со скользящим окном [LIN93], нумерует каждый кадр уникальным порядковым номером согласно модулю. Модуль определяет основание нумерации порядковых номеров кадров и размер пространства последовательности. Наибольшее значение порядкового номера рассматривается канальным протоколом как смежное с первым (0), поскольку пространство нумерации циклически повторяется.
Сам TCP является протоколом со скользящим окном на транспортном уровне [STE94], поэтому сходство между протоколом от интерфейса канала к интерфейсу канала и сквозным TCP может быть узнаваемым. Канальный протокол со скользящим окном значительно сложнее в реализации, чем более простой протокол с остановкой и ожиданием, описанный в предыдущем разделе, особенно если сохраняется упорядоченность для каждого потока.
В любой момент времени отправитель канала может иметь некоторое число отправленных, но ещё не подтверждённых кадров, вплоть до пространства, доступного в его окне передачи. Достаточно большое окно отправителя канала (равное или большее числа отправленных кадров либо большее ёмкости канала, определяемой произведением полоса пропускания*задержка) допускает непрерывную передачу новых кадров. Меньшее окно отправителя канала заставляет отправителя приостановить передачу новых кадров до получения тайм-аута или управляющего кадра, такого как подтверждение. При потере кадров для обеспечения непрерывной работы во время повторной передачи кадров необходимо большее окно, то есть превышающее произведение полоса пропускания*задержка канала.
Пространство нумерации по модулю определяет размер поля порядкового номера в заголовке кадра. Это пространство последовательности должно быть больше размера окна канала и, при использовании ARQ с выборочным повтором, больше удвоенного размера окна канала. Для непрерывной работы пространство последовательности следует сделать больше произведения ёмкости канала и устойчивости канального ARQ (рассматриваемой в разделе 2), чтобы находящиеся в пути кадры можно было однозначно идентифицировать.
Как и TCP, который обеспечивает доставку со скользящим окном по всему сквозному пути, а не по одному каналу, базовая реализация со скользящим окном имеет большое число вариантов с повышенной сложностью и усовершенствованиями, делающими их пригодными для различных условий. Selective Repeat (SR), также известный как Selective Reject (SREJ), и Go-Back-N, также известный как Reject (REJ), являются примерами методов ARQ, использующих протоколы, реализующие ARQ со скользящим окном.
1.5 Причины задержки при передаче по каналу
Каналы и канальные протоколы вносят вклад в суммарную задержку пути, испытываемую между взаимодействующими приложениями на конечных узлах. Задержка имеет ряд причин, включая:
a. Постановку входящих пакетов в очередь и буферизацию кадров в начале канала до передачи по среде передачи.
b. Отсрочку повторной передачи — дополнительную задержку, вводимую для повторных передач некоторыми схемами MAC при работе по общей среде передачи для предотвращения чрезмерной конкуренции. Иначе может возникнуть высокий уровень конкуренции, если, например, набор приёмников канала все вместе немедленно повторят передачу после коллизии в загруженной общей среде передачи. Протоколы канального ARQ, разработанные для общих сред передачи, могут выбирать задержку отсрочки, увеличивающуюся с числом попыток повторной передачи кадра; здесь возможны аналогии со сквозным предотвращением перегрузки TCP на транспортном уровне [RFC2581]. Напротив, канал по выделенной среде передачи (ёмкость которой предварительно выделена этому каналу) может отправить повторную передачу в наиболее ранний возможный момент.
c. Ожидание доступа к выделенному каналу, когда канал является общим. До начала передачи может возникать задержка обработки или задержка, обусловленная протоколом [FER99, PAR00].
d. Последовательная передача кадра и обработка передачи. Они зависят от размера кадра и скорости передачи канала.
e. Время распространения на физическом уровне, ограниченное скоростью распространения сигнала в физической среде передачи канала.
f. Обработка каждого кадра, включая стоимость планирования QoS, шифрования, FEC и перемежения. FEC и перемежение также добавляют существенную задержку, а в некоторых случаях — дополнительный джиттер. Гибридные схемы канального ARQ [LIN93], в частности, могут вносить значительную задержку обработки на приёмнике.
g. Обработка пакета, включая буферизацию содержимого кадров на приёмнике канала для повторной сборки пакета до последующей передачи пакета.
При использовании канального ARQ шаги (b), (c), (d), (e) и (f) могут повторяться несколько раз при каждой повторной передаче кадра, увеличивая общую задержку пакета, который частично переносится этим кадром. Адаптивные схемы ARQ (например, гибридный ARQ с использованием адаптивных кодов FEC) также могут вносить дополнительную обработку каждого кадра для повторно передаваемых кадров.
Важно понимать, что приложения и транспортные протоколы на конечных узлах не осведомлены об отдельных задержках, вносимых каждым каналом на пути, и видят только общую задержку пути. Поэтому производительность приложений определяется совокупной задержкой всего сквозного пути в Интернете. Этот путь может включать произвольное или даже сильно колеблющееся число каналов, причём любой канал может использовать ARQ или не использовать его. В результате невозможно установить фиксированные пределы приемлемой задержки, которую канал может добавлять к пути; другие каналы на пути добавят неизвестную задержку.
2. Устойчивость ARQ
Протоколы ARQ могут характеризоваться своей устойчивостью. Устойчивость — это готовность протокола повторно передавать потерянные кадры, чтобы обеспечить надёжную доставку трафика по каналу.
Устойчивость повторной передачи канала определяет, как долго каналу разрешено задерживать пакет, пытаясь передать по каналу все кадры, переносящие пакет и его содержимое, прежде чем отказаться от попыток и отбросить пакет. Эту устойчивость обычно можно измерять в миллисекундах, но при заданной задержке распространения в канале она может выражаться через максимальное допустимое число попыток повторной передачи по каналу. Последнее не всегда соответствует точному ограничению по времени по причинам, рассмотренным в разделе 1.5.
Примером надёжного канального протокола с совершенной устойчивостью является протокол ISO HDLC в асинхронном сбалансированном режиме (ABM) [ISO4335a].
Протокол, который повторно передаёт данные лишь некоторое число раз, прежде чем отказаться от попыток, является менее устойчивым, например Ethernet [FER99], IEEE 802.11 или GSM RLP [RFC2757]. Здесь меньшая устойчивость также обеспечивает стабильность и справедливое совместное использование общей среды передачи, даже когда многие отправители пытаются выполнить повторные передачи.
TCP, STCP [RFC2960] и ряд приложений, использующих UDP (например, tftp), реализуют собственные сквозные механизмы надёжной доставки. Многие приложения TCP и UDP, например потоковые мультимедийные приложения, выигрывают от своевременной доставки нижними уровнями с достаточной надёжностью, а не от совершенной надёжности с увеличенными задержками канала.
2.1 Протоколы ARQ с совершенной устойчивостью (надёжные)
Протокол ARQ с совершенной устойчивостью — это протокол, который пытается предоставлять надёжную службу, то есть доставку пакетов в порядке следования на другой конец канала без отсутствующих и без дублирующихся пакетов. Протокол ARQ с совершенной устойчивостью будет повторять потерянный или повреждённый кадр неопределённое (и потенциально бесконечное) число раз, пока кадр не будет успешно принят.
Если трафик не проходит далее одного канала, а потери не происходят внутри конечных узлов, совершенная устойчивость обеспечивает надёжность между двумя концами канала, не требуя протоколов более высоких уровней. Эта надёжность может стать контрпродуктивной для трафика, проходящего через несколько каналов, поскольку она дублирует функциональность механизмов протоколов на более высоких уровнях и взаимодействует с ней [SALT81].
Аргументы против использования совершенной устойчивости для IP-трафика включают:
a. Переменная задержка канала; воздействие ARQ вносит некоторую степень джиттера, зависящего от задержки физического уровня и времени последовательной передачи и передачи кадров (рассматриваемых в разделе 1.5), во все потоки, совместно использующие канал, выполняющий повторную передачу кадров.
b. Совершенная устойчивость не предоставляет ясной верхней границы максимальной задержки повторной передачи для канала. Существенные изменения задержки пути, вызванные чрезмерными повторными передачами на канале, могут приводить к срабатыванию таймеров повторной передачи TCP по тайм-ауту, хотя большая вариативность задержки канала и возникающей общей задержки пути также может приводить к выбору большого значения TCP RTO [LUD99b, PAR00]. Это изменит пропускную способность TCP, уменьшая общую производительность, но в качестве смягчающего обстоятельства также может уменьшить число тайм-аутов вследствие продолжающейся потери пакетов.
c. Приложения, которым нужна совершенно надёжная доставка, могут сами реализовать форму ARQ с совершенной устойчивостью либо использовать надёжный транспортный протокол внутри конечных узлов. Реализация совершенной устойчивости на каждом канале пути между конечными узлами избыточна, но не может обеспечить ту же надёжность, что и сквозной транспорт [SALT81].
d. Канальный ARQ не следует применять так, чтобы неблагоприятно задерживать поток сквозной управляющей информации. Например, повторная передача ARQ данных одного или нескольких потоков не должна чрезмерно удлинять контуры управления протоколом. Чрезмерная задержка дублирующихся подтверждений TCP (dupacks [STE94, BAL97]), SACK или индикаторов Explicit Congestion Notification (ECN) уменьшит отзывчивость потоков TCP на события перегрузки. Подобные проблемы существуют для TCP-Friendly Rate Control (TFRC), в котором управление перегрузкой на основе уравнения используется с UDP [DRAFTHAN01].
Протоколы канального уровня с совершенной устойчивостью, выполняющие неограниченный ARQ, то есть продолжающие повторно передавать кадры неопределённо долго, пока кадры не будут успешно приняты, редко встречаются в реальных реализациях.
Большинство практически применяемых протоколов канального уровня в некоторый момент прекращают повторные передачи, но не обязательно делают это с целью ограничить настойчивость повторных передач ARQ. Например, протокол может прекращать повторные передачи после отказа соединения канального уровня, например после того, как в течение заранее настроенного интервала таймера не было успешно принято ни одного кадра. Поэтому число повторных передач протоколом конкретного кадра (или максимальное число повторных передач) становится функцией множества различных параметров (процедуры ARQ, значений таймеров канала и процедуры мониторинга канала), а не заранее настроенной величиной.
Другая распространённая особенность такого поведения состоит в том, что некоторые разработчики реализаций протоколов предполагают: после отказа канала пакеты, поставленные в очередь для передачи по каналу, более не значимы и могут быть отброшены при прекращении повторных передач ARQ.
Примеры протоколов ARQ с полностью неограниченной настойчивостью повторных передач включают ISO/ITU-T LAP-B [ISO7776] и ISO HDLC в асинхронном сбалансированном режиме (Asynchronously Balanced Mode, ABM) [ISO4335a], например с использованием Multiple Selective Reject (MSREJ [ISO4335b]). Эти протоколы будут повторно передавать кадр неограниченное число раз, пока не будет получено подтверждение приёма кадра.
2.2 Протоколы ARQ с высокой настойчивостью повторных передач (высокой надёжностью)
Протоколы ARQ с высокой настойчивостью повторных передач ограничивают число раз (или число попыток), когда ARQ может повторно передавать конкретный кадр, прежде чем отправитель прекращает повторную передачу отсутствующего кадра и переходит к пересылке последующих буферизованных кадров, идущих в правильной последовательности. Прекращение повторной передачи кадра не означает отсутствия связности канала и не вызывает изменения состояния протокола канального уровня.
Рекомендовалось, чтобы сеть никогда не задерживала один IP-пакет дольше Maximum Segment Lifetime (MSL), равного 120 секундам и определённого для TCP [RFC1122]. Однако на практике трудно ограничить максимальную задержку пути в Интернете. Одним из случаев, когда время жизни сегмента (пакета) может быть существенным, является наличие между конечными хостами альтернативных путей с различными задержками и использование колебаний маршрута или управления трафиком без учёта потоков. Некоторые TCP-пакеты могут следовать коротким путём, тогда как другие следуют значительно более длинным путём, например при использовании настойчивого ARQ при недоступности канала.
Неспособность ограничить максимальное время жизни пакета может привести к циклическому переполнению номеров последовательности TCP при высоких скоростях передачи: старые сегменты данных могут быть перепутаны с более новыми сегментами, если пространство номеров последовательности было исчерпано и за это время повторно использовано. Некоторые реализации TCP используют опцию Round Trip Timestamp Measurement (RTTM) в TCP-пакетах для устранения этой неоднозначности, применяя алгоритм Protection Against Wrapped Sequence number (PAWS) [RFC1323].
На практике MSL обычно очень велик по сравнению с типичным TCP RTO. Расчёт TCP RTO основан на оценённой задержке пути в обоих направлениях [RFC2988]. Если число повторных передач на канальном уровне вызывает задержку пути, превышающую значение RTO, таймер повторной передачи TCP может истечь, что приведёт к тайм-ауту и повторной передаче сегмента (пакета) отправителем TCP.
Хотя высокая настойчивость повторных передач может быть полезна для объёмных потоков, вносимая ею дополнительная задержка (и изменения задержки) может быть крайне нежелательной для потоков других типов. Возможность обрабатывать потоки раздельно, с различными классами обслуживания канального уровня, полезна и рассматривается в разделе 3.
Примеры протоколов ARQ с высокой настойчивостью повторных передач включают [BHA97, ECK98, LUD99a, MEY99].
2.3 Протоколы ARQ с низкой настойчивостью повторных передач (частично надёжные)
Характеристики канала, использующего протокол ARQ с низкой настойчивостью повторных передач, можно резюмировать следующим образом:
a. Канал не является полностью надёжным и не предоставляет абсолютной гарантии доставки, то есть передатчик отбросит некоторые кадры, «прекращая попытки» до получения подтверждения успешной передачи по каналу.
b. Снижен предел максимальной добавочной задержки, которую IP-пакеты будут испытывать при прохождении по каналу (обычно она ниже TCP RTO пути). Это уменьшает взаимодействие с таймерами TCP или со схемами контроля ошибок на основе UDP.
c. Канал предоставляет малый верхний предел времени, в течение которого повторная передача одного кадра может блокировать завершённую передачу и сборку других правильно и полностью принятых IP-пакетов, передача которых была начата до отправки отсутствующего кадра. Ограничение задержки позволяет избежать усиления конкуренции или взаимодействия между различными потоками пакетов (см. также раздел 3.2).
Примеры протоколов ARQ с низкой настойчивостью повторных передач включают [SAM96, WARD95, CHE00].
2.4 Выбор настойчивости повторных передач
Максимальный TCP RTO является верхней границей максимального времени, в течение которого TCP будет ожидать, прежде чем выполнить повторную передачу. Большинство реализаций TCP обычно будут иметь TCP RTO, по меньшей мере в несколько раз превышающий задержку пути.
Установка меньшей настойчивости повторных передач на канальном уровне (например, порядка 2–5 попыток повторной передачи) уменьшает потенциальное взаимодействие с таймером TCP RTO и поэтому может уменьшить вероятность присутствия дублирующихся копий одного и того же пакета в буфере передачи канала при некоторых сценариях потерь.
Канал, использующий физический уровень с малой задержкой распространения, может допускать десятки попыток повторной передачи для доставки одного кадра и при этом всё ещё удовлетворять ограничению из пункта (b) раздела 2.3. В этом случае малой считается задержка, при которой суммарное время передачи пакета по каналу значительно меньше 100 мс (обычного значения гранулярности внутреннего системного таймера TCP).
Пакет может проходить по нескольким последовательным каналам на всём своём пути между конечными точками. Следовательно, это является доводом в пользу значительно меньшей настойчивости повторных передач на каждом отдельном канале, поскольку задержка из-за настойчивости повторных передач накапливается вдоль пути, выбранного каждым пакетом.
Некоторые разработчики реализаций выбрали меньшую настойчивость повторных передач, полагаясь на решение TCP или приложения UDP повторно передавать любые пакеты, которые не были восстановлены протоколом ARQ канального уровня.
2.5 Влияние недоступности каналов
Также могут потребовать рассмотрения каналы, испытывающие устойчивые потери, при которых многие последовательные кадры повреждаются в течение длительного времени. Примеры поведения канала, приводящего к недоступности канала, включают замирание, роуминг и некоторые формы помех. Во время события потери повышается вероятность того, что запрос повторной передачи будет повреждён, и/или повышается вероятность того, что повторно переданный кадр также будет потерян. Событие потери такого типа часто называют «временной недоступностью».
Если временная недоступность длится дольше TCP RTO, отправитель TCP также выполнит повторную передачу на транспортном уровне. В то же время отправитель TCP уменьшит своё окно перегрузки (cwnd) до 1 сегмента (пакета), пересчитает свой RTO и будет ожидать пакет ACK. Если подтверждение не получено, TCP выполнит повторную передачу снова, вплоть до предела повторных попыток. TCP определяет, что недоступность закончилась (то есть что пропускная способность пути восстановлена), только при получении ACK. Если настойчивость повторных передач протокола ARQ канального уровня приводит к отбрасыванию каналом на пути ACK, отправитель TCP должен ожидать следующей повторной передачи по RTO и её ACK, чтобы узнать, что канал восстановлен. Это может произойти через много секунд после окончания временной недоступности.
Когда канальный уровень способен различать набор классов обслуживания канала (см. раздел 3.3), настойчивость повторных передач ARQ канального уровня, превышающая длительность наибольшего события потери на канале, может быть полезна для сеанса TCP. Это позволило бы TCP быстро восстановить передачу без необходимости ожидать тайм-аута повторной передачи, в целом улучшая производительность TCP при временных недоступностях. Реализация таких схем остаётся предметом исследований.
Когда недоступность возникает у отправителя, совместно использующего общий канал с другими узлами, неконтролируемая высокая настойчивость повторных передач может продолжать потреблять ресурсы передачи в течение недоступности. Это может быть нежелательно, поскольку уменьшает доступную для других совместно использующих канал узлов пропускную способность, хотя они не обязательно испытывают ту же недоступность. В противном случае эти узлы могли бы использовать канал для более продуктивных передач. В таких случаях настойчивость повторных передач часто ограничивается другим управляющим механизмом. Для противодействия таким эффектам конкуренции протоколы ARQ могут задерживать запросы повторной передачи или откладывать повторную передачу запрошенных кадров до окончания недоступности у отправителя.
Альтернативный предложенный подход для канального уровня, способного идентифицировать отдельные потоки, состоит в использовании низкой настойчивости повторных передач на канальном уровне (раздел 2.3) вместе с механизмом более высокого уровня, например механизмом, пытающимся доставить по одному пакету (или целому сегменту TCP) на TCP-поток после события потери [DRAFTKARN02]. Это предназначено для обеспечения быстрого восстановления передачи TCP. Алгоритмы реализации этого остаются областью исследований.
3. Обработка пакетов и потоков
3.1 Упорядочение пакетов
Распространённый предмет обсуждения — следует ли разрешать каналу пересылать пакеты в порядке, отличающемся от порядка, в котором они первоначально были получены на его интерфейсе передачи.
IP-сети не обязаны доставлять все IP-пакеты по порядку, хотя в большинстве случаев сети доставляют IP-пакеты в их исходном порядке передачи. Маршрутизаторы, поддерживающие очереди на основе классов, меняют порядок полученных пакетов, переупорядочивая пакеты в разных потоках, но обычно сохраняют порядок внутри каждого потока.
Очереди на основе политик, обеспечивающие более справедливый доступ к каналу, также могут менять порядок пакетов. Всё ещё ведутся значительные обсуждения оптимальных алгоритмов и оптимальных размеров очередей для определённых скоростей канала. Однако это не связано с использованием ARQ канального уровня и применимо к любому маршрутизатору, являющемуся потенциальным узким местом.
Хотя небольшие изменения порядка распространены в IP-сетях [BEN00], существенное переупорядочение внутри потока нежелательно, поскольку оно может иметь ряд последствий:
a. Переупорядочение увеличит джиттер пакетов для приложений реального времени. Это может привести к потере данных приложения, если принимающее приложение использует небольшой буфер воспроизведения.
b. Переупорядочение приведёт к чередованию поступления сегментов TCP, вызывая формирование дублирующихся ACK (dupacks), что приведёт к предположениям о потерях. Получение ACK, за которым следует последовательность из трёх одинаковых dupacks, заставляет отправителя TCP запускать быструю повторную передачу и восстановление — форму предотвращения перегрузки, поскольку TCP всегда предполагает, что потеря пакета вызвана перегрузкой [RFC2581, STE94]. Это снижает эффективность пропускной способности TCP с точки зрения приложения, хотя не должно влиять на целостность данных.
Кроме того, переупорядочение может отрицательно повлиять на обработку некоторыми существующими плохо реализованными стеками TCP/IP, вызывая нежелательные побочные эффекты в плохо реализованном коде сборки IP-фрагментов, плохо реализованном коде демультиплексирования IP (фильтра) или в плохо реализованных приложениях UDP.
Эффекты упорядочения также необходимо учитывать при нарушении парадигмы «из конца в конец» и оценке ретрансляторов транспортного уровня, таких как реализации split-TCP или Protocol Enhancing Proxies [RFC3135].
Как и в случае общей задержки пути, на потоки TCP и UDP влияет накопленный эффект переупорядочения вдоль всего пути. Разработчики протоколов канального уровня не должны предполагать, что их канал — единственный канал, выполняющий переупорядочение пакетов, поскольку некоторый уровень переупорядочения может быть внесён другими каналами на том же пути или обработкой маршрутизатора в сети [BEN00]. В идеале протокол канального уровня не следует способствовать переупорядочению внутри потока или, по меньшей мере, должен обеспечивать, чтобы он не существенно увеличивал уровень переупорядочения внутри потока. Для достижения этого требуется буферизация у приёмника канального уровня. Общий требуемый объём буферизации является функцией произведения пропускной способности канала на задержку и уровня настойчивости повторных передач ARQ и ограничен размером окна канала.
Ряд экспериментальных протоколов ARQ допускал доставку не по порядку [BAL95, SAM96, WARD95].
3.2 Использование ARQ канального уровня для поддержки нескольких потоков
Можно ожидать, что большинство каналов одновременно переносят более одного IP-потока. Ожидается, что некоторые высокопроизводительные каналы переносят очень большое число одновременных потоков, часто от и к большому числу различных конечных хостов. При использовании нескольких приложений на конечном хосте множественные потоки можно считать нормой, а не исключением, даже для каналов последнего перехода.
Когда пакеты нескольких потоков одновременно находятся в передаче внутри протокола ARQ канального уровня, ARQ может вызывать ряд дополнительных эффектов:
a. ARQ вносит переменную задержку (джиттер) в TCP-поток, совместно использующий канал с другим потоком, испытывающим потери. Эта дополнительная задержка, обусловленная необходимостью канала обеспечивать доставку пакетов в последовательном порядке, может отрицательно повлиять на другие приложения, совместно использующие канал, и может увеличить продолжительность начального периода медленного старта для TCP-потоков этих приложений. Это существенно для короткоживущих TCP-потоков (например, используемых HTTP/1.0 и более ранними версиями), которые проводят большую часть своего существования в режиме медленного старта.
b. ARQ вносит джиттер в UDP-потоки, совместно использующие канал с другим потоком, испытывающим потери. Сквозной протокол может не требовать надёжной доставки для своих потоков, особенно если он поддерживает приложение, чувствительное к задержке.
c. ARQ с высокой настойчивостью может задерживать пакеты достаточно долго, чтобы вызвать преждевременное срабатывание таймера RTO другого TCP-потока, хотя современные реализации TCP не должны испытывать этого, поскольку рассчитанные ими значения RTO должны оставлять достаточный запас относительно RTT пути, чтобы справляться с разумными величинами джиттера.
Изменение порядка пакетов, принадлежащих различным потокам, может быть желательным [LUD99b, CHE00] для достижения справедливого совместного использования канала между установленными сеансами передачи больших объёмов данных и сеансами, передающими меньшие объёмы данных, но выигрывающими от меньшей задержки транзита по каналу. Сохранять порядок внутри каждого отдельного потока, чтобы избежать последствий изменения порядка, описанных выше в разделе 3.1, целесообразно.
3.3 Дифференциация классов обслуживания канала
Высокая настойчивость ARQ обычно считается непригодной для многих приложений, использующих UDP, когда надёжная доставка требуется не всегда и когда она может вносить неприемлемый джиттер, однако при определённых условиях канала она может быть полезна для передач больших объёмов данных. Поэтому желательна схема, дифференцирующая пакетные потоки на два или более класса, чтобы предоставлять каждому классу различное обслуживание.
Наблюдение за поведением потока может показать, какие потоки управляемы и чувствительны к перегрузке, а какие неуправляемы и не чувствительны, чтобы можно было обрабатывать их по-разному и обеспечивать справедливость. Однако оно не может показать, предполагается ли приложением, что поток является надёжным или ненадёжным, либо что требуется приложению для наилучшей работы.
Поэтому поддержка различных служб канала для различных классов потоков требует, чтобы канал мог отличать различные потоки друг от друга. Обычно для этого требуется явное указание класса, связанного с каждым потоком.
Некоторые возможные схемы указания класса пакета включают:
a. Использование битов Type of Service (ToS) в IP-заголовке [RFC791]. IETF заменила эти глобально определённые биты, которые не получили широкого использования, моделью дифференцированного обслуживания (diffserv [RFC2475, RFC3260]). В diffserv каждый пакет несёт Differentiated Service Code Point (DSCP), указывающую, к какому из набора классов diffserv принадлежит поток. Каждый маршрутизатор сопоставляет значение DSCP полученного IP-пакета одному из набора Per Hop Behaviours (PHBs) при обработке пакета в сети. Варианты применения Diffserv включают маршрутизацию на основе политик, организацию очередей на основе классов и поддержку других метрик QoS, включая приоритет IP-пакета, задержку, надёжность и стоимость.
b. Проверку заголовка сетевого пакета и просмотр типа IP-протокола [RFC791], чтобы получить представление об используемом транспортном протоколе и тем самым предположить его потребности. Это невозможно при передаче зашифрованной полезной нагрузки, например при использовании расширений безопасности IP (IPSec) с шифрованием полезной нагрузки Encapsulation Security Payload (ESP) [RFC2406].
c. Проверку информации заголовка транспортного пакета для просмотра заголовков TCP или UDP и номеров портов (например, [PAR00, BAL95]). Это невозможно при использовании шифрования полезной нагрузки, например IPSec с шифрованием полезной нагрузки ESP [RFC2406], и создаёт накладные расходы на обработку каждого пакета, передаваемого по каналу.
Однако эти схемы имеют некоторые недостатки:
i. Значения ToS/Differentiated Services Code Point (DSCP) [RFC2475] могут устанавливаться ненадёжно и могут быть перезаписаны промежуточными маршрутизаторами на пути пакета. Эти значения могут устанавливаться ISP и не обязательно указывают уровень надёжности, требуемый конечным приложением. Канал должен быть настроен со знанием локального значения этих величин.
ii. Туннелирование трафика (например, GRE, MPLS, L2TP, IP-in-IP-инкапсуляция) может агрегировать потоки различных транспортных классов, усложняя классификацию отдельных потоков схемами (b) и (c) и вызывая дополнительную обработку заголовков при проверке содержимого туннеля.
iii. Использование номера TCP/UDP-порта предполагает определённое поведение и требования приложения. Новые приложения или протоколы могут сделать эти предположения недействительными, как и использование, например, Network Address Port Translation, при котором номера портов переназначаются [RFC3022].
iv. В IPv6 весь заголовок IPv6 должен быть разобран для обнаружения протокола транспортного уровня, что добавляет сложности проверке заголовка. Это также предполагает, что шифрование полезной нагрузки IPSec не используется.
Несмотря на трудности предоставления основы для точной идентификации потоков, подход (a) может быть полезен и предпочтительнее добавления оптимизаций, запускаемых проверкой содержимого конкретных IP-пакетов. Некоторые такие оптимизации подробно обсуждаются в [LUD99b].
Управление потоками желательно; чёткая идентификация потоков увеличивает число средств, доступных разработчику канала, и допускает более сложные стратегии ARQ, которые в противном случае могут делать ошибочные предположения о требованиях и поведении трафика, когда идентификация потоков не выполняется.
Каналы, не способные чётко и безопасно различать потоки, чувствительные к задержке, например мультимедиа реального времени, DNS-запросы или telnet, и потоки, нечувствительные к задержке, например передачи больших объёмов данных по ftp или надёжная многоадресная передача файлов, не могут безопасно разделять классы обслуживания канала. Поэтому все потоки должны испытывать одинаковое поведение канала.
В общем случае, если разделение потоков по классам непрактично, для ARQ канала лучше всего подходит низкая настойчивость.
4. Выводы
Разработчики протоколов канала могут применять ряд методов для противодействия последствиям ошибок или потерь в канале. Одним из таких методов является Automatic Repeat ReQuest, ARQ, который использовался и продолжает использоваться на каналах, передающих IP-трафик. Протокол ARQ повторно передаёт кадры канала, повреждённые при передаче по каналу. ARQ канала может значительно повысить вероятность успешной передачи IP-пакетов по каналам, подверженным эпизодическим потерям кадров.
Меньшая частота потерь пакетов в целом полезна транспортным протоколам и приложениям конечных узлов. Приложения, использующие TCP, в целом выигрывают от интернет-путей с малыми потерями или без потерь и с малой задержкой пути в оба конца. Это снижает влияние на приложения, обеспечивает более быстрый рост окна перегрузки TCP в ходе медленного старта и гарантирует оперативную реакцию на обмены сквозного протокола (например, повторную передачу, индикации перегрузки). Приложения, использующие другие транспортные протоколы, например UDP или SCTP, также выигрывают от малых потерь и своевременной доставки.
Побочным эффектом ARQ канала является увеличение задержки транзита по каналу при повторной передаче кадров. При низких уровнях ошибок многие подробности ARQ, такие как степень настойчивости или любая возникающая доставка не по порядку, становятся несущественными. Большинство потерь кадров будет устранено одной или двумя попытками повторной передачи, и это в целом вряд ли окажет существенное влияние, например, на TCP. Однако на совместно используемых каналах с большой задержкой влияние ARQ на другие UDP- или TCP-потоки может приводить к нежелательному джиттеру.
При сильно изменяющихся уровнях ошибок высокая настойчивость ARQ канала может обеспечивать хорошую производительность для одного TCP-потока. Однако при совместном использовании пропускной способности одного канала многими потоками могут возникать взаимодействия между потоками. Процедура ARQ канала, обеспечивающая управление потоками, будет полезна. Меньшая настойчивость ARQ также может иметь достоинства и предпочтительна для приложений, использующих UDP. Обоснование состоит в том, что канал может выполнять полезную работу, пересылая некоторые полные пакеты, и что блокировать все потоки повторной передачей кадров одного пакета с высокой настойчивостью нежелательно.
Во время недоступности канала взаимодействия между ARQ и несколькими потоками менее существенны; протокол ARQ, вероятно, будет в равной степени безуспешен при повторной передаче кадров всех потоков. Высокая настойчивость может быть полезна TCP-потокам, обеспечивая быстрое восстановление после восстановления канала.
Низкая настойчивость ARQ особенно полезна, когда классифицировать потоки трафика и, следовательно, обрабатывать каждый поток независимо трудно или невозможно, а также когда ёмкость канала способна обслуживать большое число одновременных потоков.
Разработчикам ARQ канала следует учитывать последствия своего проекта для более широкого Интернета. Такие эффекты, как увеличенная задержка транзита, джиттер и изменение порядка, накапливаются, когда они возникают на нескольких каналах вдоль интернет-пути. Поэтому очень трудно сказать, сколько каналов с ARQ может последовательно существовать вдоль произвольного интернет-пути между конечными узлами, особенно поскольку используемый путь и его каналы могут меняться со временем.
Итак, когда каналы не могут классифицировать потоки трафика и обрабатывать их раздельно, в целом желательна низкая настойчивость; в целом желательно сохранять порядок пакетов. Чрезвычайно высокая и совершенная настойчивость в целом нежелательны; ARQ с высокой настойчивостью — плохая идея, если только классификация потоков и подробное, точное знание требований потоков не делают возможным применение высокой настойчивости там, где она будет полезна.
В настоящее время недостаточно опыта, чтобы рекомендовать конкретную схему ARQ для какого-либо класса канала. Также важно понимать, что ARQ канала — лишь один из методов восстановления после ошибок и что вместо ARQ или совместно с ним могут использоваться другие дополняющие методы физического уровня для повышения общей пропускной способности канала для IP-трафика.
Выбор потенциальных схем включает адаптацию скорости передачи данных, адаптацию полосы сигнала, адаптацию мощности передачи, адаптивную модуляцию, адаптивную избыточность информации / прямую коррекцию ошибок и перемежение. Все эти схемы могут использоваться для повышения энергии принятого сигнала на бит и, следовательно, для снижения частоты ошибок, потерь кадров и возникающих потерь пакетов при заданных условиях канала.
Необходимы дополнительные исследования, чтобы яснее определить значимость и компромиссы между указанными выше вопросами для различных типов каналов и различных типов сред передачи. Было бы полезно, если бы исследователи и разработчики при описании своего опыта ясно указывали модель потерь, ёмкость и характеристики канала, задержки канала и сквозного пути, сведения о TCP, а также число (и подробности) потоков, совместно использующих канал. В каждом случае рекомендуется также учитывать конкретные сведения о характеристиках и механизмах канала; решения зависят от условий.
5. Соображения безопасности
Не выявлено последствий для безопасности, непосредственно влияющих на IP-трафик. Однако ненадёжная служба канала может отрицательно влиять на некоторые существующие протоколы распространения ключей и управления ими на канальном уровне, если на канале также используется шифрование канала.
Атаки отказа в обслуживании, использующие поведение протокола канала, например использующие знание его поведения при повторных передачах и задержки распространения для создания определённой формы подавления сигналов, могут быть специфичными для отдельного сценария канала.
6. Соображения IANA
Никаких выделений IANA не требуется.
7. Благодарности
Значительная часть описанного здесь была разработана на основе сводки подмножества обсуждений в архивированной почтовой рассылке IETF PILC. Мы благодарим участников PILC за энергичные дискуссии.
В частности, авторы хотели бы поблагодарить Spencer Dawkins, Aaron Falk, Dan Grossman, Merkourios Karaliopoulos, Gary Kenward, Reiner Ludwig и Jean Tourrilhes за их подробные комментарии.
8. Ссылки
Ссылки вида RFCnnnn — это документы Internet Request for Comments (RFC), доступные в сети по адресу http://www.rfc-editor.org/.
8.1 Нормативные ссылки
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
September 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 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.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
8.2 Информационные ссылки
[BAL95] Balakrishnan, H., Seshan, S. and R. H. Katz,
"Improving Reliable Transport and Handoff Performance
in Cellular Wireless Networks", ACM MOBICOM, Berkeley,
1995.
[BAL97] Balakrishnan, H., Padmanabhan, V. N., Seshan, S. and
R. H. Katz, "A Comparison of Mechanisms for Improving
TCP Performance over Wireless Links", IEEE/ACM
Transactions on Networking, 5(6), pp. 756-759, 1997.
[BEN00] Bennett, J. C., Partridge, C. and N. Schectman, "Packet
Reordering is Not Pathological Network Behaviour",
IEEE/ACM Transactions on Networking, 7(6), pp. 789-798,
2000.
[BHA97] Bhagwat, P., Bhattacharya, P., Krishna A. and S. K.
Tripathi, "Using channel state dependent packet
scheduling to improve TCP throughput over wireless
LANs", ACM/Baltzer Wireless Networks Journal, (3)1,
1997.
[CHE00] Cheng, H. S., G. Fairhurst et al., "An Efficient
Partial Retransmission ARQ Strategy with Error Codes
by Feedback Channel", IEE Proceedings - Communications,
(147)5, pp. 263-268, 2000.
[DRAFTKARN02] Karn, P., Ed., "Advice for Internet Subnetwork
Designers", Work in Progress.
[DRAFTHAN01] Handley, M., Floyd, S. and J. Widmer, "TCP Friendly
Rate Control (TFRC): Protocol Specification", Work in
Progress.
[ECK98] Eckhardt, D. A. and P. Steenkiste, "Improving Wireless
LAN Performance via Adaptive Local Error Control",
IEEE ICNP, 1998.
[FER99] Ferrero, A., "The Eternal Ethernet", Addison-Wesley,
1999.
[ISO4335a] HDLC Procedures: Specification for Consolidation of
Elements of Procedures, ISO 4335 and AD/1,
International Standardization Organization, 1985.
[ISO4335b] HDLC Procedures: Elements of Procedures, Amendment 4:
Multi-Selective Reject Option, ISO 4335/4,
International Standards Organization, 1991.
[ISO7776] Specification for X.25 LAPB-Compatible DTE Data Link
Procedures, ISO 4335/4, International Standards
Organization, 1985.
[KEN87] Kent, C. A. and J. C. Mogul, "Fragmentation
Considered Harmful", Proceedings of ACM SIGCOMM 1987,
ACM Computer Communications Review, 17(5), pp. 390-401,
1987.
[LIN93] Lin, S. and D. Costello, "Error Control Coding:
Fundamentals and Applications", Prentice Hall, 1993.
[LUD99a] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K., and A.
Joseph, "Multi-Layer Tracing of TCP over a Reliable
Wireless Link", ACM SIGMETRICS, pp. 144-154, 1999.
[LUD99b] Ludwig, R., Konrad, A., Joseph, A. and R. H. Katz,
"Optimizing the End-to-End Performance of Reliable
Flows over Wireless Links", ACM MobiCOM, 1999.
[MEY99] Meyer, M., "TCP Performance over GPRS", IEEE Wireless
Communications and Networking Conference, 1999.
[PAR00] Parsa, C. and J. J. Garcia-Luna-Aceves, "Improving TCP
Performance over Wireless Networks at the Link Layer",
ACM Mobile Networks and Applications Journal, (5)1,
pp. 57-71, 2000.
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1191, November 1990.
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992.
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP
Over Satellite Channels using Standard Mechanisms",
BCP 28, RFC 2488, January 1999.
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret V. and
N. Vaidya, "Long Thin Networks", RFC 2757, January
2000.
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J.,
Tran, D., Henderson, T., Heidemann, J., Touch, J.,
Kruse, H., Ostermann, S., Scott K. and J. Semke
"Ongoing TCP Research Related to Satellites",
RFC 2760, February 2000.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and
N. Vaidya, "End-to-end Performance Implications of
Links with Errors", BCP 50, RFC 3155, August 2001.
[SALT81] Saltzer, J. H., Reed, D. P. and D. Clark, "End-to-End
Arguments in System Design", Second International
Conference on Distributed Computing Systems, pp.
509-512, 1981. Published with minor changes in ACM
Transactions in Computer Systems (2)4, pp. 277-288,
1984.
[SAM96] Samaraweera, N. and G. Fairhurst, "Robust Data Link
Protocols for Connection-less Service over Satellite
Links", International Journal of Satellite
Communications, 14(5), pp. 427-437, 1996.
[SAM98] Samaraweera, N. and G. Fairhurst, "Reinforcement of
TCP/IP Error Recovery for Wireless Communications",
ACM Computer Communications Review, 28(2), pp. 30-38,
1998.
[STE94] Stevens, W. R., "TCP/IP Illustrated, Volume 1",
Addison-Wesley, 1994.
[STONE00] Stone, J. and C. Partridge, "When the CRC and TCP
Checksum Disagree", Proceedings of SIGCOMM 2000, ACM
Computer Communications Review 30(4), pp. 309-321,
September 2000.
[WARD95] Ward, C., et al., "A Data Link Control Protocol for LEO
Satellite Networks Providing a Reliable Datagram
Service", IEEE/ACM Transactions on Networking, 3(1),
1995.