Advice for Internet Subnetwork Designers
RFC 3819 предоставляет рекомендации проектировщикам цифрового коммуникационного оборудования, протоколов канального уровня и пакетных локальных сетей, поддерживающих IP. Документ рассматривает выбор MTU и фрагментацию, кадрирование, широковещательную и многоадресную передачу, надёжность, QoS, задержки, буферизацию, мобильность, маршрутизацию и безопасность. Он подчёркивает принцип «из конца в конец»: функции следует размещать на подходящем уровне, а механизмы подсети не должны без необходимости ухудшать производительность, масштабируемость или надёжность Интернет-протоколов. Документ опубликован как Best Current Practice (BCP 89) и запрашивает обсуждение и предложения по улучшению.
Рабочая группа сети P. Karn, ред.
Запрос комментариев: 3819 Qualcomm
BCP: 89 C. Bormann
Категория: Лучшая современная практика Universitaet Bremen TZI
G. Fairhurst
University of Aberdeen
D. Grossman
Motorola, Inc.
R. Ludwig
Ericsson Research
J. Mahdavi
Novell
G. Montenegro
Sun Microsystems Laboratories, Europe
J. Touch
USC/ISI
L. Wood
Cisco Systems
Июль 2004
Рекомендации для разработчиков интернет-подсетей
Статус данного меморандума
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2004).
Аннотация
Этот документ содержит рекомендации для разработчиков цифрового
коммуникационного оборудования, протоколов канального уровня и
локальных сетей с коммутацией пакетов (совместно именуемых
подсетями), которые желают поддерживать интернет-протоколы, но могут
быть не знакомы с архитектурой Интернета и последствиями своих
проектных решений для производительности и эффективности Интернета.
Karn, et al. Лучшая современная практика [Страница 1]
RFC 3819 Рекомендации для разработчиков интернет-подсетей Июль 2004
Содержание
1. Введение и обзор. . . . . . . . . . . . . . . . . . . . . . . 2
2. Максимальные единицы передачи (MTU) и IP-фрагментация . . . . 4
2.1. Выбор MTU в медленных сетях. . . . . . . . . . . . . . . 6
3. Формирование кадров в подсетях с установлением соединения . . 7
4. Подсети с установлением соединения. . . . . . . . . . . . . . 9
5. Широковещательная передача и обнаружение . . . . . . . . . . . 10
6. Многоадресная передача . . . . . . . . . . . . . . . . . . . . 11
7. Подсети с предоставлением полосы пропускания по требованию
(BoD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Надёжность и управление ошибками. . . . . . . . . . . . . . . 14
8.1. TCP в сравнении с повторной передачей на канальном
уровне . . . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Восстановление после отказов подсети . . . . . . . . . . 17
8.3. CRC, контрольные суммы и обнаружение ошибок. . . . . . . 18
8.4. Как работает TCP. . . . . . . . . . . . . . . . . . . . 20
8.5. Характеристики производительности TCP. . . . . . . . . . 22
8.5.1. Формулы . . . . . . . . . . . . . . . . . . . . 22
8.5.2. Допущения. . . . . . . . . . . . . . . . . . . . 23
8.5.3. Анализ влияния канального уровня на
производительность TCP. . . . . . . . . . . . . 24
9. Аспекты качества обслуживания (QoS). . . . . . . . . . . . . . 26
10. Справедливость в сравнении с производительностью. . . . . . . . 29
11. Характеристики задержки. . . . . . . . . . . . . . . . . . . . 30
12. Асимметрии полосы пропускания. . . . . . . . . . . . . . . . . 31
13. Буферизация, управление потоком и перегрузкой . . . . . . . . . 31
14. Сжатие. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. Переупорядочивание пакетов. . . . . . . . . . . . . . . . . . . 36
16. Мобильность . . . . . . . . . . . . . . . . . . . . . . . . . . 37
17. Маршрутизация. . . . . . . . . . . . . . . . . . . . . . . . . 39
18. Аспекты безопасности. . . . . . . . . . . . . . . . . . . . . . 41
19. Участники . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
20. Информативные ссылки . . . . . . . . . . . . . . . . . . . . . 45
21. Адреса участников. . . . . . . . . . . . . . . . . . . . . . . 57
22. Адреса авторов . . . . . . . . . . . . . . . . . . . . . . . . 58
23. Полное заявление об авторских правах . . . . . . . . . . . . . 60
1. Введение и обзор
IP, интернет-протокол [RFC791] [RFC2460], является основным
протоколом Интернета. IP определяет простую сеть с коммутацией
пакетов «без установления соединения». Успех Интернета в значительной
мере объясняется простотой IP, «сквозным принципом» [SRC81], на
котором основан Интернет, и обусловленной этим простотой переноса IP
по широкому разнообразию подсетей, которые не обязательно
проектировались с учётом IP. Подсетью называется любая сеть,
работающая непосредственно ниже уровня IP для соединения двух или
более систем, использующих IP (то есть конечных узлов или
маршрутизаторов). В простейшей форме это может быть прямое соединение
между IP-системами (например, посредством отрезка кабеля или
беспроводной среды).
Karn, et al. Лучшая современная практика [Страница 2]
RFC 3819 Рекомендации для разработчиков интернет-подсетей Июль 2004
В этом документе подсеть определяется как сеть уровня 2, то есть
сеть, которая не полагается на службы IP-маршрутизаторов для
пересылки пакетов между частями подсети. Однако IP-маршрутизаторы
могут выполнять мостовую передачу кадров на уровне 2 между частями
подсети. Иногда удобно объединить группу таких подсетей в одну
логическую подсеть. Протоколы IP-маршрутизации (например, OSPF,
IS-IS и PIM) можно настроить для поддержки такого объединения, но
обычно они представляют подсеть уровня 3, а не подсеть уровня 2. Это
также может приводить к тому, что конкретный пакет несколько раз
проходит по одной и той же подсети уровня 2 через промежуточный шлюз
уровня 3 (маршрутизатор). Поскольку такое объединение требует
компонентов уровня 3, связанные с ним вопросы выходят за рамки этого
документа.
Однако, хотя многие подсети переносят IP, они не обязательно делают
это с максимальной эффективностью, минимальной сложностью или
стоимостью, а также не обязательно реализуют определённые функции,
позволяющие эффективно поддерживать новые, приобретающие всё большую
важность функции Интернета, такие как многоадресная передача или
качество обслуживания.
В условиях взрывного роста Интернета IP-пакеты составляют всё более
значительную долю трафика, переносимого телекоммуникационными сетями
мира. Поэтому имеет смысл оптимизировать как существующие, так и
новые технологии подсетей для IP настолько, насколько это возможно.
Оптимизация подсети для IP включает три взаимодополняющих
соображения:
1. Предоставление функциональности, достаточной для переноса IP.
2. Устранение ненужных функций, которые увеличивают стоимость или
сложность.
3. Выбор параметров подсети, максимизирующих производительность
интернет-протоколов.
Поскольку IP настолько прост, соображение 2 представляет большую
проблему, чем соображение 1. Иными словами, разработчики подсетей
совершают гораздо больше ошибок действия, чем ошибок бездействия.
Однако некоторые усовершенствования функций Интернета, такие как
многоадресная передача и качество обслуживания, существенно выигрывают
от поддержки, предоставляемой нижележащими подсетями сверх той,
которая необходима для переноса «традиционного» одноадресного IP с
доставкой по мере возможности.
Karn, et al. Лучшая современная практика [Страница 3]
RFC 3819 Рекомендации для разработчиков интернет-подсетей Июль 2004
Важным соображением при эффективном проектировании любой многоуровневой
сети связи является выбор подходящего уровня или уровней для
реализации заданной функции. Этот вопрос впервые был рассмотрен в
основополагающей статье «End-to-End Arguments in System Design»
[SRC81]. В этой статье утверждалось, что многие функции могут быть
корректно реализованы *только* сквозным образом, то есть на высших
уровнях протокола, вне подсети. К этим функциям относятся обеспечение
надёжной доставки данных и использование криптографии для обеспечения
конфиденциальности и целостности сообщений.
Такие функции нельзя предоставить исключительно путём объединения
служб на каждом участке; дублирование этих функций на нижних уровнях
протокола (то есть внутри подсети) может быть излишне избыточным или
даже вредным для стоимости и производительности.
Однако частичное дублирование функциональности на нижнем уровне
*иногда* может быть оправдано соображениями производительности,
безопасности или доступности. Примеры включают повторную передачу на
канальном уровне для повышения производительности необычно подверженного
потерям канала, например мобильного радиоканала, шифрование на уровне
канала, предназначенное для противодействия анализу трафика, а также
резервные линии передачи для повышения доступности, увеличения
пропускной способности или гарантирования производительности для
определённых классов трафика. Дублирование функций протокола следует
выполнять только с пониманием последствий на уровне системы, включая
возможные взаимодействия с механизмами верхних уровней.
Первоначальная архитектура Интернета находилась под влиянием сквозного
принципа [SRC81] и, по нашему мнению, была одной из причин успеха
Интернета.
Остальная часть этого документа рассматривает различные вопросы
проектирования подсетей, которые авторы считают значимыми для
эффективной поддержки IP.
2. Максимальные единицы передачи (MTU) и IP-фрагментация
Пакеты IPv4 (дейтаграммы) различаются по размеру: от 20 байтов
(размер одного только заголовка IPv4) до максимума в 65535 байтов.
Подсети не обязаны поддерживать IP-пакеты максимального размера
(64KB), поскольку IP предоставляет схему, разбивающую пакеты,
слишком большие для данной подсети, на фрагменты, которые передаются
как независимые IP-пакеты и собираются вновь в пункте назначения.
Максимальный размер пакета, поддерживаемый подсетью, известен как её
максимальная единица передачи (MTU).
Подсети могут, но не обязаны, указывать длину каждого переносимого ими
пакета. Одним из примеров является Ethernet с широко используемым
заголовком DIX [DIX82] (а не IEEE 802.3 [IEEE8023]), в котором
отсутствует поле длины для указания фактической длины данных, когда
пакет дополняется до минимального размера в 60 байтов. Это не является
проблемой для несжатого IP, поскольку каждый IP-пакет содержит
собственное поле длины.
Karn, et al. Лучшая современная практика [Страница 4]
RFC 3819 Рекомендации для разработчиков интернет-подсетей Июль 2004
Однако если используется необязательное сжатие заголовка [RFC1144]
[RFC2507] [RFC2508] [RFC3095], необходимо, чтобы формирование кадров
канала указывало длину кадра, поскольку она нужна для восстановления
исходного заголовка.
В IP версии 4 (версии, ныне широко применяемой) фрагментация может
происходить либо на отправляющем узле, либо в промежуточном
маршрутизаторе, а фрагменты при необходимости могут дополнительно
фрагментироваться на последующих маршрутизаторах.
В IP версии 6 [RFC2460] фрагментация может происходить только на
отправляющем узле; она не может происходить в маршрутизаторе
(именуемая в этом документе «фрагментацией маршрутизатором»).
И IPv4, и IPv6 предоставляют процедуру «обнаружения MTU пути»
[RFC1191] [RFC1435] [RFC1981], которая позволяет отправляющему узлу
избежать фрагментации, обнаруживая минимальный MTU вдоль заданного
пути и соответственно уменьшая размеры своих пакетов. Эта процедура
необязательна в IPv4 и IPv6.
Обнаружение MTU пути широко развёрнуто, но иногда сталкивается с
проблемами. Некоторые маршрутизаторы не генерируют сообщения ICMP,
передающие отправителю информацию о MTU пути, а иногда сообщения ICMP
блокируются чрезмерно ограничительными межсетевыми экранами. Результатом
может быть «чёрная дыра MTU пути» [RFC2923] [RFC1435].
Процедура обнаружения MTU пути, сохранение чёрных дыр MTU пути и
исключение фрагментации маршрутизатором из IPv6 отражают консенсус
технического сообщества Интернета в том, что фрагментации
маршрутизатором лучше избегать. Это требует, чтобы подсети поддерживали
MTU «разумно» большого размера. Все конечные узлы IPv4 обязаны
принимать и собирать вновь IP-пакеты размером 576 байтов [RFC791], но
столь малое значение было бы явно неэффективным. Поскольку IPv6 не
предусматривает фрагментацию маршрутизаторами, [RFC2460] определяет
больший минимальный MTU в 1280 байтов. Любая подсеть с внутренней
полезной нагрузкой пакета менее 1280 байтов должна реализовать
механизм, выполняющий фрагментацию и повторную сборку IP-пакетов в
кадры подсети и из кадров подсети, если она должна поддерживать IPv6.
Если подсеть не может непосредственно поддерживать «разумный» MTU
собственными механизмами формирования кадров, ей следует внутренне
фрагментировать пакеты. То есть ей следует прозрачно разбивать
IP-пакеты на внутренние элементы данных и собирать их вновь на другом
конце подсети.
Karn, et al. Лучшая современная практика [Страница 5]
RFC 3819 Рекомендации для разработчиков интернет-подсетей Июль 2004
Остаётся вопрос о том, какой MTU является «разумным». Ethernet (10 и
100 Мбит/с) имеет MTU 1500 байтов, и вследствие повсеместного
распространения Ethernet немногие интернет-пути в настоящее время
имеют MTU больше этого значения. Это существенно ограничивает
полезность более крупных MTU, предоставляемых другими подсетями. В то
же время более крупные MTU становятся всё более желательными в
высокоскоростных подсетях для уменьшения накладных расходов на
обработку каждого пакета в хост-компьютерах, и разработчикам
рекомендуется предоставлять их, даже если они могут быть неприменимы,
когда Ethernet также находится на пути.
Различные схемы «туннелирования», такие как GRE [RFC2784] или IP Security в туннельном режиме [RFC2406], рассматривают IP как подсеть для IP. Поскольку туннелирование добавляет накладные расходы заголовков, оно может вызвать фрагментацию, даже когда по обе стороны хоста, выполняющего инкапсуляцию IPsec, используются одни и те же физические подсети (например, Ethernet). Туннелирование усложнило предотвращение фрагментации маршрутизаторами и увеличило частоту появления чёрных дыр MTU пути [RFC2401] [RFC2923]. Более крупные MTU подсети могут помочь смягчить эту проблему.
2.1. Выбор MTU в медленных сетях
В медленных сетях передача пакета наибольшего возможного размера может занимать значительное время. Это известно как задержка канализации или сериализации. Общее интерактивное время отклика от конца до конца не должно превышать общеизвестный предел, связанный с человеческими факторами, в 100–200 мс. Оно включает все источники задержки: задержку электромагнитного распространения, задержку в очереди, задержку сериализации и время накопления и пересылки, то есть время передачи пакета со скоростью канала.
При низких скоростях канала задержки накопления и пересылки могут преобладать в общей задержке от конца до конца; на них, в свою очередь, непосредственно влияет размер максимальной единицы передачи (MTU). Даже если интерактивному пакету назначен более высокий приоритет в очереди, ему может потребоваться дождаться завершения передачи большого пакета массовой передачи данных. Эта наихудшая задержка ожидания может быть задана надлежащим выбором MTU.
Например, если MTU установлена в 1500 байтов, пакет размером с MTU будет передаваться около 8 миллисекунд по каналу T1 (1.536 Мб/с). Но если скорость канала составляет 19.2 кб/с, время передачи становится равным 625 мс — значительно выше нашего предела в 100–200 мс. MTU размером 256 байтов уменьшила бы эту задержку до немногим более 100 мс. Однако следует соблюдать осторожность, чтобы не уменьшать MTU чрезмерно, поскольку это увеличит накладные расходы заголовков и вызовет частую фрагментацию маршрутизаторами (если не используется обнаружение MTU пути). Вероятно, именно так будет при многоадресной рассылке, где обнаружение MTU пути неэффективно.
Один из способов ограничить задержку для интерактивного трафика, не устанавливая малую MTU, — назначить этому трафику приоритет и вытеснять (прерывать)
Karn и др. Лучшая современная практика [Страница 6]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
передачу пакета с более низким приоритетом, когда в очереди появляется пакет с более высоким приоритетом. Однако ресурсы канала, использованные для передачи прерванного пакета, теряются, и общая пропускная способность уменьшится.
Другой способ ограничить задержку — реализовать схему мультиплексирования канального уровня, допускающую одновременное нахождение нескольких пакетов в процессе передачи, при этом приоритет передачи предоставляется сегментам IP-пакетов с более высоким приоритетом. Для каналов, использующих протокол Point-To-Point Protocol (PPP) [RFC1661], такую возможность предоставляет многоканальная связь нескольких классов [RFC2686] [RFC2687] [RFC2689].
ATM (асинхронный режим передачи), в котором SNDU фрагментируются и чередуются между меньшими 53-байтовыми ячейками ATM, является ещё одним примером этого метода. Однако ATM обычно используется на высокоскоростных каналах, где задержки накопления и пересылки уже минимальны, и он вносит значительное увеличение накладных расходов (~9%) вследствие добавления 5-байтовых накладных расходов ячейки к каждой 48-байтовой ячейке ATM.
Третий пример — Data-Over-Cable Service Interface Specification (DOCSIS) с типичной восходящей пропускной способностью 2.56 Мб/с или 5.12 Мб/с. Чтобы уменьшить влияние MTU размером 1500 байтов в DOCSIS 1.0 [DOCSIS1], в DOCSIS 1.1 [DOCSIS2] определён механизм фрагментации канального уровня. Для обеспечения совместимости с установленной базой DOCSIS 1.1 должна быть обратно совместима с кабельными модемами DOCSIS 1.0, которые обычно не поддерживают фрагментацию. При совместном существовании DOCSIS 1.0 и DOCSIS 1.1 нефрагментированные большие пакеты данных от кабельных модемов DOCSIS 1.0 могут влиять на качество обслуживания голосовых пакетов от кабельных модемов DOCSIS 1.1. В этом случае в [DOCSIS3] показано, что использование алгоритмов распределения полосы пропускания может смягчить этот эффект.
Подводя итог, при проектировании подсети существует фундаментальный компромисс между эффективностью и задержкой, и разработчику следует помнить об этом компромиссе.
3. Кадрирование в ориентированных на соединение подсетях
IP требует, чтобы подсети отмечали начало и конец каждого асинхронного IP-пакета переменной длины. Вот некоторые примеры каналов и подсетей, которые не предоставляют этого как внутренне присущее свойство:
1. выделенные линии, передающие синхронный поток битов;
2. B-каналы ISDN, передающие синхронный поток октетов;
3. телефонные модемы коммутируемого доступа, передающие асинхронный поток октетов;
Karn и др. Лучшая современная практика [Страница 7]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
и
4. сети Asynchronous Transfer Mode (ATM), передающие асинхронный поток «ячеек» фиксированного размера.
Интернет-сообщество определило методы кадровой синхронизации пакетов для всех этих подсетей. Point-To-Point Protocol (PPP) [RFC1661], использующий вариант HDLC, применим к битово-синхронным, октетно-синхронным и октетно-асинхронным каналам (то есть к примерам 1–3 выше). PPP является одним из предпочтительных методов кадровой синхронизации для IP, поскольку большое число систем взаимодействует с PPP. ATM имеет собственные методы кадровой синхронизации, описанные в [RFC2684] [RFC2364].
На высоких скоростях подсети следует предоставлять кадрированный интерфейс, способный переносить асинхронные IP-дейтаграммы переменной длины. Максимальный размер пакета, поддерживаемый этим интерфейсом, рассмотрен выше в разделе MTU/Fragmentation. Подсеть может реализовать эту возможность любым удобным способом.
Границы IP-пакетов не обязаны совпадать с какими-либо механизмами кадровой синхронизации или синхронизации, внутренними для подсети. Когда подсеть реализует единицы данных переменного размера, наиболее прямой подход состоит в помещении ровно одного IP-пакета в каждую единицу данных подсети (SNDU) и в использовании уже существующей способности подсети определять границы SNDU также для определения границ IP-пакетов. Хорошим примером является Ethernet. Однако некоторые подсети имеют SNDU одного или нескольких фиксированных размеров, определяемых соображениями коммутации, прямого исправления ошибок и/или чередования. Примеры таких подсетей включают ATM, с единственным размером полезной нагрузки ячейки в 48 октетов плюс 5-октетный заголовок, и цифровую сотовую связь IS-95, с двумя «наборами скоростей» по четыре фиксированных размера кадров в каждом, которые могут выбираться на границах 20 миллисекунд.
Поскольку IP-пакеты имеют переменную длину, они не обязательно могут поместиться в целое кратное число SNDU фиксированного размера. Для преобразования IP-пакетов в SNDU с одновременной отметкой границы между каждым IP-пакетом некоторым способом необходим «уровень адаптации».
Существует несколько подходов к этой проблеме. Первый заключается в кодировании каждого IP-пакета в одну или несколько SNDU, причём ни одна SNDU не содержит частей более чем одного IP-пакета, и дополнении последней SNDU пакета по мере необходимости. Биты в управляющем заголовке, добавляемом к каждой SNDU, указывают, какое место сегмент данных занимает в IP-пакете. Если подсеть предоставляет упорядоченную доставку не более одного раза, заголовок может быть таким простым, как пара битов, указывающих, является ли SNDU первой и/или последней в IP-пакете. В качестве альтернативы для подсетей, которые не изменяют порядок фрагментов SNDU, можно было бы помечать только последнюю SNDU пакета, поскольку это неявно
Karn и др. Лучшая современная практика [Страница 8]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
указывало бы следующую SNDU как первую в новом IP-пакете. Схема AAL5 (ATM Adaptation Layer 5), используемая с ATM, является примером этого подхода, хотя она добавляет и другие возможности, включая поле длины полезной нагрузки и CRC полезной нагрузки.
В AAL5 ATM User-User Indication, которая кодируется в поле Payload Type ячейки ATM, указывает последнюю ячейку пакета. Трейлер пакета расположен в конце SNDU и содержит длину пакета и CRC.
Другой метод кадровой синхронизации состоит во вставке накладных данных для каждого сегмента, указывающих наличие опции сегмента. Когда опция присутствует, она содержит указатель на конец пакета. Это отличается от AAL5 тем, что допускает следование другого пакета в пределах того же сегмента. MPEG-2 Transport Streams [EN301192] [ISO13818] поддерживают этот стиль фрагментации и могут либо использовать дополнение (ограничивая каждый пакет транспортного потока MPEG переносом только части одного IP-пакета), либо разрешать начало второго IP-пакета в том же пакете Transport Stream (без дополнения).
Третий подход заключается во вставке специальной последовательности флагов в поток данных между каждыми IP-пакетами и упаковке результирующего потока данных в SNDU безотносительно границ SNDU. Это может иметь последствия при утрате кадров. Последовательность флагов также может дополнять неиспользуемое пространство в конце SNDU. Если специальный флаг появляется в пользовательских данных, он экранируется альтернативной последовательностью (обычно длиннее флага), чтобы избежать ошибочного истолкования в качестве флага. Все схемы кадровой синхронизации на основе HDLC, используемые в PPP, являются примерами этого подхода.
Все три схемы адаптации добавляют накладные расходы; их величина зависит от распределения размеров IP-пакетов, размера (размеров) SNDU и, в подходах, подобных HDLC, от содержимого IP-пакета (поскольку последовательности, подобные флагам, возникающие в пакете, должны экранироваться, что увеличивает их размер). Разработчик также должен сопоставить сложность реализации и производительность при выборе и проектировании уровня адаптации.
4. Ориентированные на соединение подсети
IP не имеет понятия «соединение»; это чисто протокол без установления соединения. Когда соединение требуется приложению, оно обычно предоставляется TCP [RFC793], Transmission Control Protocol, работающим поверх IP на сквозной основе.
Ориентированные на соединение подсети могут использоваться (и широко используются) для переноса IP, но часто со значительной сложностью. Подсети, состоящие из небольшого числа узлов, могут просто открывать постоянное соединение между каждой парой узлов. Это часто делается с ATM. Однако число соединений увеличивается пропорционально квадрату числа узлов, поэтому это
Karn и др. Лучшая современная практика [Страница 9]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
явно непрактично для больших подсетей. Поэтому для управления соединениями необходим «промежуточный» уровень между IP и подсетью. Это одна из наиболее распространённых функций подуровня Subnetwork Dependent Convergence Function (SNDCF) между IP и подсетью.
SNDCF обычно открывают соединения подсети по необходимости, когда IP-пакет поставлен в очередь на передачу, и закрывают их по истечении тайм-аута бездействия. Между соединениями подсети и любыми соединениями, которые могут существовать на более высоких уровнях (например, TCP), нет связи.
Поскольку интернет-трафик обычно является импульсным и ориентированным на транзакции, часто трудно выбрать оптимальный тайм-аут бездействия. Если тайм-аут слишком короткий, соединения подсети быстро открываются и закрываются, возможно, чрезмерно нагружая систему управления соединениями подсети (особенно если она была разработана для времени удержания вызовов голосового трафика). Если тайм-аут слишком долгий, соединения подсети значительную часть времени бездействуют, растрачивая любые ресурсы, выделенные им подсетью.
Чисто подсети без установления соединения (такие как Ethernet), не имеющие состояния и динамически совместно использующие ресурсы, оптимальны для поддержки IP с негарантированной доставкой, который не имеет состояния и динамически совместно использует ресурсы. Ориентированные на соединение пакетные сети (такие как ATM и Frame Relay), которые имеют состояние и динамически совместно используют ресурсы, менее оптимальны, поскольку IP с негарантированной доставкой не получает выгоды от накладных расходов на создание и поддержание состояния. Ориентированные на соединение сети с коммутацией каналов (включая PSTN и ISDN) имеют состояние и статически выделяют ресурсы для вызова и поэтому требуют накладных расходов на создание и поддержание состояния, но не получают выгоды от эффективности статистического мультиплексирования совместного использования пропускной способности, присущей IP.
В любом случае, если для поддержки IP используется SNDCF, открывающая и закрывающая соединения подсети, следует позаботиться о том, чтобы обработка соединений в подсети могла справляться с относительно короткими временами удержания.
5. Широковещание и обнаружение
Подсети подразделяются на две категории: двухточечные и совместно используемые. Двухточечная подсеть имеет ровно два оконечных компонента (хоста или маршрутизатора); совместно используемый канал имеет более двух оконечных компонентов, используя либо среду, изначально поддерживающую широковещание (например, Ethernet, радио), либо уровень коммутации, скрытый от сетевого уровня (например, коммутируемый Ethernet, Myrinet [MYR95], ATM). Коммутируемые подсети обрабатывают широковещание путём копирования широковещательных пакетов, предоставляя каждому интерфейсу, поддерживающему одну или несколько систем (хостов или маршрутизаторов), копию каждого пакета.
Karn и др. Лучшая современная практика [Страница 10]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
Несколько интернет-протоколов для IPv4 используют возможности широковещания, включая поиск адресов канального уровня (ARP), автоматическую конфигурацию (RARP, BOOTP, DHCP) и маршрутизацию (RIP).Отсутствие возможности широковещательной передачи может ухудшать производительность этих протоколов или делать их неработоспособными (например, DHCP). Поиск адреса канального уровня, подобный ARP, может обеспечиваться централизованной базой данных, но ценой потенциально более высокой задержки ответа и необходимости для узлов явно знать адрес сервера ARP. Совместно используемые каналы следует оснащать поддержкой нативной широковещательной передачи в подсети на канальном уровне.
Соответствующий набор протоколов IPv6 использует многоадресную рассылку (см. следующий раздел) вместо широковещательной передачи для обеспечения сходных функций с улучшенной масштабируемостью в крупных сетях.
6. Многоадресная рассылка
Модель Интернета включает «многоадресную рассылку», при которой IP-пакеты отправляются всем участникам группы многоадресной рассылки [RFC1112] [RFC3376] [RFC2710]. Многоадресная рассылка является опцией в IPv4, но стандартной возможностью IPv6. В настоящее время многоадресная рассылка IPv4 используется приложениями для мультимедиа, телеконференций, игр и распространения файлов (web, совместный обмен между равноправными узлами), а также некоторыми ключевыми сетевыми протоколами и протоколами хостов (например, RIPv2, OSPF, NTP). IPv6 дополнительно полагается на многоадресную рассылку для конфигурирования сети (автоконфигурации, подобной DHCP) и обнаружения адресов канального уровня [RFC2461] (заменяя ARP). В случае IPv6 это может позволять автоконфигурации и обнаружению адресов распространяться через маршрутизаторы, тогда как службы IPv4 на основе широковещательной передачи не могут этого без специальной поддержки маршрутизатора [RFC1812].
IP-маршрутизаторы с поддержкой многоадресной рассылки организуют каждую группу многоадресной рассылки в остовное дерево и маршрутизируют многоадресные пакеты, создавая копии каждого многоадресного пакета и пересылая эти копии на каждый выходной интерфейс, включающий по меньшей мере одного расположенного ниже по потоку участника группы многоадресной рассылки.
Многоадресная рассылка значительно эффективнее, когда подсеть явно поддерживает её. Например, маршрутизатору, ретранслирующему многоадресный пакет в сегмент Ethernet, достаточно отправить только одну копию пакета независимо от того, сколько участников группы многоадресной рассылки подключено к сегменту. Без нативной поддержки многоадресной рассылки маршрутизаторам и коммутаторам на совместно используемых каналах потребовалось бы использовать широковещательную передачу с программными фильтрами, так что каждый отправленный многоадресный пакет создавал бы программные накладные расходы для каждого узла в подсети, даже если узел не является участником группы многоадресной рассылки. В качестве альтернативы маршрутизатор передавал бы отдельную копию каждому участнику группы многоадресной рассылки в сегменте, как это делается в коммутируемых подсетях без возможности многоадресной рассылки.
Karn, et al. Best Current Practice [Page 11]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Подсети, использующие совместно используемые каналы (например, радио-LAN, Ethernet), особенно подходят для нативной многоадресной рассылки, и их проектировщикам следует прилагать все усилия для её поддержки. Это предполагает выделение участка собственного адресного пространства подсети для многоадресной рассылки. В таких сетях многоадресная рассылка в основном представляет собой широковещательную передачу в среде передачи с фильтрами получателей уровня 2.
Интерфейсы подсети также необходимо проектировать так, чтобы они принимали пакеты, адресованные некоторому числу многоадресных адресов, в дополнение к одноадресным пакетам, адресованным непосредственно им. Число многоадресных адресов, которое должен поддерживать хост, зависит от требований соответствующего хоста; по меньшей мере несколько десятков удовлетворят большинству текущих потребностей.
В низкоскоростных сетях функцию распознавания многоадресных адресов можно без труда реализовать в программном обеспечении хоста, но в высокоскоростных сетях её следует реализовать в аппаратном обеспечении подсети. Это аппаратное обеспечение не обязательно должно быть полным; например, многие интерфейсы Ethernet реализуют функцию «хеширования», при которой IP-уровень получает весь трафик многоадресной (и одноадресной) рассылки, на который подписан соответствующий хост, плюс некоторую малую долю трафика многоадресной рассылки, на который хост не подписан. Затем программное обеспечение хоста/маршрутизатора должно отбрасывать нежелательные пакеты, прошедшие фильтр многоадресных адресов уровня 2 [RFC1112].
Нет необходимости в однозначном соответствии между многоадресным адресом уровня 2 и IP-адресом многоадресной рассылки. Перекрытие адресов может значительно ухудшить способность аппаратного фильтра многоадресных адресов получателя к фильтрации. Подсети, поддерживающей только широковещательную передачу, следует использовать эту службу для многоадресной рассылки и должна полагаться на программную фильтрацию.
Коммутируемые подсети также должны предоставлять механизм копирования многоадресных пакетов, обеспечивающий, что пакеты достигают по меньшей мере всех участников группы многоадресной рассылки. Один из вариантов — «затопление» многоадресных пакетов тем же способом, что и широковещательных. Это может приводить к ненужным передачам по некоторым каналам подсети (в частности, на коммутаторах Ethernet, не учитывающих многоадресную рассылку). Поэтому некоторые подсети позволяют таблицам фильтров многоадресной рассылки управлять тем, какие каналы получают пакеты, принадлежащие определённой группе. Для автоматической настройки этого требуется доступ к информации об участии в группах уровня 3 (например, IGMP [RFC3376] или MLD [RFC2710]). В настоящее время существуют различные варианты реализации для предоставления узлу подсети списка отображений многоадресных адресов на порты/интерфейсы. В них применяется ряд подходов, включая сигнализацию от конечных хостов (например, IEEE 802 GARP/GMRP [802.1p]), сигнализацию от коммутаторов (например, CGMP [CGMP] и RGMP [RFC3488]), перехват и проксирование IP-пакетов об участии в группах (например, прокси IGMP/MLD [MAGMA-PROXY]), а также предоставление устройствам уровня 2 возможности отслеживать/инспектировать/заглядывать в заголовки пересылаемых протоколов уровня 3 (например,
Karn, et al. Best Current Practice [Page 12]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
IGMP, MLD, PIM), чтобы они могли выводить участие в группах многоадресной рассылки уровня 3 [MAGMA-SNOOP]. Эти подходы различаются по сложности, гибкости и способности поддерживать новые протоколы.
7. Подсети с предоставлением полосы пропускания по запросу (BoD)
Некоторые подсети позволяют нескольким узлам подсети эффективно совместно использовать канал, динамически назначая возможности передачи. Возможности передачи запрашиваются узлом подсети, когда у него есть пакеты для отправки. Подсеть планирует и предоставляет возможности передачи, достаточные для того, чтобы передающий узел подсети мог отправить один или несколько пакетов (либо фрагментов пакетов). Мы называем такие подсети подсетями с предоставлением полосы пропускания по запросу (Bandwidth on Demand, BoD). Примеры подсетей BoD включают спутниковые и наземные беспроводные сети Demand Assignment Multiple Access (DAMA), режим функции координации точек (PCF) IEEE 802.11 и DOCSIS. Сеть с установлением соединения (такая как PSTN, ATM или Frame Relay) резервирует ресурсы в значительно большем временном масштабе и поэтому не является подсетью BoD в нашей таксономии.
Параметры проектирования для BoD сходны с параметрами в подсетях с установлением соединения, хотя реализации могут значительно различаться. В BoD пользователь обычно запрашивает доступ к совместно используемому каналу на некоторую продолжительность. Доступ может быть выделен на период времени с определённой скоростью, для определённого числа пакетов или до тех пор, пока пользователь не освободит канал. Доступ может координироваться через центральный управляющий объект или распределённым алгоритмом между пользователями. Примеры ресурса, который может совместно использоваться, включают наземный беспроводной переход, восходящий канал в системе кабельного телевидения, спутниковый канал «земля—спутник» и сквозной спутниковый канал.
Подсети BoD с большой задержкой создают проблемы, сходные с подсетями с установлением соединения, при прогнозировании трафика. В то время как подсети с установлением соединения держат незанятые каналы открытыми в ожидании поступления новых данных, подсети BoD запрашивают доступ к каналу на основе заполненности буфера (или ожидаемой заполненности буфера) на отправляющем порту. Вероятно, будет получена низкая производительность, если отправитель не предвидит дополнительный трафик, поступающий на этот порт за время, необходимое для предоставления запроса на передачу. Рекомендуется, чтобы алгоритм имел возможность продлевать удержание канала для данных, поступивших после формирования исходного запроса (это может быть сделано путём включения новых запросов в пользовательские данные).
Доступно большое разнообразие протоколов BoD. Однако было проведено сравнительно мало всесторонних исследований взаимодействий между механизмами BoD и производительностью протоколов Интернета. Имеются исследования некоторых конкретных механизмов (например, [AR02]). Одним из изученных вопросов является таймер повторной передачи TCP [KY02]. BoD
Karn, et al. Best Current Practice [Page 13]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
системы могут вызывать ложные тайм-ауты при переходе с относительно высокой скорости передачи данных на относительно низкую скорость передачи данных. В этом случае переданным TCP данным требуется больше времени для прохождения через сеть, чем предсказано вычисленным отправителем TCP тайм-аутом повторной передачи. Поэтому отправитель TCP склонен преждевременно повторно отправлять сегмент.
8. Надёжность и контроль ошибок
В архитектуре Интернета окончательная ответственность за восстановление после ошибок лежит на конечных точках [SRC81]. Интернет может иногда отбрасывать, повреждать, дублировать или изменять порядок пакетов, и транспортный протокол (например, TCP) или приложение (например, если UDP используется в качестве транспортного протокола) должны восстанавливаться после этих ошибок сквозным образом [RFC3155]. Поэтому восстановление после ошибок в подсети оправдано лишь в той мере, в какой оно может улучшить общую производительность. Важно понимать, что подсеть может зайти слишком далеко в стремлении предоставлять службы восстановления после ошибок в среде Интернета. Надёжности подсети следует быть «лёгкой», то есть ей достаточно быть «достаточно хорошей», *а не* совершенной.
В этом разделе мы обсуждаем, как анализировать характеристики подсети, чтобы определить, что является «достаточно хорошим». Приведённое ниже обсуждение сосредоточено на TCP, который является наиболее широко используемым транспортным протоколом в Интернете. Широко распространено мнение (и это заявленная цель IETF), что транспортным протоколам, отличным от TCP, следует стремиться быть «дружественными к TCP» и иметь многие из тех же характеристик производительности. Таким образом, приведённое ниже обсуждение должно быть применимо даже к частям Интернета, где TCP может не быть преобладающим протоколом.
8.1. TCP в сравнении с повторной передачей на канальном уровне
Восстановление после ошибок включает создание и передачу избыточной информации, вычисленной на основе пользовательских данных. В зависимости от того, какой объём избыточной информации отправляется и как он формируется, получатель может использовать её для надёжного обнаружения ошибок передачи, исправления до некоторого максимального числа ошибок передачи либо для того и другого. Общий подход известен как кодирование для контроля ошибок, или ECC.
Использование ECC для обнаружения ошибок передачи, чтобы можно было запрашивать повторные передачи (будем надеяться, без ошибок), широко известно как «ARQ» (Automatic Repeat Request).
Когда доступно достаточно информации ECC, позволяющей получателю исправлять некоторые ошибки передачи без повторной передачи, этот подход известен как прямое исправление ошибок (Forward Error Correction, FEC). Из-за большей сложности требуемого ECC и необходимости адаптировать его проектирование к характеристикам конкретного модема и канала FEC
Karn, et al. Best Current Practice [Page 14]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
традиционно реализовывался в специализированном аппаратном обеспечении, являющемся неотъемлемой частью модема. Фактически это делает его частью физического уровня.
В отличие от ARQ, FEC до 1990-х годов редко использовался для телекоммуникаций вне космических каналов. Сейчас он почти повсеместно применяется в телефонных, кабельных и DSL-модемах, цифровых спутниковых каналах и цифровых мобильных телефонах. FEC также широко используется в оптических и магнитных носителях данных, где «повторные передачи» невозможны.
Некоторые системы используют гибридные комбинации ARQ, расположенного поверх FEC; один из примеров — модемы коммутируемого доступа V.90 (в восходящем направлении) с контролем ошибок V.42. Большинство ошибок исправляются кодом с решётчатой структурой (FEC) внутри модема V.90, а большинство оставшихся ошибок обнаруживаются и исправляются механизмами ARQ в V.42.
В настоящее время ведётся работа по применению FEC выше физического уровня, главным образом в связи с надёжной многоадресной рассылкой [RFC3048] [RFC3450-RFC3453], где традиционные механизмы ARQ неэффективны или трудны в реализации. Однако в этом обсуждении мы будем предполагать, что при наличии FEC он реализован на физическом уровне.
В зависимости от уровня, на котором он реализован, контроль ошибок может работать сквозным образом или на более коротком участке, таком как отдельный канал. TCP является важнейшим примером сквозного протокола, использующего стратегию ARQ.
Многие протоколы канального уровня используют ARQ, обычно некоторый вариант HDLC [ISO3309]. Примеры включают канальный уровень X.25, протокол AX.25, используемый в любительской пакетной радиосвязи, беспроводные LAN 802.11 и надёжный канальный уровень, определённый в IEEE 802.2.
Только сквозное восстановление после ошибок может обеспечить надёжную службу для приложения (см. раздел 8). Однако некоторые подсети (например, многие беспроводные каналы) также имеют восстановление после ошибок на канальном уровне как средство повышения производительности [RFC3366]. Например, многие сотовые каналы имеют малые размеры физических кадров (< 100 байт) и относительно высокую частоту потери кадров. Опора исключительно на сквозное восстановление после ошибок явно может приводить к ухудшению производительности, поскольку повторные передачи по сквозному пути принимаются значительно дольше, чем при использовании повторных передач канального уровня. Таким образом, восстановление после ошибок на канальном уровне часто может повысить сквозную производительность. В результате восстановление на канальном и сквозном уровнях часто сосуществуют; это может приводить к возможности неэффективных взаимодействий между протоколами ARQ двух уровней. Эта межуровневая «конкуренция» может приводить к следующей
расточительной ситуации. Когда канальный уровень повторно передаёт
(части) пакета, задержка канала на некоторое время увеличивается.
Поскольку TCP основывает свой
Karn и др. Лучшая современная практика [Страница 15]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
тайм-аут повторной передачи на предыдущих измерениях суммарной
сквозной задержки, включая задержку рассматриваемого канала, это
внезапное увеличение задержки может вызвать ненужную повторную
передачу TCP пакета, который канальный уровень всё ещё повторно
передаёт. Такие ложные сквозные повторные передачи создают ненужную
нагрузку и уменьшают сквозную пропускную способность. В результате
канальный уровень может даже одновременно иметь несколько копий
одного и того же пакета в одной очереди канала. В общем случае можно
сказать, что конкурирующее восстановление после ошибок вызвано
внутренним контуром управления (восстановлением после ошибок
канального уровня), реагирующим на тот же сигнал, что и внешний
контур управления (сквозным восстановлением после ошибок), без какой-
либо координации между контурами. Обратите внимание, что это касается
исключительно эффективности; TCP продолжает обеспечивать надёжную
сквозную доставку по таким каналам.
В связи с этим возникает вопрос, насколько настойчивым следует быть
отправителю канального уровня при выполнении повторной передачи
[RFC3366]. Мы определяем настойчивость ARQ канального уровня (LL) как
максимальное время, в течение которого конкретный канал будет
пытаться передать пакет, прежде чем его можно будет отбросить. Это
намеренно упрощённое определение ничего не говорит о максимальном
числе повторных передач, стратегиях повторной передачи, размерах
очередей, дисциплинах обслуживания очередей, задержках передачи и
тому подобном. Причина, по которой мы используем термин
«настойчивость LL ARQ» вместо термина наподобие «максимальное время
удержания пакета на канальном уровне», состоит в том, что определение
тесно связано с восстановлением после ошибок канального уровня.
Например, на каналах, реализующих прямолинейные стратегии
восстановления после ошибок, настойчивость LL ARQ часто будет
соответствовать максимальному числу повторных передач, разрешённых
для каждого кадра канального уровня.
Для канальных уровней, которые не различают или не могут различать
потоки (например, из-за шифрования сетевого уровня), настойчивость
LL ARQ следует делать небольшой. Это позволяет избежать каких-либо
вредных воздействий или ухудшения производительности вследствие
неизбирательно высокой настойчивости. Подробное обсуждение этих
вопросов приведено в [RFC3366].
Однако, когда канальный уровень может идентифицировать отдельные
потоки и применять ARQ избирательно [LKJK02], настойчивость ARQ
канала следует делать высокой для потока, использующего надёжные
одноадресные транспортные протоколы (например, TCP), и она должна
быть низкой для всех остальных потоков. Установка настойчивости ARQ
канала выше, чем наибольшая недоступность канала, позволяет TCP
быстро восстановить передачу, не дожидаясь истечения тайм-аута
повторной передачи. В целом это улучшает производительность TCP при
временных недоступностях. Однако чрезмерно высокая настойчивость
может быть невыгодна; может быть желателен практический верхний
предел в 30-60 секунд. Реализация таких схем остаётся предметом
исследований. (См. также следующий раздел «Восстановление после
недоступности подсети».)
Karn и др. Лучшая современная практика [Страница 16]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
У многих разработчиков подсетей есть возможности снизить вероятность
потери пакетов, например с помощью FEC, ARQ и перемежения, ценой
увеличения задержки. Производительность TCP улучшается при снижении
потерь, но ухудшается при увеличении сквозной задержки, поэтому важно
найти надлежащий баланс посредством анализа и моделирования.
8.2. Восстановление после недоступности подсети
Некоторые типы подсетей, особенно мобильные радиосети, подвержены
частым временным недоступностям. Например, активный пользователь
сотовой передачи данных может въехать или войти в область (такую как
туннель), находящуюся вне зоны действия любой базовой станции. Ни
один пакет не будет успешно доставлен, пока пользователь не вернётся
в область с покрытием.
В настоящее время протоколы Интернета не предоставляют стандартного
способа для подсети явно уведомить протокол верхнего уровня (например,
TCP), что она испытывает недоступность, а не серьёзную перегрузку.
В этих обстоятельствах TCP после каждой неуспешной повторной
передачи будет ждать ещё дольше, прежде чем попытаться снова; таков
его алгоритм «экспоненциальной отсрочки». Кроме того, TCP не обнаружит,
что недоступность подсети закончилась, до своей следующей попытки
повторной передачи. Если TCP увеличил отсрочку, это может занять
некоторое время. Это может привести к крайне низкой производительности
TCP в таких подсетях.
Поэтому весьма желательно, чтобы подверженная недоступностям подсеть
не отбрасывала пакеты молча во время недоступности. В идеале подсети
следует определить интерфейс со следующим более высоким уровнем (то
есть IP), позволяющий ей отклонять пакеты во время недоступности
и автоматически запрашивать у IP новые пакеты, когда она снова сможет
их доставлять. Если она не может этого сделать, то подсети следует
удерживать по меньшей мере некоторые из пакетов, которые она принимает
во время недоступности, и пытаться доставить их, когда недоступность
закончится. Когда пакеты отбрасываются, IP следует уведомлять, чтобы
могли быть отправлены соответствующие сообщения ICMP.
Обратите внимание, что *не* обязательно полностью избегать отбрасывания
пакетов во время недоступности. Цель удержания пакета во время
недоступности — либо в подсети, либо на уровне IP — состоит в том,
чтобы его последующая доставка неявно уведомила TCP, что подсеть снова
работоспособна. Это предназначено для повышения производительности,
а не для обеспечения надёжности — надёжность, как обсуждалось ранее,
может быть обеспечена только на сквозной основе.
Достаточно удерживать таким образом лишь несколько пакетов на
соединение TCP, включая ACK, чтобы после возобновления потока
отправитель TCP восстановился от дополнительных потерь [RFC3366].
Karn и др. Лучшая современная практика [Страница 17]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
Поскольку для IP или уровня подсети просмотр заголовков TCP был бы
нарушением уровневой архитектуры (и, возможно, снижением
производительности) — и в любом случае был бы невозможен при
использовании шифрования IPsec [RFC2401] — IP или уровни подсети могли
бы разумно выбирать в качестве параметра проектирования некоторое
небольшое число пакетов, которые будут сохраняться во время
недоступности.
8.3. CRC, контрольные суммы и обнаружение ошибок
Протоколы TCP [RFC793], UDP [RFC768], ICMP и IPv4 [RFC791] все
используют один и тот же простой 16-битный алгоритм контрольной суммы
с дополнением до единицы [RFC1071] для обнаружения повреждённых
пакетов. Контрольная сумма заголовка IPv4 защищает только заголовок
IPv4, тогда как контрольные суммы TCP, ICMP и UDP обеспечивают
сквозное обнаружение ошибок как для псевдозаголовка транспорта
(включая информацию сетевого и транспортного уровней), так и для
данных полезной нагрузки транспорта. Защита данных необязательна для
приложений, использующих UDP [RFC768] для IPv4, но обязательна для
IPv6.
Контрольная сумма Интернета не очень сильна с точки зрения теории
кодирования, но её легко вычислять программно, и различные предложения
заменить контрольные суммы Интернета более сильными контрольными
суммами потерпели неудачу. Однако известно, что необнаруженные ошибки
могут возникать и действительно возникают в пакетах, полученных
конечными хостами [SP2000].
Для снижения затрат на обработку IPv6 не имеет контрольной суммы
заголовка IP. Конечный хост обнаруживает «важные» ошибки в заголовке
IP, такие как доставка пакета не тому получателю. Это делается путём
включения IP-адресов источника и назначения (псевдозаголовка) в
вычисление контрольной суммы в заголовке TCP или UDP — практика,
уже выполняемая в IPv4. Ошибки в других полях заголовка IPv6 могут
остаться необнаруженными в сети; это считалось разумной ценой за
значительное сокращение обработки, требуемой каждым маршрутизатором,
и предполагалось, что подсети будут использовать надёжный канальный
CRC.
Один из способов обеспечить дополнительную защиту заголовка IPv4 или
IPv6 — использовать службы аутентификации и целостности пакетов
протокола IP Security (IPsec) [RFC2401]. Однако для разработчика
подсети это может быть недоступным вариантом.
Большинство подсетей реализуют обнаружение ошибок непосредственно над
физическим уровнем. Пакеты, повреждённые при передаче, обнаруживаются
и отбрасываются до доставки на уровень IP. 16-битная циклическая
проверка избыточности (CRC) обычно является минимумом для обнаружения
ошибок. Она существенно более устойчива к большинству шаблонов ошибок,
чем 16-битная контрольная сумма Интернета. Обратите внимание, что
свойства обнаружения ошибок конкретного кода CRC ухудшаются с
увеличением размера кадра. Point-to-Point Protocol [RFC1662] требует
поддержки 16-битного CRC
Karn и др. Лучшая современная практика [Страница 18]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
для каждого кадра канала, с 32-битным CRC в качестве варианта. (PPP
часто используется совместно с модемом коммутируемого доступа, который
обеспечивает собственное управление ошибками.) Другие подсети, включая
802.3/Ethernet, AAL5/ATM, FDDI, Token Ring и PPP поверх SONET/SDH, все
используют 32-битный CRC. Многие подсети также могут использовать
другие механизмы для усиления способности канального CRC обнаруживать
ошибки (например, FEC в модемах коммутируемого доступа, каналах
мобильной радиосвязи и спутниковых каналах).
Поэтому любой новой подсети, предназначенной для переноса IP, следует
обеспечивать обнаружение ошибок для каждого IP-пакета, по меньшей мере
столь же сильное, как 32-битный CRC, указанный в [ISO3309]. Хотя это
позволит достичь очень низкой частоты необнаруженных ошибок пакетов,
вызванных ошибками передачи, оно не позволит (и не обязано позволить)
достичь очень низкой частоты потерь пакетов, поскольку протоколы
Интернета лучше приспособлены для обработки потерянных пакетов, чем
повреждённых пакетов [SRC81].
Повреждение пакетов также может быть и действительно вызывается
ошибками в аппаратном и программном обеспечении хостов и
маршрутизаторов. Даже если бы каждая подсеть реализовала надёжное
обнаружение ошибок, всё равно существенно необходимо, чтобы на
принимающем конечном хосте использовались сквозные контрольные суммы
[SP2000].
Разработчикам сложных подсетей, состоящих из внутренних каналов и
коммутаторов пакетов, следует рассмотреть реализацию обнаружения
ошибок от границы до границы, охватывающего весь SNDU (или IP-пакет).
CRC генерировался бы в точке входа в подсеть и проверялся в конечной
точке выхода. Это может использоваться вместо обнаружения ошибок на
интерфейсе к каждому физическому каналу или в сочетании с ним.
Проверка от границы до границы имеет существенное преимущество:
защищает от ошибок, внесённых в любом месте внутри подсети, а не
только в её каналах передачи. Примеры этого подхода включают способ,
которым CRC-32 Ethernet обрабатывается мостами LAN [802.1D]. ATM AAL5
[ITU-I363] также использует CRC-32 от границы до границы.
Некоторые конкретные приложения могут быть терпимы к остаточным
ошибкам в данных, которыми они обмениваются, но удаление канального
CRC может подвергнуть сеть нежелательному увеличению необнаруженных
ошибок в заголовках IP и транспорта. Приложениям также может требоваться
высокий уровень защиты от ошибок для управляющей информации, которой
обмениваются протоколы, действующие выше транспортного уровня. Один
пример — голосовой кодек, устойчивый к битовым ошибкам в образцах речи.
Чтобы такие механизмы работали, принимающее приложение должно быть
способно переносить получение повреждённых данных. Это также требует,
чтобы приложение использовало механизм для сигнализации о допустимости
повреждения полезной нагрузки и для указания охвата (заголовков и
данных), который должен быть защищён CRC подсети. Протокол UDP-Lite
[RFC3828] является первым транспортным протоколом Интернета на пути
стандартизации, поддерживающим частичную защиту полезной нагрузки.
Получение повреждённых данных произвольными
Karn и др. Лучшая современная практика [Страница 19]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
протоколами приложений несёт серьёзную опасность того, что подсеть
доставит данные с ошибками, которые останутся необнаруженными
приложением и вследствие этого повредят передаваемые данные [SRC81].
8.4. Как работает TCP
Одна из функций TCP — управление перегрузкой Интернета на основе
конечных хостов. Это критически важная часть общей стабильности
Интернета, поэтому важно, чтобы разработчики канального уровня
понимали алгоритмы управления перегрузкой TCP.
TCP предполагает, что на наиболее абстрактном уровне сеть состоит из
каналов и очередей. Очереди обеспечивают выходную буферизацию на
каналах, которые временно перегружены. Они сглаживают мгновенные
всплески трафика, чтобы он соответствовал пропускной способности
канала. Когда спрос превышает ёмкость канала достаточно долго, чтобы
заполнить очередь, пакеты необходимо отбрасывать. Традиционное действие
отбрасывания самого последнего пакета («отбрасывание хвоста») более не
рекомендуется [RFC2309] [RFC2914], но всё ещё широко практикуется.
TCP использует нумерацию последовательностей и подтверждения (ACK) на
сквозной основе, чтобы обеспечивать надёжную упорядоченную доставку.
Подтверждения TCP являются накопительными, то есть каждое неявно
подтверждает каждый сегмент, полученный к этому моменту. Если получен
пакет с неожиданным номером последовательности, поле ACK в пакетах,
возвращаемых получателем, перестанет увеличиваться. Используя
необязательное усовершенствование, TCP может отправлять выборочные
подтверждения (SACK) [RFC2018], чтобы указать, какие сегменты прибыли
к получателю. Поскольку наиболее распространённой причиной потери пакетов является
перегрузка, TCP рассматривает потерю пакета как признак потенциальной
перегрузки Интернета на пути между конечными узлами TCP. Это происходит
автоматически, и подсети не требуется ничего знать об IP или TCP. Узел
подсети просто отбрасывает пакеты всякий раз, когда вынужден это делать,
хотя некоторые стратегии отбрасывания пакетов (например, RED) более
справедливы по отношению к конкурирующим потокам, чем другие.
TCP восстанавливается после потерь пакетов двумя различными способами.
Наиболее важный механизм — тайм-аут повторной передачи. Если ACK не
поступает по прошествии некоторого периода времени, TCP повторно передаёт
самый старый неподтверждённый пакет. Воспринимая это как указание на то,
что сеть перегружена, TCP ожидает подтверждения повторной передачи, прежде
чем продолжить, и постепенно увеличивает число пакетов в полёте, пока
тайм-аут не произойдёт снова.
Тайм-аут повторной передачи может налагать существенный штраф на
производительность, поскольку отправитель бездействует в течение интервала
тайм-аута и после тайм-аута начинает заново с окном перегрузки в один
сегмент TCP.
Karn, et al. Best Current Practice [Page 20]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Чтобы обеспечить более быстрое восстановление после случайной потери
пакета при передаче большого объёма данных, была введена альтернативная
схема, известная как «быстрое восстановление» ("fast recovery") [RFC2581]
[RFC2582] [RFC2914] [TCPF98].
Быстрое восстановление опирается на тот факт, что при потере одного
пакета при передаче большого объёма данных получатель продолжает возвращать
для последующих пакетов данных ACK, которые фактически не подтверждают
никаких вновь полученных данных. Они известны как «дублирующие
подтверждения» ("duplicate acknowledgments") или «dupacks». Отправляющий
TCP может использовать dupacks как указание на потерю пакета и повторно
передать его, не дожидаясь тайм-аута. Dupacks фактически образуют
отрицательное подтверждение (NAK) для номера последовательности пакета в
поле подтверждения. TCP ожидает, пока не будет получено определённое число
dupacks (в настоящее время 3), прежде чем предположить, что произошла
потеря; это помогает избежать ненужной повторной передачи при доставке не
по порядку.
Метод, называемый «явным уведомлением о перегрузке» (Explicit Congestion
Notification, ECN) [RFC3168], позволяет маршрутизаторам непосредственно
сигнализировать узлам о перегрузке без отбрасывания пакетов. Это делается
установкой бита в заголовке IP. Поскольку поддержка ECN, вероятно, останется
необязательной, отсутствие бита ECN *никогда* не должно интерпретироваться
как отсутствие перегрузки. Поэтому в обозримом будущем TCP должен
интерпретировать потерянный пакет как сигнал перегрузки.
Алгоритм TCP «предотвращения перегрузки» ("congestion avoidance")
[RFC2581] поддерживает окно перегрузки (cwnd), управляющее объёмом данных,
который TCP может иметь в полёте в любой момент. Уменьшение cwnd уменьшает
общую полосу пропускания, получаемую соединением; аналогично, увеличение
cwnd повышает производительность вплоть до предела доступной ёмкости.
TCP исследует доступную ёмкость сети, первоначально устанавливая cwnd в
один или два пакета, а затем увеличивая cwnd на один пакет для каждого ACK,
возвращённого получателем. Это механизм TCP «медленного старта» ("slow
start"). Когда обнаруживается потеря пакета (или о перегрузке сигнализируют
другие механизмы), cwnd сбрасывается до единицы, и процесс медленного старта
повторяется, пока cwnd не достигнет половины своего предыдущего значения до
сброса. Cwnd продолжает увеличиваться после этой точки, но с гораздо меньшей
скоростью, чем прежде. Если дальнейших потерь не происходит, cwnd в
конечном итоге достигнет размера окна, объявленного получателем.
Это алгоритм «аддитивное увеличение, мультипликативное уменьшение»
(Additive Increase, Multiplicative Decrease, AIMD). Резкое уменьшение cwnd
в ответ на перегрузку обеспечивает стабильность сети; алгоритм AIMD также
обеспечивает справедливость между длительно работающими TCP-соединениями,
использующими один и тот же путь.
Karn, et al. Best Current Practice [Page 21]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
8.5. Характеристики производительности TCP
Предостережение
Здесь мы представляем современное понимание производительности TCP,
соответствующее «современному уровню техники». Этот анализ пытается
охарактеризовать производительность TCP-соединений на линиях связи с
различными характеристиками.
Разработчики линий связи могут пожелать использовать методы из этого
раздела для прогнозирования производительности, которой TCP/IP может
достичь при новом проекте канального уровня. Такой анализ приветствуется.
Поскольку это относительно новый анализ, а теория основана на
однопоточных TCP-соединениях в «идеальных» условиях, следует признать,
что результаты такого анализа могут отличаться от фактической
производительности в Интернете. Сказав это, мы сделали всё возможное,
чтобы предоставить разработчикам полезную информацию для получения точного
представления о возможностях и ограничениях TCP в различных условиях.
8.5.1. Формулы
Производительность алгоритма предотвращения перегрузки TCP AIMD была
широко проанализирована. Текущая наилучшая формула для производительности
конкретных алгоритмов, используемых Reno TCP (то есть TCP, определённого в
[RFC2581]), приведена Padhye и др. [PFTK98]. Эта формула имеет вид:
MSS
BW = --------------------------------------------------------
RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
где
BW — максимальный TCP throughout, достижимый отдельным
TCP-потоком
MSS — размер сегмента TCP, используемый соединением
RTT — время кругового обхода TCP-соединения от конца до конца
RTO — тайм-аут пакета (основанный на RTT)
p — доля потерь пакетов на пути
(то есть .01 при 1% потерь пакетов)
Следует отметить, что скорость линий связи, составляющих путь в Интернете,
явно не фигурирует в этой формуле. Попытка передавать быстрее самой
медленной линии на пути вызывает рост очереди у передатчика, обслуживающего
узкое место. Это увеличивает RTT, что, в свою очередь, уменьшает
достижимую пропускную способность.
В настоящее время это считается наилучшей приближённой формулой для
производительности Reno TCP. Обычно далее эту формулу упрощают, предполагая,
что RTO приблизительно равно 5*RTT.
Karn, et al. Best Current Practice [Page 22]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
TCP постоянно совершенствуется. Более простая формула, задающая верхнюю
границу производительности любого алгоритма AIMD, который, вероятно, будет
реализован в TCP в будущем, была выведена Ott и др. [MSMO97].
MSS 1
BW = C --- -------
RTT sqrt(p)
где C равно 0.93.
8.5.2. Допущения
Обе формулы предполагают, что окно приёма TCP не ограничивает
производительность соединения. Поскольку окно приёма полностью определяется
конечными узлами, мы предполагаем, что узлы будут максимизировать
объявляемое окно приёма для максимизации производительности своей сети.
Обе эти формулы допускают, что BW становится бесконечным, если потерь нет.
Однако путь в Интернете будет отбрасывать пакеты в очередях в узких местах,
если нагрузка слишком высока. Поэтому полностью свободная от потерь сеть
TCP/IP никогда не может существовать (если только сеть не используется
недостаточно).
Используемое RTT является средним арифметическим, включая задержки в
очередях.
Формулы предназначены для одного TCP-соединения. Если путь переносит много
TCP-соединений, каждое из них будет независимо следовать приведённым выше
формулам.
Формулы предполагают длительно работающие TCP-соединения. Для соединений,
которые чрезвычайно коротки (<10 пакетов) и не теряют ни одного пакета,
производительность определяется алгоритмом медленного старта TCP. Для
соединений средней длины, в которых в среднем теряются лишь несколько
сегментов, производительность одного соединения фактически будет немного
лучше, чем заданная приведёнными выше формулами.
Различие между приведёнными выше простой и сложной формулами состоит в том,
что сложная формула учитывает эффекты тайм-аутов повторной передачи TCP.
При очень низких уровнях потерь пакетов (значительно менее 1%) тайм-ауты
вряд ли произойдут, и формулы дают очень похожие результаты. При более
высоких потерях пакетов (1% и выше) сложная формула даёт более точную оценку
производительности (которая всегда будет значительно ниже результата простой
формулы).
Следует отметить, что эти формулы перестают работать по мере приближения p
к 100%.
Karn, et al. Best Current Practice [Page 23]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
8.5.3. Анализ влияния канального уровня на производительность TCP
Рассмотрим следующий пример:
Разработчик изобретает новый беспроводной канальный уровень, который в
среднем теряет 1% IP-пакетов. Канальный уровень поддерживает пакеты до
1040 байтов и имеет одностороннюю задержку 20 мс.
Если бы эта линия использовалась на пути в Интернете со временем кругового
обхода более 80 мс, верхняя граница могла бы быть вычислена следующим
образом:
Для MSS используйте 1000 байтов, чтобы исключить 40 байтов минимальных
заголовков IPv4 и TCP.
Для RTT используйте 120 мс (80 мс для части Интернета плюс по 20 мс в
каждом направлении для новой беспроводной линии).
Для p используйте .01. Для C предположите 1.
Простая формула даёт:
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
Более сложная формула даёт:
BW = 402.9 kbit/sec
Если бы это была беспроводная LAN 2 Мбит/с, разработчики могли бы быть
несколько разочарованы.
Некоторые наблюдения о производительности:
1. Мы предположили, что потери пакетов на канальном уровне
интерпретируются TCP как перегрузка. Это «факт жизни», который
необходимо принять.
2. Все уравнения производительности TCP выражены через потери пакетов,
но многие разработчики подсетей мыслят в терминах коэффициента битовых
ошибок. *Если* битовые ошибки канала независимы, то вероятность
повреждения пакета равна:
p = 1 - ([1 - BER]^[FRAME_SIZE*8])
Здесь предполагается, что FRAME_SIZE выражен в байтах, а "^" обозначает
возведение в степень. Он включает пользовательские данные и все
заголовки (TCP,IP и подсети). (Примечание: этот анализ предполагает, что
Karn, et al. Best Current Practice [Page 24]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
подсеть не выполняет ARQ или прозрачную фрагментацию [RFC3366].) Если
неравенство
BER * [FRAME_SIZE*8] << 1
выполняется, вероятность потери пакета p можно аппроксимировать как:
p = BER * [FRAME_SIZE*8]
Эти уравнения можно использовать для применения BER к приведённым выше
уравнениям производительности.
Следует отметить, что FRAME_SIZE может меняться от одного пакета к
следующему. Малые пакеты (такие как TCP acks), как правило, имеют
меньшую вероятность ошибки пакета, чем, например, TCP-пакет, несущий
один MSS (максимальный размер сегмента) пользовательских данных. Можно
ожидать, что поток малых TCP acks будет немного надёжнее потока более
крупных сегментов данных TCP.
Стоит повторить, что приведённый выше анализ предполагает статистическую
независимость битовых ошибок. Поскольку это неверно для многих реальных
линий связи, наше вычисление p фактически является верхней границей, а
не точной вероятностью потери пакета.
Существует много причин, почему битовые ошибки на реальных линиях не
независимы. На многие радиолинии влияют замирания распространения или
помехи, сохраняющиеся в течение многих битовых интервалов. Кроме того,
линии с прямым исправлением ошибок (Forward Error Correction, FEC), как
правило, имеют очень неоднородные распределения битовых ошибок, которые
зависят от типа FEC, но в целом неисправленные ошибки обычно возникают
пачками, даже когда ошибки символов канала независимы. Во всех таких
случаях наше вычисление p по BER может устанавливать лишь верхний предел
для доли потерь пакетов.
Если распределение ошибок при схеме FEC известно, можно было бы
применить тот же тип анализа, что и выше, используя правильную функцию
распределения для BER. Однако в этих случаях с FEC более вероятно, что
для определения фактической доли потерь пакетов потребуются эмпирические
методы.
3. Следует отметить, что размер пакета играет важную роль. Если
характеристики потерь подсети таковы, что большие пакеты имеют ту же
вероятность потери, что и меньшие пакеты, то большие пакеты обеспечат
улучшенную производительность.
Karn, et al. Best Current Practice [Page 25]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
4. Мы выбрали конкретное RTT, которое могло бы встретиться на
широкозонном маршруте Интернета в пределах США. Важно признать, что в
Интернете наблюдаются разнообразные значения RTT.
Например, RTT обычно составляет менее 10 мс в среде проводной LAN при
обмене данными с локальным узлом. Международные соединения могут иметь
RTT 200 мс или более. Модемы и другие линии с низкой пропускной
способностью могут добавлять значительную задержку из-за длительного
времени передачи (последовательной передачи) пакетов.
Линии через геостационарные спутники-ретрансляторы имеют односторонние
задержки, обусловленные скоростью света, около 250 мс: минимум 125 мс
задержки распространения до спутника и 125 мс вниз. Ожидается, что RTT
сквозного TCP-соединения, включающего такую линию, будет больше 250 мс.
Очереди на сильно перегруженных линиях могут накапливаться, увеличивая
RTT. Наконец, виртуальные частные сети (VPN) и другие формы шифрования
и туннелирования могут добавлять значительную сквозную задержку к
сетевым соединениям.
9. Соображения качества обслуживания (QoS)
В целом признаётся, что для поддержки мультимедиа реального времени,
телефонии с качеством, сравнимым с качеством телефонной сети, и
других критически важных для производительности приложений необходимы
конкретные гарантии обслуживания. Предоставление таких гарантий
качества обслуживания в Интернете является активной областью
исследований и стандартизации. IETF не пришла к единой модели
обслуживания, набору услуг или единому механизму, который обеспечивал
бы полезные для приложений гарантии и мог масштабироваться до
Интернета. В самом деле, у IETF нет единого определения качества
обслуживания. [RFC2990] отражает текущее понимание проблем,
возникающих при разработке архитектуры QoS для Интернета.
В настоящее время существуют два архитектурных подхода к
предоставлению механизмов поддержки QoS в Интернете.
Интегрированные службы IP (Intserv) [RFC1633] предоставляют
детализированные гарантии обслуживания отдельным потокам. Потоки
идентифицируются спецификацией потока (flowspec), которая создаёт
хранящую состояние связь между отдельными пакетами путём сопоставления
полей в заголовке пакета. Для потока резервируется пропускная
способность, а на маршрутизаторах вдоль пути устанавливаются
соответствующие средства кондиционирования трафика и планирования.
Протокол резервирования (ReSerVation Protocol, RSVP) [RFC2205]
[RFC2210] обычно, но не обязательно, используется для установки
состояния QoS потока. Intserv определяет две службы в дополнение к
службе Default (best effort).
Karn и др. Лучшая современная практика [Страница 26]
RFC 3819 Рекомендации для проектировщиков подсетей Интернета Июль 2004
1. Служба с гарантированным обслуживанием (Guaranteed Service, GS)
[RFC2212] предоставляет строгие верхние границы задержки потокам,
соответствующим спецификации трафика (TSpec). Она использует
модель потока жидкости для связи TSpec и зарезервированной
пропускной способности (RSpec) с переменной задержкой.
Несоответствующие пакеты пересылаются по принципу best effort.
2. Служба контролируемой нагрузки (Controlled Load Service, CLS)
[RFC2211] предоставляет потокам, соответствующим TSpec, задержку
и потери пакетов, эквивалентные таковым в ненагруженной сети, но
без строгих границ. Несоответствующие пакеты пересылаются по
принципу best effort.
Intserv требует установки информации о состоянии в каждом участвующем
маршрутизаторе. Гарантии производительности не могут быть
предоставлены, если это состояние отсутствует в каждом маршрутизаторе
вдоль пути. Считается, что это, наряду с обработкой RSVP и
необходимостью учёта на основе использования, создаёт проблемы
масштабируемости, особенно в ядре Интернета [RFC2208].
Дифференцированные службы IP (Diffserv) [RFC2475] предоставляют
«набор инструментов», предлагающий грубозернистое управление
агрегатами потоков. Diffserv сам по себе *не* предоставляет гарантий
QoS, но может использоваться для построения служб с гарантиями QoS в
пределах домена Diffserv. Diffserv пытается решить проблемы
масштабирования, связанные с Intserv, требуя учёта состояния только на
границе домена Diffserv. На границе пакеты классифицируются по
потокам, а потоки подвергаются кондиционированию (маркировке, контролю
или сглаживанию) в соответствии со спецификацией кондиционирования
трафика (TCS). В заголовке каждого пакета устанавливается Diffserv Codepoint
(DSCP), идентифицирующий поведение на каждом переходе (PHB). DSCP
переносится в поле DS, охватывая шесть бит бывшего байта
Type-of-Service (ToS) [RFC791] заголовка IP [RFC2474]. PHB обозначает
поведение пересылки, применяемое к пакету в каждом узле домена
Diffserv. Хотя с каждым PHB связан «рекомендуемый» DSCP, отображения
DSCP в PHB определяются DS-доменом. Фактически с одним и тем же PHB
может быть связано несколько DSCP. В настоящее время Diffserv
определяет три PHB.
1. PHB селектора класса [RFC2474] заменяет поле приоритета IP
бывшего байта ToS. Он предоставляет относительные приоритеты
пересылки.
2. PHB ускоренной пересылки (Expedited Forwarding, EF) [RFC3246]
[RFC3248] гарантирует, что пакеты будут иметь чётко определённую
минимальную скорость отправки, которая, если не превышена,
обеспечивает, что связанные очереди коротки или пусты. EF
предназначен для поддержки служб, предлагающих жёстко ограниченные
потери, задержку и джиттер задержки.
Karn и др. Лучшая современная практика [Страница 27]
RFC 3819 Рекомендации для проектировщиков подсетей Интернета Июль 2004
3. Группа PHB гарантированной пересылки (Assured Forwarding, AF)
[RFC2597] предлагает различные уровни гарантии пересылки для
каждого агрегированного потока пакетов. Каждой группе AF
независимо выделяются ресурсы пересылки. Пакеты маркируются одним
из трёх приоритетов отбрасывания; пакеты с наивысшим приоритетом
отбрасывания отбрасываются с меньшей вероятностью, чем пакеты,
маркированные наименьшим приоритетом отбрасывания. DSCP
рекомендуются для четырёх независимых групп AF, хотя DS-домен
может иметь большее или меньшее число групп AF.
Текущая работа в IETF рассматривает способы поддержки Intserv с
помощью Diffserv. Существует мнение (например, выраженное в
[RFC2990]), что такой подход позволит отдельным потокам получать
гарантии обслуживания и масштабироваться до глобального Интернета.
Гарантии QoS, которые может предложить уровень IP, являются
результатом двух факторов:
1. объединения гарантий QoS, предлагаемых подсетями вдоль пути
потока. Это подразумевает, что подсеть может пожелать предложить
уровню IP несколько служб (с различными гарантиями QoS), после
чего он сможет определить, какие потоки используют какую службу
подсети. Иными словами, поведение пересылки в подсети должно быть
«подсказано» поведением пересылки (службой или PHB) на уровне IP;
и
2. работы набора взаимодействующих механизмов, таких как
резервирование пропускной способности и контроль допуска,
управление политиками, классификация трафика, кондиционирование
трафика (маркировка, контроль и/или сглаживание), избирательное
отбрасывание, постановка в очередь и планирование. Обратите
внимание, что поддержка QoS в подсетях может потребовать
аналогичных механизмов, особенно когда эти подсети являются
подсетями общей топологии (например, ATM, frame relay или MPLS)
либо подсетями с разделяемой средой.
Многие проектировщики подсетей сталкиваются с неизбежными компромиссами
между задержкой, пропускной способностью, надёжностью и стоимостью.
Другие подсети имеют параметры, управляющие пропускной способностью,
внутренним состоянием соединений и тому подобным. Поэтому следующие
возможности подсети могут быть желательными, хотя некоторые из них
могут быть тривиальными или несущественными, если подсеть представляет
собой выделенную двухточечную линию.
1. Подсети следует обладать возможностью резервировать пропускную
способность для соединения или потока и соответственно
планировать пакеты.
2. Резервирования пропускной способности следует основывать на
модели корзины с одним или двумя маркерами в зависимости от того,
предназначена ли служба для поддержки трафика с постоянной
скоростью или всплескового трафика.
Karn и др. Лучшая современная практика [Страница 28]
RFC 3819 Рекомендации для проектировщиков подсетей Интернета Июль 2004
3. Если соединение или поток в данный момент не использует свою
зарезервированную пропускную способность, неиспользуемую пропускную
способность следует делать доступной другим потокам.
4. Пакеты, превышающие согласованную скорость соединения или потока,
следует пересылать по принципу best effort или отбрасывать в
зависимости от службы, предлагаемой подсетью уровню IP.
5. Если подсеть содержит механизмы контроля ошибок (повторную
передачу и/или FEC), следует обеспечить возможность уровню IP
влиять на присущие компромиссы между неисправленными ошибками,
потерями пакетов и задержкой. Эти возможности на границе служб
подсеть/уровень IP соответствуют выбору большего или меньшего
контроля ошибок и/или выбору конкретных механизмов контроля ошибок
внутри подсети.
6. Уровню подсети следует знать и быть способным сообщать уровню IP,
какую фиксированную задержку и джиттер задержки он предлагает для
потока или соединения. Если используется модель Intserv, компонент
джиттера задержки, возможно, лучше всего выражать в терминах модели
TSpec/RSpec, описанной в [RFC2212].
7. Поддержка селекторов класса Diffserv [RFC2474] предполагает, что
подсеть может рассмотреть механизмы, поддерживающие приоритеты.
10. Справедливость против производительности
Проектировщикам подсетей следует осознавать компромиссы между
справедливостью и эффективностью, присущие многим алгоритмам
планирования передачи. Например, многие локальные сети используют
протоколы конкуренции для разрешения доступа к общему каналу передачи.
Эти протоколы создают накладные расходы. Хотя ограничение объёма
данных, который узел подсети может передать за цикл конкуренции,
помогает обеспечить своевременный доступ к каналу для каждого узла
подсети, оно также увеличивает накладные расходы конкуренции на единицу
переданных данных.
В некоторых сетях мобильной радиосвязи ёмкость ограничена помехами,
которые, в свою очередь, зависят от средней мощности передатчика.
Некоторым приёмникам может требоваться значительно большая мощность
передатчика (создающая больше помех и потребляющая большую ёмкость
канала), чем другим.
В каждом случае разработчик алгоритма планирования должен
сбалансировать конкурирующие цели: предоставить справедливую долю
ёмкости каждому узлу подсети при одновременной максимизации общей
ёмкости сети. Один из подходов к балансированию производительности и
справедливости изложен в [ES00].
Karn и др. Лучшая современная практика [Страница 29]
RFC 3819 Рекомендации для проектировщиков подсетей Интернета Июль 2004
11. Характеристики задержки
Отправитель TCP основывает свой тайм-аут повторной передачи (RTO) на
измерениях задержки кругового обхода, испытанной предыдущими пакетами.
Это позволяет TCP автоматически адаптироваться к чрезвычайно широкому
диапазону задержек, встречающихся в Интернете. Рекомендуемые алгоритмы
описаны в [RFC2988]. Оценки таймера повторной передачи TCP можно найти
в [AP99] и [LS00].
Эти алгоритмы моделируют задержку вдоль пути Интернета как нормально
распределённую случайную величину с медленно изменяющимися средним
значением и стандартным отклонением. TCP оценивает эти два параметра,
экспоненциально сглаживая отдельные измерения задержки, и устанавливает
RTO равным оценённой средней задержке плюс некоторое фиксированное
число стандартных отклонений. (Алгоритм фактически использует среднее
отклонение как приближение стандартного отклонения, поскольку его
легче вычислять.)
Цель состоит в вычислении RTO, достаточно малого для обнаружения
потерь пакетов и восстановления после них, при минимизации ненужных
(«ложных») повторных передач, когда пакеты неожиданно задерживаются,
но не теряются. Хотя эти цели противоречат друг другу, алгоритм
работает хорошо, когда дисперсия задержки вдоль пути Интернета низка
либо частота потерь пакетов низка.
Если дисперсия задержки на пути высока, TCP устанавливает RTO, намного
превышающий среднее значение измеренных задержек. Если частота потерь
пакетов низка, большой RTO имеет малое значение, поскольку тайм-ауты
возникают лишь редко. И наоборот, если дисперсия задержки на пути
низка, TCP быстро восстанавливается после потерянных пакетов; снова
алгоритм работает хорошо. Однако, когда и дисперсия задержки, и частота
потерь пакетов высоки, эти алгоритмы работают плохо, особенно когда
средняя задержка также высока.
Поскольку TCP использует возвращающиеся подтверждения как «часы» для
определения времени передачи дополнительных данных, чрезмерно высокие
задержки (даже если дисперсия задержки низка) также влияют на
способность TCP полностью использовать высокоскоростной канал
передачи. Это также замедляет восстановление потерянных пакетов, даже
когда дисперсия задержки мала.
Поэтому проектировщикам подсетей следует минимизировать все три
параметра (задержку, дисперсию задержки и потери пакетов) настолько,
насколько возможно.
Во многих подсетях эти параметры по своей природе конфликтуют. Например,
на канале мобильной радиосвязи проектировщик подсети может использовать
повторную передачу (ARQ) и/или прямую коррекцию ошибок (FEC), чтобы
находить компромисс между задержкой, дисперсией задержки и потерями
пакетов в попытке улучшить производительность TCP. Хотя ARQ увеличивает
дисперсию задержки, FEC этого не делает. Однако FEC (особенно в
сочетании с перемежением) часто увеличивает среднюю задержку, даже на
хороших каналах, где повторные передачи ARQ не нужны и ARQ не увеличил
бы ни задержку, ни дисперсию задержки.
Karn и др. Лучшая современная практика [Страница 30]
RFC 3819 Рекомендации для проектировщиков подсетей Интернета Июль 2004
Компромиссы между этими механизмами контроля ошибок и их взаимодействия
с TCP могут быть весьма сложными и являются предметом многочисленных
продолжающихся исследований. Поэтому мы рекомендуем, чтобы
проектировщики подсетей обеспечивали как можно большую гибкость при
реализации этих механизмов и предоставляли доступ к ним, как обсуждалось
выше в разделе о качестве обслуживания.
12. Асимметрия пропускной способности
Некоторые подсети могут предоставлять асимметричную пропускную
способность (либо вызывать у потоков пакетов TCP асимметрию ёмкости),
и набор интернет-протоколов в целом всё равно будет работать хорошо.
Однако существует случай, когда такой сценарий снижает
производительность TCP. Поскольку сегменты данных TCP «тактуются»
возвращающимися подтверждениями, отправители TCP ограничены скоростью,
с которой могут возвращаться ACK [BPK98]. Поэтому, когда отношение
доступной ёмкости пути Интернета, несущего данные, к пропускной
способности обратного пути подтверждений слишком велико, медленное
возвращение ACK непосредственно влияет на производительность. Поскольку
ACK обычно меньше сегментов данных, TCP может переносить некоторую
асимметрию, но, как общее правило, проектировщикам подсетей следует
осознавать, что подсети со значительной асимметрией могут приводить к
снижению производительности, если не предпринимаются вопросы для её
смягчения [RFC3449].Было выявлено несколько стратегий уменьшения воздействия асимметрии сетевого пути между двумя конечными TCP-узлами, например [RFC3449]. Эти методы пытаются сократить число ACK, передаваемых по обратному пути (каналу с низкой пропускной способностью), за счёт изменений в конечном узле (конечных узлах) и/или изменения пересылки пакетов подсетью. Хотя эти решения могут смягчить проблемы производительности, вызванные асимметричными подсетями, они сопряжены с затратами и могут иметь другие последствия. Более полное обсуждение стратегий и их последствий приведено в [RFC3449].
13. Буферизация, управление потоком и перегрузкой
Многие подсети включают несколько каналов с различными потребностями в передаче трафика и, возможно, различными скоростями передачи. На каждом канале должна быть система очередей, включающая буферизацию, планирование и возможность отбрасывать избыточные пакеты подсети. Эти очереди также могут быть частью схемы управления потоком или управления перегрузкой подсети.
Karn и др. Best Current Practice [Страница 31]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
Для целей данного обсуждения мы говорим о пакетах независимо от того, относятся ли они к полному IP-пакету или кадру подсети. В каждой очереди пакет испытывает задержку, зависящую от конкурирующего трафика и дисциплины планирования, и подвергается действию локальной политики отбрасывания.
Некоторые подсети могут иметь механизмы управления потоком или перегрузкой в дополнение к отбрасыванию пакетов. Такие механизмы могут работать с компонентами на уровне подсети, такими как планировщики, формирователи или отбрасыватели, и могут влиять на работу IP-пересылателей на границах подсети. Однако, за исключением Explicit Congestion Notification [RFC3168] (рассматриваемого ниже), у IP нет способа передавать TCP явные сигналы перегрузки или управления потоком.
TCP-трафик, особенно агрегированный TCP-трафик, имеет всплесковый характер. В результате мгновенная глубина очередей может резко изменяться даже в номинально стабильных сетях. Для оптимальной производительности пакеты следует отбрасывать контролируемым образом, а не только тогда, когда буферное пространство недоступно. Какой объём буферного пространства следует предоставлять, всё ещё является предметом дискуссий, но в качестве практического правила каждому узлу следует иметь достаточно буферной памяти, чтобы хранить объём данных, равный одному произведению link_bandwidth*link_delay, для каждого TCP-соединения, совместно использующего канал.
Это часто трудно оценить, поскольку это зависит от параметров, находящихся вне контроля или знания подсети. Узлы Интернета обычно не реализуют политики контроля допуска и не могут ограничивать число TCP-соединений, использующих их. В общем случае разумно ошибаться в пользу слишком большой, а не слишком малой буферизации. Подсетям также может быть полезно включать механизмы, измеряющие задержки распространения, чтобы содействовать расчётам размеров буферов.
В исследовательском сообществе существует приблизительный консенсус в том, что активное управление очередями важно для повышения справедливости, использования канала и пропускной способности [RFC2309]. Хотя существуют вопросы и сомнения относительно эффективности активного управления очередями (например, [MBDL99]), оно широко считается улучшением по сравнению с политиками отбрасывания в конце очереди (tail-drop).
Одной из форм активного управления очередями является алгоритм Random Early Detection (RED) [RED93], семейство связанных алгоритмов. В одной версии RED поддерживается экспоненциально взвешенное скользящее среднее глубины очереди:
Когда эта средняя глубина очереди находится между максимальным порогом max_th и минимальным порогом min_th, вероятность отбрасывания пакетов пропорциональна величине, на которую средняя глубина очереди превышает min_th.
Karn и др. Best Current Practice [Страница 32]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
Когда эта средняя глубина очереди равна max_th, вероятность отбрасывания равна настраиваемому параметру max_p.
Когда эта средняя глубина очереди больше max_th, пакеты всегда отбрасываются.
В литературе представлены многочисленные варианты RED, а также другие алгоритмы активного управления очередями, которые заявляют различные преимущества перед RED [GM02].
При использовании алгоритма активного управления очередями отброшенные пакеты становятся сигналом обратной связи, побуждающим TCP в конечных узлах к более подходящему поведению при перегрузке. Рандомизация отбрасывания имеет тенденцию нарушать наблюдаемую склонность TCP-окон, принадлежащих различным TCP-соединениям, синхронизироваться вследствие коррелированных отбрасываний; кроме того, она обеспечивает некоторую степень справедливости для тех соединений, которые правильно реализуют предотвращение перегрузки TCP. Ещё одно важное свойство алгоритмов активного управления очередями состоит в том, что они пытаются поддерживать небольшую среднюю глубину очередей, одновременно допуская большие кратковременные всплески.
Поскольку TCP не знает и не интересуется тем, происходит ли потеря пакетов вследствие перегрузки на уровне IP или в подсети, подсетям, выполняющим постановку в очередь и отбрасывание, может быть целесообразно рассмотреть реализацию некоторой формы активного управления очередями. Это особенно верно, если большие агрегаты TCP-соединений, вероятно, будут совместно использовать одну и ту же очередь. Однако активное управление очередями может быть менее эффективным в случае множества очередей, обслуживающих меньшие агрегаты TCP-соединений, например в ATM-коммутаторе, реализующем постановку в очередь для каждого VC.
Следует отметить, что производительность алгоритмов активного управления очередями чрезвычайно чувствительна к настройкам конфигурируемых параметров, а также к таким факторам, как RTT [MBB00] [FB00].
Некоторые подсети, в особенности ATM, выполняют сегментацию и повторную сборку на границах подсети. При разработке политик отбрасывания здесь следует проявлять осторожность. Если подсеть отбрасывает фрагмент IP-пакета, то оставшиеся фрагменты становятся непроизводительной нагрузкой на подсеть, которая может заметно ухудшить сквозную производительность [RF95]. Поэтому подсети следует пытаться отбрасывать эти дополнительные фрагменты всякий раз, когда один из них необходимо отбросить. Если IP-пакет уже был частично переслан, когда отбрасывание становится необходимым, то следует также отбросить каждый оставшийся фрагмент, кроме того, который обозначает конец IP-пакета. Для ATM-подсетей это, в частности, означает использование Early Packet Discard и Partial Packet Discard [ATMFTM].
Некоторые подсети включают механизмы управления потоком, которые фактически требуют, чтобы скорость потоков трафика формировалась при входе в подсеть. Одним из примеров такого механизма подсети является категория обслуживания ATM Available Bit
Karn и др. Best Current Practice [Страница 33]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
rate (ABR) [ATMFTM]. Такие механизмы управления потоком делают подсеть почти без потерь, перенося перегрузку в IP-маршрутизаторы на границах подсети. В таком случае в этих маршрутизаторах необходимы адекватные буферизация и политики отбрасывания для работы с подсетью, которая представляется имеющей изменяющуюся пропускную способность. Вопрос о наличии пользы от такого рода управления потоком является спорным; существует множество имитационных и аналитических исследований, поддерживающих обе точки зрения. По-видимому, среди проблем, приводящих к столь различным результатам, — чувствительность к параметрам ABR, использование двоичной, а не явной обратной связи о скорости, использование (или неиспользование) постановки в очередь для каждого VC и конкретные алгоритмы ATM-коммутатора, выбранные для исследования. Согласно отдельным свидетельствам, некоторые крупные сети, использовавшие IP поверх ABR для передачи TCP-трафика, заявляли об успехе, но не публиковали результатов.
Другим возможным подходом к управлению потоком в подсети было бы применение семантики TCP Explicit Congestion Notification (ECN) [RFC3168] посредством использования явных индикаторов перегрузки в кадрах подсети. Маршрутизаторы на границах подсети вместо формирования устанавливали бы бит явной перегрузки в тех IP-пакетах, которые получены в кадрах подсети с индикацией ECN. Узлам в подсети необходимо было бы реализовать протокол активного управления очередями, который помечает кадры подсети вместо их отбрасывания.
В настоящее время ECN является предлагаемым стандартом, но ещё не получил широкого развёртывания.
14. Сжатие
Сжатие данных приложений — это функция, которой в подсети обычно можно пренебречь. Конечные точки обычно имеют больше ресурсов CPU и памяти для выполнения алгоритма сжатия и лучше понимают, что именно сжимается. Сквозное сжатие приносит пользу каждому сетевому элементу на пути, тогда как сжатие на уровне подсети по определению приносит пользу только одной подсети.
Данные, передаваемые на уровень подсети, могут уже быть в сжатом формате (например, файл JPEG), сжаты на уровне приложения (например, необязательное сжатие "gzip", "compress" и "deflate" в HTTP/1.1 [RFC2616]) или сжаты на уровне IP (IP Payload Compression Protocol [RFC3173] поддерживает DEFLATE [RFC2394] и LZS [RFC2395]). Сжатие на границах подсети не приносит пользы ни в одном из этих случаев.
Подсеть также может обрабатывать данные, зашифрованные приложением (OpenPGP [RFC2440] или S/MIME [RFC2633]), непосредственно над TCP (SSL, TLS [RFC2246]) или непосредственно над IP (IPsec ESP [RFC2406]).
Karn и др. Best Current Practice [Страница 34]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
Шифры генерируют битовые потоки с высокой энтропией, лишённые каких-либо шаблонов, которые мог бы использовать алгоритм сжатия.
Однако многие данные всё ещё передаются по Интернету несжатыми, поэтому сжатие в подсети может быть полезно. Любой алгоритм сжатия в подсети не должен расширять несжимаемые данные, например данные, уже сжатые или зашифрованные.
Мы настоятельно рекомендуем, чтобы подсети, работающие на низкой скорости или с малыми MTU, сжимали заголовки IP и транспортного уровня (TCP и UDP), используя несколько схем сжатия заголовков, разработанных в IETF [RFC3150]. Несжатый 40-байтовый заголовок TCP/IP передаётся примерно за 33 миллисекунды при 9600 бит/с. Сжатие заголовков TCP/IP "VJ" [RFC1144] сжимает большинство заголовков до 3–5 байтов, сокращая время передачи до нескольких миллисекунд на коммутируемых модемных линиях. Это особенно полезно для малых чувствительных к задержке пакетов в интерактивных сеансах.
Аналогично схемы сжатия RTP, такие как CRTP [RFC2508] и ROHC [RFC3095], сжимают большинство заголовков IP/UDP/RTP до 1–4 байтов. Получаемая экономия особенно значительна, когда аудиопакеты поддерживаются малыми, чтобы минимизировать задержку накопления и пересылки.
Разработчикам следует учитывать влияние частоты ошибок подсети на производительность сжатия заголовков. TCP обычно восстанавливается после потерянных пакетов, повторно передавая только те пакеты, которые были действительно потеряны; пакеты, корректно прибывающие после потери пакета, сохраняются в очереди переупорядочивания и не нуждаются в повторной передаче. Однако при сжатии заголовков VJ TCP/IP [RFC1144] получатель не может явно уведомить отправителя о повреждении данных и последующей потере синхронизации между компрессором и декомпрессором. Вместо этого он полагается на повторную передачу TCP для повторной синхронизации декомпрессора. После потери пакета декомпрессор должен отбрасывать каждый последующий пакет, даже если подсеть не допускает дальнейших ошибок, пока отправляющий TCP не выполнит повторную передачу для повторной синхронизации декомпрессора. Этот эффект может существенно усилить влияние потерь пакетов в подсети, если окно отправляющего TCP велико, как это часто бывает на пути с большим произведением bandwidth*delay [LRKOJ99].
Альтернативные схемы сжатия заголовков, такие как описанные в [RFC2507], включают явный запрос повторной передачи несжатого пакета, позволяющий повторно синхронизировать декомпрессор, не ожидая повторной передачи TCP. Однако эти схемы ещё не получили широкого применения.
Обе схемы сжатия заголовков TCP не сжимают широко используемые параметры TCP, такие как выборочные подтверждения (SACK). Обе не сжимают TCP-трафик, использующий явное уведомление о перегрузке
Karn и др. Best Current Practice [Страница 35]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
(ECN). В рабочей группе IETF ROHC ведётся работа по устранению этих недостатков в схеме сжатия заголовков ROHC для TCP [RFC3095] [RFC3096].
Частота ошибок подсети также важна для сжатия заголовков RTP. CRTP использует дельта-кодирование, поэтому потеря пакета на канале вызывает неопределённость относительно последующих пакетов, которые часто необходимо отбрасывать, пока декомпрессор не уведомит компрессор, а компрессор не передаст информацию для повторной синхронизации. Обычно это занимает немного больше времени, чем время двустороннего прохождения по сквозному пути. Для каналов, сочетающих значительные частоты ошибок с задержками, требующими одновременного нахождения в передаче нескольких пакетов, это приводит к значительному распространению ошибок, то есть к последующим потерям, вызванным первоначальной потерей.
Для каналов одновременно с высокой задержкой (несколько пакетов типичного RTP-потока находятся в передаче) и подверженных ошибкам RTP ROHC предоставляет более устойчивый способ сжатия заголовков RTP ценой большей сложности компрессора и декомпрессора. Например, в пределах речевого отрезка обычно только продолжительные потери (в зависимости от выбранного режима) 12–64 пакетов вызывают распространение ошибок.
15. Переупорядочивание пакетов
Архитектура Интернета не гарантирует, что пакеты прибудут в том же порядке, в котором они были первоначально переданы; транспортные протоколы, такие как TCP, должны это учитывать. Однако переупорядочение всё же сопряжено с издержками для TCP в его
нынешнем определении. Поскольку TCP возвращает совокупное подтверждение
(ACK), указывающее последний поступивший сегмент в правильном порядке,
сегменты, поступившие не по порядку, заставляют TCP-приёмник передавать
дублирующее подтверждение. Когда TCP-отправитель замечает три
дублирующих подтверждения, он предполагает, что сегмент был отброшен
сетью, и использует алгоритм быстрой повторной передачи [Jac90] [RFC2581]
для повторной отправки сегмента. Кроме того, окно перегрузки уменьшается
вдвое, что фактически вдвое снижает скорость отправки TCP. Если
подсеть существенно переупорядочивает сегменты так, что создаются три
дублирующих ACK, TCP-отправитель без необходимости уменьшает окно
перегрузки, и производительность ухудшается.
Переупорядочение пакетов часто происходит в частях Интернета, и его,
по-видимому, трудно или невозможно устранить [BPS99]. По этой причине
начались исследования по улучшению поведения TCP при переупорядочении
пакетов [LK00] [BA02].
Karn, et al. Лучшая современная практика [Страница 36]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
В [BPS99] приводятся причины, по которым устранение переупорядочения
может быть даже нежелательным. Существуют ситуации, в которых при
разрешении переупорядочения можно уменьшить среднюю задержку пакетов,
повысить эффективность канала и/или улучшить надёжность. Примеры
включают некоторые высокоскоростные коммутаторы внутри магистральной
сети Интернета и параллельные каналы, используемые на многих путях
Интернета для распределения нагрузки и резервирования.
Это предполагает, что разработчикам подсетей следует стараться избегать
переупорядочения пакетов всегда, когда это возможно, но не если это
снижает эффективность, ухудшает надёжность или увеличивает среднюю
задержку пакетов.
Следует отметить, что каждая схема сжатия заголовков, в настоящее время
стандартизированная для Интернета, требует доставки пакетов в правильном
порядке по каналу между компрессором и декомпрессором. PPP часто
используется для переноса сжатых пакетов TCP/IP; поскольку он изначально
был разработан для двухточечных и коммутируемых каналов, предполагается,
что он обеспечивает доставку в правильном порядке. По этой причине
разработчики подсетей, предоставляющие интерфейсы PPP для VPN и других
более сложных подсетей, также должны поддерживать доставку кадров PPP в
правильном порядке.
16. Мобильность
Пользователи Интернета становятся всё более мобильными. Многие узлы
Интернета являются не только портативными компьютерами, но и карманные
органайзеры и мобильные встраиваемые системы также становятся узлами в
Интернете. Эти узлы со временем могут подключаться ко многим различным
точкам доступа в Интернете и ожидают, что это будет в значительной
степени прозрачно для их деятельности. За исключением случаев, когда они
вообще не подключены к Интернету, и различий в производительности, когда
они подключены, они ожидают, что всё будет «просто работать» независимо
от их текущей точки подключения к Интернету или технологии локальной
подсети.
Изменение точки подключения хоста к Интернету включает один или несколько
из следующих шагов.
Во-первых, если использование локальной подсети ограничено, учётные
данные пользователя должны быть проверены и доступ предоставлен.
Существует множество способов сделать это. Тривиальным примером могло бы
быть «интернет-кафе», которое за плату предоставляет физический доступ к
подсети. Подсети могут реализовывать собственные технические средства
контроля доступа; одним из примеров является IEEE 802.11 Wireless
Equivalent Privacy [IEEE80211]. Обычной практикой является соглашение
между операторами сотовой связи и поставщиками интернет-услуг (ISP) об
обслуживании пользователей друг друга; RADIUS [RFC2865] является
стандартным методом обмена информацией об авторизации между ISP.
Во-вторых, хост, возможно, придётся перенастроить с параметрами IP,
подходящими для локальной подсети. Обычно это включает настройку
IP-адреса, маршрутизатора по умолчанию и серверов системы доменных имён
(DNS).
Karn, et al. Лучшая современная практика [Страница 37]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
В сетях множественного доступа для этой цели почти повсеместно
используется Dynamic Host Configuration Protocol (DHCP) [RFC2131]. На
каналах PPP эти функции выполняются IP Control Protocol (IPCP) [RFC1332].
В-третьих, трафик, предназначенный мобильному хосту, должен
маршрутизироваться к его текущему местоположению. Эта функция роуминга
является наиболее распространённым значением термина «мобильность в
Интернете».
Мобильность в Интернете может обеспечиваться на любом из нескольких
уровней стека протоколов Интернета, и продолжается обсуждение того, какой
из них является наиболее подходящим и эффективным. Мобильность уже
является свойством некоторых протоколов прикладного уровня; Post Office
Protocol (POP) [RFC1939] и Internet Message Access Protocol (IMAP)
[RFC3501] были созданы специально для обеспечения мобильности при
получении электронной почты.
Мобильность также может обеспечиваться на уровне IP [RFC3344]. Этот
механизм обеспечивает большую прозрачность, а именно IP-адреса, которые
остаются неизменными при перемещении узлов, но ценой потенциально
значительных накладных расходов сети и увеличенной задержки из-за
задействованных неоптимальной маршрутизации сети и туннелирования.
Некоторые подсети могут предоставлять внутреннюю мобильность, прозрачную
для IP, как свойство собственных внутренних механизмов маршрутизации. В
той мере, в какой это упрощает маршрутизацию на уровне IP, уменьшает
потребность в таких механизмах, как Mobile IP, или использует механизмы,
уникальные для подсети, это в целом желательно. Это особенно верно, когда
подсеть охватывает относительно небольшую географическую область, а
пользователи быстро перемещаются между точками подключения внутри этой
области. Примеры схем внутренней мобильности включают коммутацию Ethernet
и внутрисистемную передачу обслуживания в сотовой телефонии.
Однако если подсеть физически велика и подключается к другим частям
Интернета в нескольких географических точках, следует позаботиться об
оптимизации глобальной маршрутизации пакетов между узлами во внешнем
Интернете и узлами в подсети. Обычно это делается с помощью стратегий
маршрутизации «ближайший выход». Поскольку данная подсеть может не знать
фактическое физическое местоположение назначения в другой подсети, она
просто маршрутизирует пакеты, направленные в другую подсеть, к ближайшему
маршрутизатору между этими двумя подсетями. Это предполагает некоторое
знание IP-адресации и маршрутизации внутри подсети. Подсеть может
пожелать использовать маршрутизацию IP внутри себя для глобальной
маршрутизации и ограничить специфичную для подсети маршрутизацию
географически ограниченными областями, где последствия неоптимальной
маршрутизации минимизированы.
Karn, et al. Лучшая современная практика [Страница 38]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
17. Маршрутизация
Подсети, соединяющие более двух систем, должны предоставлять собственные
внутренние механизмы пересылки уровня 2, неявно (например, широковещание)
либо явно (например, коммутацией). Поскольку маршрутизация является
основной функцией уровня Интернета, естественно возникает вопрос о
взаимодействии между маршрутизацией на уровне Интернета и маршрутизацией
в подсети, а также о правильном распределении функций между ними.
Подсети уровня 2 могут быть двухточечными, соединяющими две системы, или
многоточечными. Многоточечные подсети могут быть широковещательными
(например, со средой общего доступа либо эмулируемые) или
нешироковещательными. В целом IP рассматривает многоточечные подсети как
широковещательные, при этом Ethernet со средой общего доступа является
каноническим (и историческим) примером, а двухточечные подсети — как
вырожденный случай. Нешироковещательным подсетям могут потребоваться
дополнительные механизмы, например выше IP на уровне маршрутизации
[RFC2328].
IP не осведомлён о топологии уровня подсети. В частности, изменение
конфигурации путей подсети не отслеживается уровнем IP. На IP влияет
только то, может ли он отправлять/принимать пакеты, отправленные удалённо
подключённым системам через интерфейс подсети (то есть достижимость от
одного маршрутизатора до другого). IP далее считает, что подсети в
значительной степени статичны — что как их состав, так и существование
стабильны в масштабах времени маршрутизации (десятки секунд); изменения
этого рассматриваются как повторное предоставление ресурсов, а не как
маршрутизация.
Функциональность маршрутизации в подсети связана с адресацией в этой
подсети. Разрешение адресов на каналах подсети требуется для пересылки
пакетов IP через каналы (например, ARP для IPv4 или ND для IPv6). Прямое
взаимодействие между маршрутизацией подсети и маршрутизацией IP
маловероятно. Если широковещание предоставляется или явно эмулируется,
разрешение адресов может использоваться непосредственно; если оно не
предоставляется, маршрутизация канального уровня может взаимодействовать
с протоколом разрешения, например с Next-Hop Resolution Protocol
[RFC2322], чтобы предоставить возможности разрешения адресов, зависящие
от контекста.
Маршрутизация подсети может либо дополнять, либо конкурировать с
маршрутизацией IP. Она дополняет IP, когда подсеть инкапсулирует свою
внутреннюю маршрутизацию и последствия этой маршрутизации не видны на
уровне IP. Однако если разные пути в подсети имеют характеристики,
влияющие на маршрутизацию IP, это может влиять на сходимость маршрутизации
IP или даже препятствовать ей.
Karn, et al. Лучшая современная практика [Страница 39]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Протоколы маршрутизации обычно считают подсети уровня 2, то есть с
масками подсети и без промежуточных IP-переходов, имеющими единообразные
метрики маршрутизации до всех участников. Маршрутизация может нарушиться,
когда характеристики канала не соответствуют метрике маршрутизации, в
данном случае, например, когда некоторые пары участников имеют разные
характеристики пути. Рассмотрим виртуальную подсеть Ethernet, включающую
как близко расположенные системы (с задержкой менее миллисекунды), так и
удалённые системы (с задержкой в сотни миллисекунд). Представление этой
группы как одной подсети означает, что некоторые протоколы маршрутизации
будут предполагать, что все пары имеют одинаковую задержку и что эта
задержка мала. Поскольку это не так, построенные таблицы маршрутизации
могут быть неоптимальными или даже не сойтись.
Когда подсеть используется для транзита между набором маршрутизаторов,
она обычно предоставляет эквивалент полной сетки двухточечных каналов.
Простота внутренней структуры подсети может использоваться (например,
через NHRP [RFC2332]) для сокращения размера таблиц разрешения адресов,
но обмены маршрутной информацией продолжат отражать полную сетку, которую
они эмулируют. В целом подсети не следует использовать в качестве
транзита между набором маршрутизаторов, если протоколы маршрутизации
нарушились бы при использовании полной сетки эквивалентных двухточечных
каналов.
Некоторые подсети имеют специальные свойства, позволяющие использовать
более эффективные или отзывчивые механизмы маршрутизации, которые нельзя
реализовать в IP из-за необходимости его универсальности. Одним из
примеров является алгоритм самообучающегося моста, широко используемый в
сетях Ethernet. Обучающиеся мосты выполняют пересылку подсети уровня 2,
избегая необходимости динамической маршрутизации на каждом переходе
подсети. Другим примером является механизм «передачи обслуживания» в
сетях сотовой телефонии, в частности схема «мягкой передачи обслуживания»
в IS-95 CDMA.
Следует избегать подсетей, охватывающих большие географические области
или включающих каналы с сильно различающимися возможностями. Маршрутизация
IP обычно считает все многоточечные подсети эквивалентными локальному
каналу со средой общего доступа с единообразными метриками между любой
парой систем и игнорирует внутреннюю топологию подсети. Если подсеть
отклоняется от этого предположения, разработчики подсети обязаны
предоставить компенсирующие механизмы. Невыполнение этого может повлиять
на масштабируемость и сходимость маршрутизации IP, как отмечалось выше.
Разработчику подсети, который решает реализовать внутреннюю маршрутизацию,
следует рассмотреть, оправдан ли специальный алгоритм маршрутизации или
может оказаться достаточным существующий алгоритм или протокол
маршрутизации Интернета. Разработчику следует рассмотреть, принято ли это
решение для уменьшения размера таблицы разрешения адресов (что возможно,
но требует дополнительной поддержки протокола) или предпринимается
попытка уменьшить сложность таблицы маршрутизации. Последнее может быть
лучше достигнуто путём разделения подсети, физически или логически, и
использования протоколов сетевого уровня для поддержки разделения
(например, AS в BGP). Протоколы и алгоритмы маршрутизации
Karn, et al. Лучшая современная практика [Страница 40]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
могут быть печально известны своей тонкостью, сложностью и трудностью
правильной реализации. Многих усилий можно избежать, если существующие
протоколы или реализации можно легко повторно использовать.
18. Вопросы безопасности
Безопасность стала высоким приоритетом при проектировании и эксплуатации
Интернета. Интернет огромен, и бесчисленное множество организаций и лиц
владеют и эксплуатируют его различные компоненты. Сформировался консенсус
относительно того, что можно назвать «принципом размещения безопасности»:
механизм безопасности наиболее эффективен, когда он размещён как можно
ближе к защищаемому им активу и находится под непосредственным контролем
владельца этого актива.
Следствием этого принципа является то, что сквозная безопасность
(например, конфиденциальность, аутентификация, целостность и контроль
доступа) не может быть обеспечена механизмами безопасности подсети.
Сквозные механизмы безопасности не только гораздо теснее связаны с
активами конечного пользователя, которые они защищают, но и значительно
более всеобъемлющи. Например, сквозные механизмы безопасности закрывают
пробелы, которые могут возникать при последовательном соединении в иных
отношениях хороших механизмов подсети. Это важное применение сквозного
принципа [SRC81].
Ряд механизмов безопасности, которые могут использоваться между конечными точками, уже развёрнуты в Интернете и применяются всё шире. Наиболее важны Secure Sockets Layer (SSL) [SSL2] [SSL3] и TLS [RFC2246], преимущественно используемые для защиты электронной торговли в Интернете; Pretty Good Privacy (PGP) [RFC1991] и S/MIME [RFCs-2630-2634], преимущественно используемые для защиты и аутентификации электронной почты и распространяемого программного обеспечения; Secure Shell (SSH), используемый для безопасного удалённого доступа и передачи файлов; а также IPsec [RFC2401] — механизм шифрования и аутентификации общего назначения, располагающийся непосредственно над IP и пригодный для использования любым IP-приложением. (IPsec фактически может использоваться либо между конечными точками, либо между шлюзами безопасности, не включающими одну или обе конечные системы.)
Тем не менее механизмы безопасности между конечными точками применяются не настолько широко, как могло бы быть желательно. Однако группа не смогла достичь консенсуса относительно того, следует ли активно поощрять разработчиков подсетей реализовывать механизмы защиты пользовательских данных.
Ясный консенсус рабочей группы заключался в том, что механизмы безопасности подсети, особенно слабые или реализованные неправильно [BGW01], могут фактически быть контрпродуктивными. Аргумент состоит в том, что механизмы безопасности подсети могут создавать у конечных пользователей ложное ощущение безопасности, уменьшать стимул к развёртыванию эффективных механизмов между конечными точками
Karn, et al. Best Current Practice [Page 41]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
и поощрять «рискованные» способы использования Интернета, которые не применялись бы, если бы пользователи понимали неотъемлемые ограничения механизмов безопасности подсети.
Другая точка зрения поощряет безопасность подсети, исходя из принципа, что она лучше ситуации по умолчанию, которая слишком часто вообще не предусматривает никакой безопасности. Пользователи особенно уязвимых подсетей (такие как потребители, имеющие домашние беспроводные сети и/или доступ в Интернет через общую среду передачи) часто контролируют не более одной конечной точки — обычно клиента — и потому не могут обеспечить использование механизмов между конечными точками. Однако безопасность подсети может быть полностью достаточной для защиты малоценных активов от наиболее вероятных угроз. В любом случае механизмы подсети не исключают использования механизмов между конечными точками, которые обычно применяются для защиты высокоценных активов. Эта точка зрения признаёт, что многие политики безопасности неявно предполагают, что весь путь между конечными точками состоит из последовательности соединённых звеньев, номинально защищённых физически. То есть эти политики предполагают, что все конечные точки всех звеньев заслуживают доверия и что атакующим трудно получить доступ к физической среде. Для удовлетворения предположений таких политик необходимы явные механизмы для звеньев (особенно звеньев с общей средой передачи), не имеющих физической защиты. Таково, например, обоснование Wired Equivalent Privacy (WEP) в стандарте беспроводных LAN IEEE 802.11 [IEEE80211] и Baseline Privacy Interface в стандартах передачи данных по кабельным телевизионным сетям DOCSIS [DOCSIS1] [DOCSIS2].
Поэтому мы рекомендуем разработчикам подсетей, которые выбирают реализацию механизмов безопасности для защиты пользовательских данных, быть настолько откровенными, насколько возможно, в отношении деталей таких механизмов безопасности и неотъемлемых ограничений даже наиболее защищённых механизмов при их реализации в подсети, а не между конечными точками.
В соответствии с «принципом размещения» существует ясный консенсус относительно другой роли безопасности подсети: защиты самой подсети. Возможные угрозы активам подсети включают хищение услуг и отказ в обслуживании; подсети с общей средой передачи, как правило, особенно уязвимы для таких атак. В некоторых случаях механизмы, защищающие активы подсети, также могут улучшить (но не могут гарантировать) безопасность между конечными точками.
Подсеть может предоставлять одну службу безопасности, которая поможет решить общую проблему Интернета: безопасности подсети следует предоставлять механизм аутентификации источника кадра подсети. Эта функция отсутствует в некоторых современных протоколах, например при использовании ARP [RFC826] для связывания адреса IPv4 с MAC-адресом. IPv6 Neighbor Discovery (ND) [RFC2461] выполняет аналогичную функцию.
Karn, et al. Best Current Practice [Page 42]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
У этого механизма разрешения адресов имеются хорошо известные недостатки безопасности [Wilbur89]. Однако включение аутентификации источника кадра подсети позволит обеспечить защищённый адрес подсети.
Другая потенциальная роль безопасности подсети — защита пользователей от анализа трафика, то есть выявления взаимодействующих сторон и определения схем и объёмов их обмена данными, даже когда фактическое содержимое защищено сильными механизмами безопасности между конечными точками. Безопасность нижнего уровня может быть более эффективной против анализа трафика благодаря присущей ей способности агрегировать коммуникации множества сторон, совместно использующих одни и те же физические средства, одновременно скрывая информацию протоколов более высокого уровня, которая указывает конкретные конечные точки, например IP-адреса и номера портов TCP/UDP.
Однако анализ трафика — общеизвестно тонкая и трудная для понимания и отражения угроза, значительно более сложная, чем угрозы конфиденциальности и целостности. Поэтому мы настоятельно призываем к крайней осторожности при проектировании механизмов безопасности подсети, специально предназначенных для противодействия анализу трафика.
Разработчики подсетей должны помнить, что проектирование и реализация средств безопасности трудны [Schneier00]. В [Schneier95] описаны протоколы и алгоритмы, которые считаются хорошо изученными и предположительно надёжными.
Некачественный процесс проектирования, тонкие ошибки проектирования и дефектная реализация могут приводить к вопиющим уязвимостям. В последние годы в ряде стандартов подсетей были выявлены проблемы. Ниже приведены примеры допущенных ошибок:
1. Использование слабых и непроверенных алгоритмов [Crypto9912] [BGW01]. По различным причинам были выбраны алгоритмы с тонкими недостатками, делавшими их уязвимыми к различным атакам.
2. Использование «безопасности через сокрытие» [Schneier00] [Crypto9912]. Одна распространённая ошибка состоит в предположении, что сохранение криптографических алгоритмов в тайне делает их безопаснее. Это интуитивно, но неверно. Полное публичное раскрытие на ранней стадии процесса проектирования привлекает экспертную оценку знающих криптографов. Выявление недостатков в ходе такой оценки намного перевешивает любую воображаемую выгоду от принуждения атакующих к обратной разработке алгоритмов безопасности.
3. Включение лазеек [Schneier00] [Crypto9912]. Лазейки — это недостатки, тайно оставленные в алгоритме, чтобы позволить его взломать. Это может быть сделано для восстановления утраченных ключей или для предоставления скрытого доступа государственным органам. Лазейки могут быть обнаружены и использованы злоумышленниками.
Karn, et al. Best Current Practice [Page 43]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
4. Передача паролей или иной идентифицирующей информации открытым текстом. В течение многих лет аналоговые сотовые телефоны можно было клонировать и использовать для хищения услуг. Клонировщики лишь прослушивали протоколы регистрации, в которых всё передавалось открытым текстом.
5. Ключи, общие для всех систем в подсети [BGW01].
6. Неправильное использование надёжного механизма. Например [BGW01], один стандарт подсети включает вектор инициализации, который плохо спроектирован и плохо специфицирован. Решительный атакующий может легко восстановить несколько шифротекстов, зашифрованных одним и тем же ключевым потоком, и выполнить статистические атаки для их расшифровки.
7. Передаваемая открытым текстом идентифицирующая информация, которую можно сопоставить с отдельным идентифицируемым устройством. Это создаёт уязвимость для атак, направленных на это устройство (или его владельца).
8. Невозможность обновлять и отзывать общую секретную информацию.
9. Недостаточная длина ключа.
10. Неспособность противодействовать атакам «человек посередине», например с помощью взаимной аутентификации.
11. Неспособность предоставить форму обнаружения повторной передачи, например для предотвращения принятия получателем пакетов от атакующего, который лишь повторно посылает ранее захваченный сетевой трафик.
12. Неспособность предоставить механизмы целостности при предоставлении схем конфиденциальности [Bel98].
Этот список далеко не исчерпывающий. Проблем проектирования трудно избежать, но экспертная оценка обычно неоценима для их предотвращения.
Кроме того, хорошо спроектированные протоколы безопасности могут быть скомпрометированы дефектами реализации. Примеры таких дефектов включают использование предсказуемых псевдослучайных чисел [RFC1750], уязвимость к атакам переполнения буфера вследствие небезопасного использования некоторых системных вызовов ввода-вывода [WFBA2000] и непреднамеренное раскрытие секретных данных.
19. Участники
Этот документ представляет консенсус членов рабочей группы IETF Performance Implications of Link Characteristics (PILC).
Karn, et al. Best Current Practice [Page 44]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
Этот документ не был бы возможен без вклада большого числа людей из рабочей группы Performance Implications of Link Characteristics. В частности, следующие люди внесли значительный вклад в текст, редактирование и рекомендации для этого документа: Mark Allman выполнил окончательное редактирование для завершения этого документа. Carsten Bormann предоставил текст об устойчивом сжатии заголовков. Gorry Fairhurst предоставил текст по вопросам широковещательной и многоадресной передачи, маршрутизации и множество ценных замечаний по всему документу. Aaron Falk предоставил текст о выделении пропускной способности по требованию. Dan Grossman предоставил текст по многим аспектам документа. Reiner Ludwig выполнил тщательную проверку документа и предоставил текст о сравнении повторной передачи TCP и повторной передачи на канальном уровне. Jamshid Mahdavi предоставил текст о расчётах производительности TCP. Saverio Mascolo предоставил отзыв о документе. Gabriel Montenegro предоставил отзыв о документе. Marie-Jose Montpetit предоставила текст о выделении пропускной способности по требованию. Joe Touch предоставил текст о многоадресной передаче, широковещательной передаче и маршрутизации, а Lloyd Wood предоставил множество ценных замечаний к версиям документа.
20. Информативные ссылки
Ссылки вида RFCnnnn являются документами Internet Request for Comments (RFC), доступными в Интернете по адресу www.rfc-editor.org.
[802.1D] Information Technology Telecommunications and
information exchange between systems Local and
metropolitan area networks, Common specifications Media
access control (MAC) bridges, IEEE 802.1D, 1998. ISO
15802-3.
[802.1p] IEEE, 802.1p, Standard for Local and Metropolitan Area
Networks - Supplement to Media Access Control (MAC)
Bridges: Traffic Class Expediting and Multicast.
[AP99] Allman, M. and V. Paxson, On Estimating End-to-End
Network Path Properties, In Proceedings of ACM SIGCOMM
99.
[AR02] Acar, G. and C. Rosenberg, Weighted Fair Bandwidth-on-
Demand (WFBoD) for Geo-Stationary Satellite Networks
with On-Board Processing, Computer Networks, 39(1),
2002.
[ATMFTM] The ATM Forum, "Traffic Management Specification,
Version 4.0", April 1996, document af-tm-0056.000.
http://www.atmforum.com/
Karn, et al. Best Current Practice [Page 45]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to
Packet Reordering. ACM Computer Communication Review,
32(1), January 2002.
[Bel98] Bellovin, S., "Cryptography and the Internet", in
Proceedings of CRYPTO '98, August 1998.
http://www.research.att.com/~smb/papers/inet-crypto.pdf
[BGW01] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
Mobile Communications: The Insecurity of 802.11," In
Proceedings of ACM MobiCom, July 2001.
[BPK98] Balakrishnan, H., Padmanabhan, V. and R. Katz. "The
Effects of Asymmetry on TCP Performance." ACM Mobile
Networks and Applications (MONET), 1998.
[BPS99] Bennet,, J.C.R., Partridge, C. and N. Shectman, "Packet
Reordering is Not Pathological Network Behavior",
IEEE/ACM Transactions on Networking, Vol. 7, No. 6,
December 1999.
[CGMP] Farinacci D., Tweedly A. and T. Speakman, "Cisco Group
Management Protocol (CGMP)", 1996/1997.
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[Crypto9912] Schneier, B., "European Cellular Encryption Algorithms"
Crypto-Gram, December 15, 1999.
http://www.counterpane.com
[DIX82] Digital Equipment Corp, Intel Corp, Xerox Corp,
Ethernet Local Area Network Specification Version 2.0,
November 1982.
[DOCSIS1] Data-Over-Cable Service Interface Specifications, Radio
Frequency Interface Specification 1.0, SP-RFI-I05-
991105, November 1999, Cable Television Laboratories,
Inc. [DOCSIS2] Data-Over-Cable Service Interface Specifications, Radio
Frequency Interface Specification 1.1, SP-RFIv1.1-I05-
000714, July 2000, Cable Television Laboratories, Inc.
[DOCSIS3] Lai, W.S., "DOCSIS-Based Cable Networks: Impact of
Large Data Packets on Upstream Capacity", 14th ITC
Specialists Seminar on Access Networks and Systems,
Barcelona, Spain, April 25-27, 2001.
Karn, et al. Лучшая современная практика [Страница 46]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
[EN301192] ETSI, European Broadcasting Union, Digital Video
Broadcasting (DVB); DVB Specification for Data
Broadcasting, European Standard (Telecommunications
Series) EN 301 192 v1.2.1(1999-06).
[ES00] Eckhardt, D. and P. Steenkiste, "Effort-limited Fair
(ELF) Scheduling for Wireless Networks, Proceedings of
IEEE Infocom 2000.
[FB00] Firoiu V. and M. Borden, "A Study of Active Queue
Management for Congestion Control", должно быть
опубликовано в Infocom 2000.
[GM02] Grieco1, L. and S. Mascolo, "TCP Westwood and Easy RED
to Improve Fairness in High-Speed Networks",
Proceedings of the 7th International Workshop on
Protocols for High-Speed Networks, April 2002.
[IEEE8023] IEEE 802.3 CSMA/CD Access Method.
http://standards.ieee.org/
[IEEE80211] IEEE 802.11 Wireless LAN standard.
http://standards.ieee.org/
[ISO3309] ISO/IEC 3309:1991(E), "Information Technology -
Telecommunications and information exchange between
systems - High-level data link control (HDLC)
procedures - Frame structure", International
Organization For Standardization, Fourth edition 1991-
06-01.
[ISO13818] ISO/IEC, ISO/IEC 13818-1:2000(E) Information
Technology - Generic coding of moving pictures and
associated audio information: Systems, Second edition,
2000-12-01 International Organization for
Standardization and International Electrotechnical
Commission.
[ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification
Type AAL5, International Standards Organisation (ISO),
1996.
[Jac90] Jacobson, V., Modified TCP Congestion Avoidance
Algorithm. Электронное письмо в список рассылки
end2end-interest, апрель 1990.
ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
Karn, et al. Лучшая современная практика [Страница 47]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
[KY02] Khafizov, F. and M. Yavuz, Running TCP Over IS-2000,
Proceedings of IEEE ICC, 2002.
[LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making
TCP Robust Against Spurious Retransmissions", ACM
Computer Communication Review, Vol. 30, No. 1, January
2000.
[LKJK02] Ludwig, R., Konrad, A., Joseph, A. D. and R. H. Katz,
"Optimizing the End-to-End Performance of Reliable
Flows over Wireless Links", Kluwer/ACM Wireless
Networks Journal, Vol. 8, Nos. 2/3, pp. 289-299,
March-May 2002.
[LRKOJ99] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K. and A.
Joseph, Multi-Layer Tracing of TCP over a Reliable
Wireless Link, стр. 144-154, в Proceedings of ACM
SIGMETRICS 99.
[LS00] Ludwig, R. and K. Sklower, The Eifel Retransmission
Timer, ACM Computer Communication Review, Vol. 30, No.
3, July 2000.
[MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick,
"IGMP/MLD-based Multicast Forwarding ("IGMP/MLD
Proxying")", В работе.
[MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky,
"Considerations for IGMP and MLD Snooping Switches",
В работе.
[MBB00] May, M., Bonald, T. and J-C. Bolot, "Analytic
Evaluation of RED Performance", INFOCOM 2000.
[MBDL99] May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not
to deploy RED", Proc. of 7th. International Workshop on
Quality of Service (IWQoS'99), June 1999.
[MSMO97] Mathis, M., Semke, J., Mahdavi, J. and T. Ott, "The
Macroscopic Behavior of the TCP Congestion Avoidance
Algorithm", Computer Communication Review, Vol. 27,
number 3, July 1997.
[MYR95] Boden, N., Cohen, D., Felderman, R., Kulawik, A.,
Seitz, C., et al. MYRINET: A Gigabit per Second Local
Area Network, IEEE-Micro, Vol. 15, No.1, February 1995,
pp. 29-36.
Karn, et al. Лучшая современная практика [Страница 48]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
[PFTK98] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose,
"Modeling TCP Throughput: a Simple Model and its
Empirical Validation", UMASS CMPSCI Tech Report TR98-
008, Feb. 1998.
[RED93] Floyd, S. and V. Jacobson, "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM
Transactions in Networking, Vol. 1 No. 4, August 1993.
http://www.aciri.org/floyd/papers/red/red.html
[RF95] Romanow, A. and S. Floyd, "Dynamics of TCP Traffic over
ATM Networks". IEEE Journal of Selected Areas in
Communication, Vol.13 No. 4, May 1995, p. 633-641.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC826] Plummer, D.C., "Ethernet Address Resolution Protocol:
Or converting network protocol addresses to 48-bit
Ethernet address for transmission on Ethernet
hardware", STD 37, RFC 826, November 1982.
[RFC1071] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet checksum", RFC 1071, September 1988.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC 1112, August 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.
[RFC1332] McGregor, C., "The PPP Internet Protocol Control
Protocol (IPCP)", RFC 1332, May 1992.
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
Karn, et al. Лучшая современная практика [Страница 49]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51,
RFC 1662, July 1994.
[RFC1750] Eastlake 3rd, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October
1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell,
M., Romanow, A., Weinrib, A. and L. Zhang, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Applicability
Statement Some Guidelines on Deployment", RFC 2208,
September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
Karn, et al. Лучшая современная практика [Страница 50]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C. and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L.,
Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April
1998.
[RFC2322] van den Hout, K., Koopal, A. and R. van Mook,
"Management of IP numbers by peg-dhcp", RFC 2322, 1
April 1998.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)",
RFC 2332, April 1998.
[RFC2364] Gross, G., Kaycee, M., Li, A., Malis, A. and J.
Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE",
RFC 2394, December 1998.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression
Using LZS", RFC 2395, December 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
Karn, et al. Лучшая современная практика [Страница 51]
RFC 3819 Рекомендации для разработчиков подсетей Интернета Июль 2004
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February
1999.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification
to TCP's Fast Recovery Algorithm", RFC 2582, April
1999.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
Handling", RFC 2632, June 1999.
Karn и др. Лучшая современная практика [Страница 52]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol
Encapsulation over ATM Adaptation Layer 5", RFC 2684,
September 1999.
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link
PPP", RFC 2686, September 1999.
[RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like
Framing", RFC 2687, September 1999.
[RFC2689] Bormann, C., "Providing Integrated Services over Low-
bitrate Links", RFC 2689, September 1999.
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC
2784, March 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S. and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001.
Karn и др. Лучшая современная практика [Страница 53]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
[RFC3095] Bormann, C., Ed., Burmeister, C., Degermark, M.,
Fukushima, H., Hannu, H., Jonsson, L-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.
[RFC3096] Degermark, M., Ed., "Requirements for robust IP/UDP/RTP
header compression", RFC 3096, 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.
[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.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3173] Shacham, A., Monsour, B., Pereira, R. and M. Thomas,
"IP Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J.,
Halpern, J., Kumar, B. and J. Schnizlein, "A Delay
Bound alternative revision of RFC 2598", RFC 3248,
March 2002.
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
August 2002.
Karn и др. Лучшая современная практика [Страница 54]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
Sooriyabandara, "TCP Performance Implications of
Network Path Asymmetry", BCP 69, RFC 3449, December
2002.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L.,
Handley, M. and J. Crowcroft, "Layered Coding Transport
(LCT) Building Block", RFC 3451, December 2002.
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
Handley, M. and J. Crowcroft, "Forward Error Correction
(FEC) Building Block", RFC 3452, December 2002.
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
Handley, M. and J. Crowcroft, "The Use of Forward Error
Correction (FEC) in Reliable Multicast", RFC 3453,
December 2002.
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group
Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
Ed. and G. Fairhurst, Ed., "The User Datagram Protocol
(UDP)-Lite Protocol", RFC 3828, June 2004.
[Schneier95] Schneier, B., Applied Cryptography: Protocols,
Algorithms and Source Code in C (John Wiley and Sons,
October 1995).
[Schneier00] Schneier, B., Secrets and Lies: Digital Security in a
Networked World (John Wiley and Sons, August 2000).
[SP2000] Stone, J. and C. Partridge, "When the CRC and TCP
Checksum Disagree", ACM SIGCOMM, September 2000.
http://www.acm.org/sigcomm/sigcomm2000/conf/
paper/sigcomm2000-9-1.pdf
Karn и др. Лучшая современная практика [Страница 55]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
[SRC81] Saltzer, J., Reed D. and D. Clark, "End-to-End
Arguments in System Design". Second International
Conference on Distributed Computing Systems (April,
1981) pages 509-512. Published with minor changes in
ACM Transactions in Computer Systems 2, 4, November,
1984, pages 277-288. Reprinted in Craig Partridge,
editor Innovations in internetworking. Artech House,
Norwood, MA, 1988, pages 195-206. ISBN 0-89006-337-0.
[SSL2] Hickman, K., "The SSL Protocol", Netscape
Communications Corp., Feb 9, 1995.
[SSL3] Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., Nov 18, 1996.
[TCPF98] Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies:
Analysis and Improvements", IEEE Infocom, March 1998.
http://www.eecs.harvard.edu/networking/papers/infocom-
tcp-final-198.pdf
[WFBA2000] Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A
First Step Toward Automated Detection of Buffer Overrun
Vulnerabilities", Proceedings of NDSS2000.
http://www.isoc.org/isoc/conferences/ndss/
2000/proceedings/039.pdf
[Wilbur89] Wilbur, Steve R., Jon Crowcroft, and Yuko Murayama.
"MAC layer Security Measures in Local Area Networks",
Local Area Network Security, Workshop LANSEC '89
Proceedings, Springer-Verlag, April 1989, pp. 53-64.
Karn и др. Лучшая современная практика [Страница 56]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
21. Адреса участников
Aaron Falk
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, CA 90292
Телефон: 310-448-9327
Электронная почта: falk@isi.edu
Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica,
Politecnico di Bari Via Orabona 4, 70125 Bari, Italy
Телефон: +39 080 596 3621
Электронная почта: mascolo@poliba.it
URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
Marie-Jose Montpetit
MJMontpetit.com
Электронная почта: marie@mjmontpetit.com
Karn и др. Лучшая современная практика [Страница 57]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
22. Адреса авторов
Phil Karn, редактор
Qualcomm 5775 Morehouse Drive
San Diego CA 92121
Телефон: 858 587 1121
Электронная почта: karn@qualcomm.com
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
D-28334 Bremen, Germany
Телефон: +49 421 218 7024
Факс: +49 421 218 7000
Электронная почта: cabo@tzi.org
Godred (Gorry) Fairhurst
Department of Engineering, University of Aberdeen,
Aberdeen, AB24 3UE, United Kingdom
Электронная почта: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
Dan Grossman
Motorola, Inc.
111 Locke Drive
Marlboro, MA 01752
Электронная почта: Dan.Grossman@motorola.com
Reiner Ludwig
Ericsson Research
Ericsson Allee
1 52134 Herzogenrath, Germany
Телефон: +49 2407 575 719
Электронная почта: Reiner.Ludwig@ericsson.com
Karn и др. Лучшая современная практика [Страница 58]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
Jamshid Mahdavi
Novell, Inc.
Электронная почта: jmahdavi@earthlink.net
Gabriel Montenegro
Sun Microsystems Laboratories, Europe
180, Avenue de l'Europe
38334 Saint Ismier CEDEX
France
Электронная почта: gab@sun.com
Joe Touch
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey CA 90292
Телефон: 310 448 9151
Электронная почта: touch@isi.edu
URL: http://www.isi.edu/touch
Lloyd Wood
Cisco Systems
9 New Square Park, Bedfont Lakes
Feltham TW14 8HA
United Kingdom
Телефон: +44 (0)20 8824 4236
Электронная почта: lwood@cisco.com
URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
Karn и др. Лучшая современная практика [Страница 59]
RFC 3819 Advice for Internet Subnetwork Designers Июль 2004
23. Полное заявление об авторских правах
Авторское право (C) The Internet Society (2004). Этот документ
регулируется правами, лицензиями и ограничениями, содержащимися в BCP 78,
и, за исключением предусмотренного в нём, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются на условиях
"КАК ЕСТЬ", И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ
КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), THE INTERNET SOCIETY И THE
INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ
ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО,
ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО
ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ
ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает какой-либо позиции относительно действительности или
объёма каких-либо прав интеллектуальной собственности либо иных прав,
которые могут быть заявлены как относящиеся к реализации или использованию
технологии, описанной в этом документе, или относительно того, может ли
какая-либо лицензия по таким правам быть доступна; IETF также не заявляет,
что предприняла какие-либо независимые усилия для выявления каких-либо
таких прав. Информацию о процедурах, касающихся прав в документах RFC,
можно найти в BCP 78 и BCP 79.
Копии раскрытий IPR, направленных в Секретариат IETF, и любых заверений о
лицензиях, которые будут предоставлены, либо результат попытки получить
общую лицензию или разрешение на использование таких прав собственности
разработчиками или пользователями этой спецификации можно получить из
онлайнового репозитория IPR IETF по адресу http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне довести до её сведения
любые авторские права, патенты или патентные заявки либо иные права
собственности, которые могут охватывать технологию, которая может
потребоваться для реализации этого стандарта. Пожалуйста, направляйте
информацию в IETF по адресу ietf-ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
The Internet Society.
Karn и др. Лучшая современная практика [Страница 60]
Network Working Group P. Karn, Ed.
Request for Comments: 3819 Qualcomm
BCP: 89 C. Bormann
Category: Best Current Practice Universitaet Bremen TZI
G. Fairhurst
University of Aberdeen
D. Grossman
Motorola, Inc.
R. Ludwig
Ericsson Research
J. Mahdavi
Novell
G. Montenegro
Sun Microsystems Laboratories, Europe
J. Touch
USC/ISI
L. Wood
Cisco Systems
July 2004
Advice for Internet Subnetwork Designers
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 (2004).
Abstract
This document provides advice to the designers of digital
communication equipment, link-layer protocols, and packet-switched
local networks (collectively referred to as subnetworks), who wish to
support the Internet protocols but may be unfamiliar with the
Internet architecture and the implications of their design choices on
the performance and efficiency of the Internet.
Karn, et al. Best Current Practice [Page 1]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Table of Contents
1. Introduction and Overview. . . . . . . . . . . . . . . . . . . 2
2. Maximum Transmission Units (MTUs) and IP Fragmentation . . . . 4
2.1. Choosing the MTU in Slow Networks. . . . . . . . . . . . 6
3. Framing on Connection-Oriented Subnetworks . . . . . . . . . . 7
4. Connection-Oriented Subnetworks. . . . . . . . . . . . . . . . 9
5. Broadcasting and Discovery . . . . . . . . . . . . . . . . . . 10
6. Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Bandwidth on Demand (BoD) Subnets. . . . . . . . . . . . . . . 13
8. Reliability and Error Control. . . . . . . . . . . . . . . . . 14
8.1. TCP vs Link-Layer Retransmission . . . . . . . . . . . . 14
8.2. Recovery from Subnetwork Outages . . . . . . . . . . . . 17
8.3. CRCs, Checksums and Error Detection. . . . . . . . . . . 18
8.4. How TCP Works. . . . . . . . . . . . . . . . . . . . . . 20
8.5. TCP Performance Characteristics. . . . . . . . . . . . . 22
8.5.1. The Formulae . . . . . . . . . . . . . . . . . . 22
8.5.2. Assumptions. . . . . . . . . . . . . . . . . . . 23
8.5.3. Analysis of Link-Layer Effects on TCP
Performance. . . . . . . . . . . . . . . . . . . 24
9. Quality-of-Service (QoS) Considerations. . . . . . . . . . . . 26
10. Fairness vs Performance. . . . . . . . . . . . . . . . . . . . 29
11. Delay Characteristics. . . . . . . . . . . . . . . . . . . . . 30
12. Bandwidth Asymmetries. . . . . . . . . . . . . . . . . . . . . 31
13. Buffering, Flow and Congestion Control . . . . . . . . . . . . 31
14. Compression. . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. Packet Reordering. . . . . . . . . . . . . . . . . . . . . . . 36
16. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
17. Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
20. Informative References . . . . . . . . . . . . . . . . . . . . 45
21. Contributors' Addresses. . . . . . . . . . . . . . . . . . . . 57
22. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 58
23. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 60
1. Introduction and Overview
IP, the Internet Protocol [RFC791] [RFC2460], is the core protocol of
the Internet. IP defines a simple "connectionless" packet-switched
network. The success of the Internet is largely attributed to IP's
simplicity, the "end-to-end principle" [SRC81] on which the Internet
is based, and the resulting ease of carrying IP on a wide variety of
subnetworks, not necessarily designed with IP in mind. A subnetwork
refers to any network operating immediately below the IP layer to
connect two or more systems using IP (i.e., end hosts or routers).
In its simplest form, this may be a direct connection between the IP
systems (e.g., using a length of cable or a wireless medium).
Karn, et al. Best Current Practice [Page 2]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
This document defines a subnetwork as a layer 2 network, which is a
network that does not rely upon the services of IP routers to forward
packets between parts of the subnetwork. However, IP routers may
bridge frames at Layer 2 between parts of a subnetwork. Sometimes,
it is convenient to aggregate a group of such subnetworks into a
single logical subnetwork. IP routing protocols (e.g., OSPF, IS-IS,
and PIM) can be configured to support this aggregation, but typically
present a layer-3 subnetwork rather than a layer-2 subnetwork. This
may also result in a specific packet passing several times over the
same layer-2 subnetwork via an intermediate layer-3 gateway (router).
Because that aggregation requires layer-3 components, issues thereof
are beyond the scope of this document.
However, while many subnetworks carry IP, they do not necessarily do
so with maximum efficiency, minimum complexity, or cost, nor do they
implement certain features to efficiently support newer Internet
features of increasing importance, such as multicasting or quality of
service.
With the explosive growth of the Internet, IP packets comprise an
increasingly large fraction of the traffic carried by the world's
telecommunications networks. It therefore makes sense to optimize
both existing and new subnetwork technologies for IP as much as
possible.
Optimizing a subnetwork for IP involves three complementary
considerations:
1. Providing functionality sufficient to carry IP.
2. Eliminating unnecessary functions that increase cost or
complexity.
3. Choosing subnetwork parameters that maximize the performance of
the Internet protocols.
Because IP is so simple, consideration 2 is more of an issue than
consideration 1. That is to say, subnetwork designers make many more
errors of commission than errors of omission. However, certain
enhancements to Internet features, such as multicasting and quality-
of-service, benefit significantly from support given by the
underlying subnetworks beyond that necessary to carry "traditional"
unicast, best-effort IP.
Karn, et al. Best Current Practice [Page 3]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
A major consideration in the efficient design of any layered
communication network is the appropriate layer(s) in which to
implement a given function. This issue was first addressed in the
seminal paper, "End-to-End Arguments in System Design" [SRC81]. That
paper argued that many functions can be implemented properly *only*
on an end-to-end basis, i.e., at the highest protocol layers, outside
the subnetwork. These functions include ensuring the reliable
delivery of data and the use of cryptography to provide
confidentiality and message integrity.
Such functions cannot be provided solely by the concatenation of
hop-by-hop services; duplicating these functions at the lower
protocol layers (i.e., within the subnetwork) can be needlessly
redundant or even harmful to cost and performance.
However, partial duplication of functionality in a lower layer can
*sometimes* be justified by performance, security, or availability
considerations. Examples include link-layer retransmission to
improve the performance of an unusually lossy channel, e.g., mobile
radio, link-level encryption intended to thwart traffic analysis, and
redundant transmission links to improve availability, increase
throughput, or to guarantee performance for certain classes of
traffic. Duplication of protocol functions should be done only with
an understanding of system-level implications, including possible
interactions with higher-layer mechanisms.
The original architecture of the Internet was influenced by the
end-to-end principle [SRC81], and has been, in our view, part of the
reason for the Internet's success.
The remainder of this document discusses the various subnetwork
design issues that the authors consider relevant to efficient IP
support.
2. Maximum Transmission Units (MTUs) and IP Fragmentation
IPv4 packets (datagrams) vary in size, from 20 bytes (the size of the
IPv4 header alone) to a maximum of 65535 bytes. Subnetworks need not
support maximum-sized (64KB) IP packets, as IP provides a scheme that
breaks packets that are too large for a given subnetwork into
fragments that travel as independent IP packets and are reassembled
at the destination. The maximum packet size supported by a
subnetwork is known as its Maximum Transmission Unit (MTU).
Subnetworks may, but are not required to, indicate the length of each
packet they carry. One example is Ethernet with the widely used DIX
[DIX82] (not IEEE 802.3 [IEEE8023]) header, which lacks a length
Karn, et al. Best Current Practice [Page 4]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
field to indicate the true data length when the packet is padded to a
minimum of 60 bytes. This is not a problem for uncompressed IP
because each IP packet carries its own length field.
If optional header compression [RFC1144] [RFC2507] [RFC2508]
[RFC3095] is used, however, it is required that the link framing
indicate frame length because that is needed for the reconstruction
of the original header.
In IP version 4 (the version now in widespread use), fragmentation
can occur at either the sending host or in an intermediate router,
and fragments can be further fragmented at subsequent routers if
necessary.
In IP version 6 [RFC2460], fragmentation can occur only at the
sending host; it cannot occur in a router (called "router
fragmentation" in this document).
Both IPv4 and IPv6 provide a "path MTU discovery" procedure [RFC1191]
[RFC1435] [RFC1981] that allows the sending host to avoid
fragmentation by discovering the minimum MTU along a given path and
reduce its packet sizes accordingly. This procedure is optional in
IPv4 and IPv6.
Path MTU discovery is widely deployed, but it sometimes encounters
problems. Some routers fail to generate the ICMP messages that
convey path MTU information to the sender, and sometimes the ICMP
messages are blocked by overly restrictive firewalls. The result can
be a "Path MTU Black Hole" [RFC2923] [RFC1435].
The Path MTU Discovery procedure, the persistence of path MTU black
holes, and the deletion of router fragmentation in IPv6 reflect a
consensus of the Internet technical community that router
fragmentation is best avoided. This requires that subnetworks
support MTUs that are "reasonably" large. All IPv4 end hosts are
required to accept and reassemble IP packets of size 576 bytes
[RFC791], but such a small value would clearly be inefficient.
Because IPv6 omits fragmentation by routers, [RFC2460] specifies a
larger minimum MTU of 1280 bytes. Any subnetwork with an internal
packet payload smaller than 1280 bytes must implement a mechanism
that performs fragmentation/reassembly of IP packets to/from
subnetwork frames if it is to support IPv6.
If a subnetwork cannot directly support a "reasonable" MTU with
native framing mechanisms, it should internally fragment. That is,
it should transparently break IP packets into internal data elements
and reassemble them at the other end of the subnetwork.
Karn, et al. Best Current Practice [Page 5]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
This leaves the question of what is a "reasonable" MTU. Ethernet (10
and 100 Mb/s) has an MTU of 1500 bytes, and because of the ubiquity
of Ethernet few Internet paths currently have MTUs larger than this
value. This severely limits the utility of larger MTUs provided by
other subnetworks. Meanwhile, larger MTUs are increasingly desirable
on high-speed subnetworks to reduce the per-packet processing
overhead in host computers, and implementers are encouraged to
provide them even though they may not be usable when Ethernet is also
in the path.
Various "tunneling" schemes, such as GRE [RFC2784] or IP Security in
tunnel mode [RFC2406], treat IP as a subnetwork for IP. Since
tunneling adds header overhead, it can trigger fragmentation, even
when the same physical subnetworks (e.g., Ethernet) are used on both
sides of the host performing IPsec encapsulation. Tunneling has made
it more difficult to avoid router fragmentation and has increased the
incidence of path MTU black holes [RFC2401] [RFC2923]. Larger
subnetwork MTUs may help to alleviate this problem.
2.1. Choosing the MTU in Slow Networks
In slow networks, the largest possible packet may take a considerable
amount of time to send. This is known as channelisation or
serialisation delay. Total end-to-end interactive response time
should not exceed the well-known human factors limit of 100 to 200
ms. This includes all sources of delay: electromagnetic propagation
delay, queuing delay, serialisation delay, and the store-and-forward
time, i.e., the time to transmit a packet at link speed.
At low link speeds, store-and-forward delays can dominate total
end-to-end delay; these are in turn directly influenced by the
maximum transmission unit (MTU) size. Even when an interactive
packet is given a higher queuing priority, it may have to wait for a
large bulk transfer packet to finish transmission. This worst-case
wait can be set by an appropriate choice of MTU.
For example, if the MTU is set to 1500 bytes, then an MTU-sized
packet will take about 8 milliseconds to send on a T1 (1.536 Mb/s)
link. But if the link speed is 19.2kb/s, then the transmission time
becomes 625 ms -- well above our 100-200ms limit. A 256-byte MTU
would lower this delay to a little over 100 ms. However, care should
be taken not to lower the MTU excessively, as this will increase
header overhead and trigger frequent router fragmentation (if Path
MTU discovery is not in use). This is likely to be the case with
multicast, where Path MTU discovery is ineffective.
One way to limit delay for interactive traffic without imposing a
small MTU is to give priority to this traffic and to preempt (abort)
Karn, et al. Best Current Practice [Page 6]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
the transmission of a lower-priority packet when a higher priority
packet arrives in the queue. However, the link resources used to
send the aborted packet are lost, and overall throughput will
decrease.
Another way to limit delay is to implement a link-level multiplexing
scheme that allows several packets to be in progress simultaneously,
with transmission priority given to segments of higher-priority IP
packets. For links using the Point-To-Point Protocol (PPP)
[RFC1661], multi-class multilink [RFC2686] [RFC2687] [RFC2689]
provides such a facility.
ATM (asynchronous transfer mode), where SNDUs are fragmented and
interleaved across smaller 53-byte ATM cells, is another example of
this technique. However, ATM is generally used on high-speed links
where the store-and-forward delays are already minimal, and it
introduces significant (~9%) increases in overhead due to the
addition of 5-byte cell overhead to each 48-byte ATM cell.
A third example is the Data-Over-Cable Service Interface
Specification (DOCSIS) with typical upstream bandwidths of 2.56 Mb/s
or 5.12 Mb/s. To reduce the impact of a 1500-byte MTU in DOCSIS 1.0
[DOCSIS1], a data link layer fragmentation mechanism is specified in
DOCSIS 1.1 [DOCSIS2]. To accommodate the installed base, DOCSIS 1.1
must be backward compatible with DOCSIS 1.0 cable modems, which
generally do not support fragmentation. Under the co-existence of
DOCSIS 1.0 and DOCSIS 1.1, the unfragmented large data packets from
DOCSIS 1.0 cable modems may affect the quality of service for voice
packets from DOCSIS 1.1 cable modems. In this case, it has been
shown in [DOCSIS3] that the use of bandwidth allocation algorithms
can mitigate this effect.
To summarize, there is a fundamental tradeoff between efficiency and
latency in the design of a subnetwork, and the designer should keep
this tradeoff in mind.
3. Framing on Connection-Oriented Subnetworks
IP requires that subnetworks mark the beginning and end of each
variable-length, asynchronous IP packet. Some examples of links and
subnetworks that do not provide this as an intrinsic feature include:
1. leased lines carrying a synchronous bit stream;
2. ISDN B-channels carrying a synchronous octet stream;
3. dialup telephone modems carrying an asynchronous octet stream;
Karn, et al. Best Current Practice [Page 7]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
and
4. Asynchronous Transfer Mode (ATM) networks carrying an
asynchronous stream of fixed-sized "cells".
The Internet community has defined packet framing methods for all
these subnetworks. The Point-To-Point Protocol (PPP) [RFC1661],
which uses a variant of HDLC, is applicable to bit synchronous,
octet-synchronous, and octet asynchronous links (i.e., examples 1-3
above). PPP is one preferred framing method for IP, since a large
number of systems interoperate with PPP. ATM has its own framing
methods, described in [RFC2684] [RFC2364].
At high speeds, a subnetwork should provide a framed interface
capable of carrying asynchronous, variable-length IP datagrams. The
maximum packet size supported by this interface is discussed above in
the MTU/Fragmentation section. The subnetwork may implement this
facility in any convenient manner.
IP packet boundaries need not coincide with any framing or
synchronization mechanisms internal to the subnetwork. When the
subnetwork implements variable sized data units, the most
straightforward approach is to place exactly one IP packet into each
subnetwork data unit (SNDU), and to rely on the subnetwork's existing
ability to delimit SNDUs to also delimit IP packets. A good example
is Ethernet. However, some subnetworks have SNDUs of one or more
fixed sizes, as dictated by switching, forward error correction
and/or interleaving considerations. Examples of such subnetworks
include ATM, with a single cell payload size of 48 octets plus a 5-
octet header, and IS-95 digital cellular, with two "rate sets" of
four fixed frame sizes each that may be selected on 20 millisecond
boundaries.
Because IP packets are of variable length, they may not necessarily
fit into an integer multiple of fixed-sized SNDUs. An "adaptation
layer" is needed to convert IP packets into SNDUs while marking the
boundary between each IP packet in some manner.
There are several approaches to this problem. The first is to encode
each IP packet into one or more SNDUs with no SNDU containing pieces
of more than one IP packet, and to pad out the last SNDU of the
packet as needed. Bits in a control header added to each SNDU
indicate where the data segment belongs in the IP packet. If the
subnetwork provides in-order, at-most-once delivery, the header can
be as simple as a pair of bits indicating whether the SNDU is the
first and/or the last in the IP packet. Alternatively, for
subnetworks that do not reorder the fragments of an SNDU, only the
last SNDU of the packet could be marked, as this would implicitly
Karn, et al. Best Current Practice [Page 8]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
indicate the next SNDU as the first in a new IP packet. The AAL5
(ATM Adaptation Layer 5) scheme used with ATM is an example of this
approach, though it adds other features, including a payload length
field and a payload CRC.
In AAL5, the ATM User-User Indication, which is encoded in the
Payload Type field of an ATM cell, indicates the last cell of a
packet. The packet trailer is located at the end of the SNDU and
contains the packet length and a CRC.
Another framing technique is to insert per-segment overhead to
indicate the presence of a segment option. When present, the option
carries a pointer to the end of the packet. This differs from AAL5
in that it permits another packet to follow within the same segment.
MPEG-2 Transport Streams [EN301192] [ISO13818] support this style of
fragmentation, and may either use padding (limiting each MPEG
transport stream packet to carry only part of one IP packet), or
allow a second IP packet to start in the same Transport Stream packet
(no padding).
A third approach is to insert a special flag sequence into the data
stream between each IP packet, and to pack the resulting data stream
into SNDUs without regard to SNDU boundaries. This may have
implications when frames are lost. The flag sequence can also pad
unused space at the end of an SNDU. If the special flag appears in
the user data, it is escaped to an alternate sequence (usually larger
than a flag) to avoid being misinterpreted as a flag. The HDLC-based
framing schemes used in PPP are all examples of this approach.
All three adaptation schemes introduce overhead; how much depends on
the distribution of IP packet sizes, the size(s) of the SNDUs, and in
the HDLC-like approaches, the content of the IP packet (since flag-
like sequences occurring in the packet must be escaped, which expands
them). The designer must also weigh implementation complexity and
performance in the choice and design of an adaptation layer.
4. Connection-Oriented Subnetworks
IP has no notion of a "connection"; it is a purely connectionless
protocol. When a connection is required by an application, it is
usually provided by TCP [RFC793], the Transmission Control Protocol,
running atop IP on an end-to-end basis.
Connection-oriented subnetworks can be (and are widely) used to carry
IP, but often with considerable complexity. Subnetworks consisting
of few nodes can simply open a permanent connection between each pair
of nodes. This is frequently done with ATM. However, the number of
connections increases as the square of the number of nodes, so this
Karn, et al. Best Current Practice [Page 9]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
is clearly impractical for large subnetworks. A "shim" layer between
IP and the subnetwork is therefore required to manage connections.
This is one of the most common functions of a Subnetwork Dependent
Convergence Function (SNDCF) sublayer between IP and a subnetwork.
SNDCFs typically open subnetwork connections as needed when an IP
packet is queued for transmission and close them after an idle
timeout. There is no relation between subnetwork connections and any
connections that may exist at higher layers (e.g., TCP).
Because Internet traffic is typically bursty and transaction-
oriented, it is often difficult to pick an optimal idle timeout. If
the timeout is too short, subnetwork connections are opened and
closed rapidly, possibly over-stressing the subnetwork connection
management system (especially if it was designed for voice traffic
call holding times). If the timeout is too long, subnetwork
connections are idle much of the time, wasting any resources
dedicated to them by the subnetwork.
Purely connectionless subnets (such as Ethernet), which have no state
and dynamically share resources, are optimal for supporting best-
effort IP, which is stateless and dynamically shares resources.
Connection-oriented packet networks (such as ATM and Frame Relay),
which have state and dynamically share resources, are less optimal,
since best-effort IP does not benefit from the overhead of creating
and maintaining state. Connection-oriented circuit-switched networks
(including the PSTN and ISDN) have state and statically allocate
resources for a call, and thus require state creation and maintenance
overhead, but do not benefit from the efficiencies of statistical
multiplexing sharing of capacity inherent in IP.
In any event, if an SNDCF that opens and closes subnet connections is
used to support IP, care should be taken to make sure that connection
processing in the subnet can keep up with relatively short holding
times.
5. Broadcasting and Discovery
Subnetworks fall into two categories: point-to-point and shared. A
point-to-point subnet has exactly two endpoint components (hosts or
routers); a shared link has more than two endpoint components, using
either an inherently broadcast medium (e.g., Ethernet, radio) or a
switching layer hidden from the network layer (e.g., switched
Ethernet, Myrinet [MYR95], ATM). Switched subnetworks handle
broadcast by copying broadcast packets, providing each interface that
supports one, or more, systems (hosts or routers) with a copy of each
packet.
Karn, et al. Best Current Practice [Page 10]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Several Internet protocols for IPv4 make use of broadcast
capabilities, including link-layer address lookup (ARP), auto-
configuration (RARP, BOOTP, DHCP), and routing (RIP).
A lack of broadcast capability can impede the performance of these
protocols, or render them inoperable (e.g., DHCP). ARP-like link
address lookup can be provided by a centralized database, but at the
expense of potentially higher response latency and the need for nodes
to have explicit knowledge of the ARP server address. Shared links
should support native, link-layer subnet broadcast.
A corresponding set of IPv6 protocols uses multicasting (see next
section) instead of broadcasting to provide similar functions with
improved scaling in large networks.
6. Multicasting
The Internet model includes "multicasting", where IP packets are sent
to all the members of a multicast group [RFC1112] [RFC3376]
[RFC2710]. Multicast is an option in IPv4, but a standard feature of
IPv6. IPv4 multicast is currently used by multimedia,
teleconferencing, gaming, and file distribution (web, peer-to-peer
sharing) applications, as well as by some key network and host
protocols (e.g., RIPv2, OSPF, NTP). IPv6 additionally relies on
multicast for network configuration (DHCP-like autoconfiguration) and
link-layer address discovery [RFC2461] (replacing ARP). In the case
of IPv6, this can allow autoconfiguration and address discovery to
span across routers, whereas the IPv4 broadcast-based services cannot
without ad-hoc router support [RFC1812].
Multicast-enabled IP routers organize each multicast group into a
spanning tree, and route multicast packets by making copies of each
multicast packet and forwarding the copies to each output interface
that includes at least one downstream member of the multicast group.
Multicasting is considerably more efficient when a subnetwork
explicitly supports it. For example, a router relaying a multicast
packet onto an Ethernet segment need send only one copy of the
packet, no matter how many members of the multicast group are
connected to the segment. Without native multicast support, routers
and switches on shared links would need to use broadcast with
software filters, such that every multicast packet sent incurs
software overhead for every node on the subnetwork, even if a node is
not a member of the multicast group. Alternately, the router would
transmit a separate copy to every member of the multicast group on
the segment, as is done on multicast-incapable switched subnets.
Karn, et al. Best Current Practice [Page 11]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Subnetworks using shared channels (e.g., radio LANs, Ethernets) are
especially suitable for native multicasting, and their designers
should make every effort to support it. This involves designating a
section of the subnetwork's own address space for multicasting. On
these networks, multicast is basically broadcast on the medium, with
Layer-2 receiver filters.
Subnet interfaces also need to be designed to accept packets
addressed to some number of multicast addresses, in addition to the
unicast packets specifically addressed to them. The number of
multicast addresses that needs to be supported by a host depends on
the requirements of the associated host; at least several dozen will
meet most current needs.
On low-speed networks, the multicast address recognition function may
be readily implemented in host software, but on high-speed networks,
it should be implemented in subnetwork hardware. This hardware need
not be complete; for example, many Ethernet interfaces implement a
"hashing" function where the IP layer receives all of the multicast
(and unicast) traffic to which the associated host subscribes, plus
some small fraction of multicast traffic to which the host does not
subscribe. Host/router software then has to discard the unwanted
packets that pass the Layer-2 multicast address filter [RFC1112].
There does not need to be a one-to-one mapping between a Layer-2
multicast address and an IP multicast address. An address overlap
may significantly degrade the filtering capability of a receiver's
hardware multicast address filter. A subnetwork supporting only
broadcast should use this service for multicast and must rely on
software filtering.
Switched subnetworks must also provide a mechanism for copying
multicast packets to ensure the packets reach at least all members of
a multicast group. One option is to "flood" multicast packets in the
same manner as broadcast. This can lead to unnecessary transmissions
on some subnetwork links (notably non-multicast-aware Ethernet
switches). Some subnetworks therefore allow multicast filter tables
to control which links receive packets belonging to a specific group.
To configure this automatically requires access to Layer-3 group
membership information (e.g., IGMP [RFC3376], or MLD [RFC2710]).
Various implementation options currently exist to provide a subnet
node with a list of mappings of multicast addresses to
ports/interfaces. These employ a range of approaches, including
signaling from end hosts (e.g., IEEE 802 GARP/GMRP [802.1p]),
signaling from switches (e.g., CGMP [CGMP] and RGMP [RFC3488]),
interception and proxy of IP group membership packets (e.g., IGMP/MLD
Proxy [MAGMA-PROXY]), and enabling Layer-2 devices to
snoop/inspect/peek into forwarded Layer-3 protocol headers (e.g.,
Karn, et al. Best Current Practice [Page 12]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
IGMP, MLD, PIM) so that they may infer Layer-3 multicast group
membership [MAGMA-SNOOP]. These approaches differ in their
complexity, flexibility, and ability to support new protocols.
7. Bandwidth on Demand (BoD) Subnets
Some subnets allow a number of subnet nodes to share a channel
efficiently by assigning transmission opportunities dynamically.
Transmission opportunities are requested by a subnet node when it has
packets to send. The subnet schedules and grants transmission
opportunities sufficient to allow the transmitting subnet node to
send one or more packets (or packet fragments). We call these
subnets Bandwidth on Demand (BoD) subnets. Examples of BoD subnets
include Demand Assignment Multiple Access (DAMA) satellite and
terrestrial wireless networks, IEEE 802.11 point coordination
function (PCF) mode, and DOCSIS. A connection-oriented network (such
as the PSTN, ATM or Frame Relay) reserves resources on a much longer
timescale, and is therefore not a BoD subnet in our taxonomy.
The design parameters for BoD are similar to those in connection-
oriented subnetworks, although the implementations may vary
significantly. In BoD, the user typically requests access to the
shared channel for some duration. Access may be allocated for a
period of time at a specific rate, for a certain number of packets,
or until the user releases the channel. Access may be coordinated
through a central management entity or with a distributed algorithm
amongst the users. Examples of the resource that may be shared
include a terrestrial wireless hop, an upstream channel in a cable
television system, a satellite uplink, and an end-to-end satellite
channel.
Long-delay BoD subnets pose problems similar to connection-oriented
subnets in anticipating traffic. While connection-oriented subnets
hold idle channels open expecting new data to arrive, BoD subnets
request channel access based on buffer occupancy (or expected buffer
occupancy) on the sending port. Poor performance will likely result
if the sender does not anticipate additional traffic arriving at that
port during the time it takes to grant a transmission request. It is
recommended that the algorithm have the capability to extend a hold
on the channel for data that has arrived after the original request
was generated (this may be done by piggybacking new requests on user
data).
There is a wide variety of BoD protocols available. However, there
has been relatively little comprehensive research on the interactions
between BoD mechanisms and Internet protocol performance. Research
on some specific mechanisms is available (e.g., [AR02]). One item
that has been studied is TCP's retransmission timer [KY02]. BoD
Karn, et al. Best Current Practice [Page 13]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
systems can cause spurious timeouts when adjusting from a relatively
high data rate, to a relatively low data rate. In this case, TCP's
transmitted data takes longer to get through the network than
predicted by the TCP sender's computed retransmission timeout.
Therefore, the TCP sender is prone to resending a segment
prematurely.
8. Reliability and Error Control
In the Internet architecture, the ultimate responsibility for error
recovery is at the end points [SRC81]. The Internet may occasionally
drop, corrupt, duplicate, or reorder packets, and the transport
protocol (e.g., TCP) or application (e.g., if UDP is used as the
transport protocol) must recover from these errors on an end-to-end
basis [RFC3155]. Error recovery in the subnetwork is therefore
justifiable only to the extent that it can enhance overall
performance. It is important to recognize that a subnetwork can go
too far in attempting to provide error recovery services in the
Internet environment. Subnet reliability should be "lightweight",
i.e., it only has to be "good enough", *not* perfect.
In this section, we discuss how to analyze characteristics of a
subnetwork to determine what is "good enough". The discussion below
focuses on TCP, which is the most widely-used transport protocol in
the Internet. It is widely believed (and is a stated goal within the
IETF) that non-TCP transport protocols should attempt to be "TCP-
friendly" and have many of the same performance characteristics.
Thus, the discussion below should be applicable, even to portions of
the Internet where TCP may not be the predominant protocol.
8.1. TCP vs Link-Layer Retransmission
Error recovery involves the generation and transmission of redundant
information computed from user data. Depending on how much redundant
information is sent and how it is generated, the receiver can use it
to reliably detect transmission errors, correct up to some maximum
number of transmission errors, or both. The general approach is
known as Error Control Coding, or ECC.
The use of ECC to detect transmission errors so that retransmissions
(hopefully without errors) can be requested is widely known as "ARQ"
(Automatic Repeat Request).
When enough ECC information is available to permit the receiver to
correct some transmission errors without a retransmission, the
approach is known as Forward Error Correction (FEC). Due to the
greater complexity of the required ECC and the need to tailor its
design to the characteristics of a specific modem and channel, FEC
Karn, et al. Best Current Practice [Page 14]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
has traditionally been implemented in special-purpose hardware
integral to a modem. This effectively makes it part of the physical
layer.
Unlike ARQ, FEC was rarely used for telecommunications outside of
space links prior to the 1990s. It is now nearly universal in
telephone, cable and DSL modems, digital satellite links, and digital
mobile telephones. FEC is also heavily used in optical and magnetic
storage where "retransmissions" are not possible.
Some systems use hybrid combinations of ARQ layered atop FEC; V.90
dialup modems (in the upstream direction) with V.42 error control are
one example. Most errors are corrected by the trellis (FEC) code
within the V.90 modem, and most remaining errors are detected and
corrected by the ARQ mechanisms in V.42.
Work is now underway to apply FEC above the physical layer, primarily
in connection with reliable multicasting [RFC3048] [RFC3450-RFC3453]
where conventional ARQ mechanisms are inefficient or difficult to
implement. However, in this discussion, we will assume that if FEC
is present, it is implemented within the physical layer.
Depending on the layer in which it is implemented, error control can
operate on an end-to-end basis or over a shorter span, such as a
single link. TCP is the most important example of an end-to-end
protocol that uses an ARQ strategy.
Many link-layer protocols use ARQ, usually some flavor of HDLC
[ISO3309]. Examples include the X.25 link layer, the AX.25 protocol
used in amateur packet radio, 802.11 wireless LANs, and the reliable
link layer specified in IEEE 802.2.
Only end-to-end error recovery can ensure reliable service to the
application (see Section 8). However, some subnetworks (e.g., many
wireless links) also have link-layer error recovery as a performance
enhancement [RFC3366]. For example, many cellular links have small
physical frame sizes (< 100 bytes) and relatively high frame loss
rates. Relying solely on end-to-end error recovery can clearly yield
a performance degradation, as retransmissions across the end-to-end
path take much longer to be received than when link layer
retransmissions are used. Thus, link-layer error recovery can often
increase end-to-end performance. As a result, link-layer and end-
to-end recovery often co-exist; this can lead to the possibility of
inefficient interactions between the two layers of ARQ protocols.
This inter-layer "competition" might lead to the following wasteful
situation. When the link layer retransmits (parts of) a packet, the
link latency momentarily increases. Since TCP bases its
Karn, et al. Best Current Practice [Page 15]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
retransmission timeout on prior measurements of total end-to-end
latency, including that of the link in question, this sudden increase
in latency may trigger an unnecessary retransmission by TCP of a
packet that the link layer is still retransmitting. Such spurious
end-to-end retransmissions generate unnecessary load and reduce end-
to-end throughput. As a result, the link layer may even have
multiple copies of the same packet in the same link queue at the same
time. In general, one could say the competing error recovery is
caused by an inner control loop (link-layer error recovery) reacting
to the same signal as an outer control loop (end-to-end error
recovery) without any coordination between the loops. Note that this
is solely an efficiency issue; TCP continues to provide reliable
end-to-end delivery over such links.
This raises the question of how persistent a link-layer sender should
be in performing retransmission [RFC3366]. We define the link-layer
(LL) ARQ persistency as the maximum time that a particular link will
spend trying to transfer a packet before it can be discarded. This
deliberately simplified definition says nothing about the maximum
number of retransmissions, retransmission strategies, queue sizes,
queuing disciplines, transmission delays, or the like. The reason we
use the term LL ARQ persistency, instead of a term such as "maximum
link-layer packet holding time," is that the definition closely
relates to link-layer error recovery. For example, on links that
implement straightforward error recovery strategies, LL ARQ
persistency will often correspond to a maximum number of
retransmissions permitted per link-layer frame.
For link layers that do not or cannot differentiate between flows
(e.g., due to network layer encryption), the LL ARQ persistency
should be small. This avoids any harmful effects or performance
degradation resulting from indiscriminate high persistence. A
detailed discussion of these issues is provided in [RFC3366].
However, when a link layer can identify individual flows and apply
ARQ selectively [LKJK02], then the link ARQ persistency should be
high for a flow using reliable unicast transport protocols (e.g.,
TCP) and must be low for all other flows. Setting the link ARQ
persistency larger than the largest link outage allows TCP to rapidly
restore transmission without needing to wait for a retransmission
time out. This generally improves TCP performance in the face of
transient outages. However, excessively high persistence may be
disadvantageous; a practical upper limit of 30-60 seconds may be
desirable. Implementation of such schemes remains a research issue.
(See also the following section "Recovery from Subnetwork Outages").
Karn, et al. Best Current Practice [Page 16]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Many subnetwork designers have opportunities to reduce the
probability of packet loss, e.g., with FEC, ARQ, and interleaving, at
the cost of increased delay. TCP performance improves with
decreasing loss but worsens with increasing end-to-end delay, so it
is important to find the proper balance through analysis and
simulation.
8.2. Recovery from Subnetwork Outages
Some types of subnetworks, particularly mobile radio, are subject to
frequent temporary outages. For example, an active cellular data
user may drive or walk into an area (such as a tunnel) that is out of
range of any base station. No packets will be delivered successfully
until the user returns to an area with coverage.
The Internet protocols currently provide no standard way for a
subnetwork to explicitly notify an upper layer protocol (e.g., TCP)
that it is experiencing an outage rather than severe congestion.
Under these circumstances TCP will, after each unsuccessful
retransmission, wait even longer before trying again; this is its
"exponential back-off" algorithm. Furthermore, TCP will not discover
that the subnetwork outage has ended until its next retransmission
attempt. If TCP has backed off, this may take some time. This can
lead to extremely poor TCP performance over such subnetworks.
It is therefore highly desirable that a subnetwork subject to outages
does not silently discard packets during an outage. Ideally, the
subnetwork should define an interface to the next higher layer (i.e.,
IP) that allows it to refuse packets during an outage, and to
automatically ask IP for new packets when it is again able to deliver
them. If it cannot do this, then the subnetwork should hold onto at
least some of the packets it accepts during an outage and attempt to
deliver them when the outage ends. When packets are discarded, IP
should be notified so that the appropriate ICMP messages can be sent.
Note that it is *not* necessary to completely avoid dropping packets
during an outage. The purpose of holding onto a packet during an
outage, either in the subnetwork or at the IP layer, is so that its
eventual delivery will implicitly notify TCP that the subnetwork is
again operational. This is to enhance performance, not to ensure
reliability -- reliability, as discussed earlier, can only be ensured
on an end-to-end basis.
Only a few packets per TCP connection, including ACKs, need be held
in this way to cause the TCP sender to recover from the additional
losses once the flow resumes [RFC3366].
Karn, et al. Best Current Practice [Page 17]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Because it would be a layering violation (and possibly a performance
hit) for IP or a subnetwork layer to look at TCP headers (which would
in any event be impossible if IPsec encryption [RFC2401] is in use),
it would be reasonable for the IP or subnetwork layers to choose, as
a design parameter, some small number of packets that will be
retained during an outage.
8.3. CRCs, Checksums and Error Detection
The TCP [RFC793], UDP [RFC768], ICMP, and IPv4 [RFC791] protocols all
use the same simple 16-bit 1's complement checksum algorithm
[RFC1071] to detect corrupted packets. The IPv4 header checksum
protects only the IPv4 header, while the TCP, ICMP, and UDP checksums
provide end-to-end error detection for both the transport pseudo
header (including network and transport layer information) and the
transport payload data. Protection of the data is optional for
applications using UDP [RFC768] for IPv4, but is required for IPv6.
The Internet checksum is not very strong from a coding theory
standpoint, but it is easy to compute in software, and various
proposals to replace the Internet checksums with stronger checksums
have failed. However, it is known that undetected errors can and do
occur in packets received by end hosts [SP2000].
To reduce processing costs, IPv6 has no IP header checksum. The
destination host detects "important" errors in the IP header, such as
the delivery of the packet to the wrong destination. This is done by
including the IP source and destination addresses (pseudo header) in
the computation of the checksum in the TCP or UDP header, a practice
already performed in IPv4. Errors in other IPv6 header fields may go
undetected within the network; this was considered a reasonable price
to pay for a considerable reduction in the processing required by
each router, and it was assumed that subnetworks would use a strong
link CRC.
One way to provide additional protection for an IPv4 or IPv6 header
is by the authentication and packet integrity services of the IP
Security (IPsec) protocol [RFC2401]. However, this may not be a
choice available to the subnetwork designer.
Most subnetworks implement error detection just above the physical
layer. Packets corrupted in transmission are detected and discarded
before delivery to the IP layer. A 16-bit cyclic redundancy check
(CRC) is usually the minimum for error detection. This is
significantly more robust against most patterns of errors than the
16-bit Internet checksum. Note that the error detection properties
of a specific CRC code diminish with increasing frame size. The
Point-to-Point Protocol [RFC1662] requires support of a 16-bit CRC
Karn, et al. Best Current Practice [Page 18]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
for each link frame, with a 32-bit CRC as an option. (PPP is often
used in conjunction with a dialup modem, which provides its own error
control). Other subnetworks, including 802.3/Ethernet, AAL5/ATM,
FDDI, Token Ring, and PPP over SONET/SDH all use a 32-bit CRC. Many
subnetworks can also use other mechanisms to enhance the error
detection capability of the link CRC (e.g., FEC in dialup modems,
mobile radio and satellite channels).
Any new subnetwork designed to carry IP should therefore provide
error detection for each IP packet that is at least as strong as the
32-bit CRC specified in [ISO3309]. While this will achieve a very
low undetected packet error rate due to transmission errors, it will
not (and need not) achieve a very low packet loss rate as the
Internet protocols are better suited to dealing with lost packets
than to dealing with corrupted packets [SRC81].
Packet corruption may be, and is, also caused by bugs in host and
router hardware and software. Even if every subnetwork implemented
strong error detection, it is still essential that end-to-end
checksums are used at the receiving end host [SP2000].
Designers of complex subnetworks consisting of internal links and
packet switches should consider implementing error detection on an
edge-to-edge basis to cover an entire SNDU (or IP packet). A CRC
would be generated at the entry point to the subnetwork and checked
at the exit endpoint. This may be used instead of, or in combination
with, error detection at the interface to each physical link. An
edge-to-edge check has the significant advantage of protecting
against errors introduced anywhere within the subnetwork, not just
within its transmission links. Examples of this approach include the
way in which the Ethernet CRC-32 is handled by LAN bridges [802.1D].
ATM AAL5 [ITU-I363] also uses an edge-to-edge CRC-32.
Some specific applications may be tolerant of residual errors in the
data they exchange, but removal of the link CRC may expose the
network to an undesirable increase in undetected errors in the IP and
transport headers. Applications may also require a high level of
error protection for control information exchanged by protocols
acting above the transport layer. One example is a voice codec,
which is robust against bit errors in the speech samples. For such
mechanisms to work, the receiving application must be able to
tolerate receiving corrupted data. This also requires that an
application uses a mechanism to signal that payload corruption is
permitted and to indicate the coverage (headers and data) required to
be protected by the subnetwork CRC. The UDP-Lite protocol [RFC3828]
is the first Internet standards track transport protocol supporting
partial payload protection. Receipt of corrupt data by arbitrary
Karn, et al. Best Current Practice [Page 19]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
application protocols carries a serious danger that a subnet delivers
data with errors that remain undetected by the application and hence
corrupt the communicated data [SRC81].
8.4. How TCP Works
One of TCP's functions is end-host based congestion control for the
Internet. This is a critical part of the overall stability of the
Internet, so it is important that link-layer designers understand
TCP's congestion control algorithms.
TCP assumes that, at the most abstract level, the network consists of
links and queues. Queues provide output-buffering on links that are
momentarily oversubscribed. They smooth instantaneous traffic bursts
to fit the link bandwidth. When demand exceeds link capacity long
enough to fill the queue, packets must be dropped. The traditional
action of dropping the most recent packet ("tail dropping") is no
longer recommended [RFC2309] [RFC2914], but it is still widely
practiced.
TCP uses sequence numbering and acknowledgments (ACKs) on an
end-to-end basis to provide reliable, sequenced delivery. TCP ACKs
are cumulative, i.e., each implicitly ACKs every segment received so
far. If a packet with an unexpected sequence number is received, the
ACK field in the packets returned by the receiver will cease to
advance. Using an optional enhancement, TCP can send selective
acknowledgments (SACKs) [RFC2018] to indicate which segments have
arrived at the receiver.
Since the most common cause of packet loss is congestion, TCP treats
packet loss as an indication of potential Internet congestion along
the path between TCP end hosts. This happens automatically, and the
subnetwork need not know anything about IP or TCP. A subnetwork node
simply drops packets whenever it must, though some packet-dropping
strategies (e.g., RED) are more fair to competing flows than others.
TCP recovers from packet losses in two different ways. The most
important mechanism is the retransmission timeout. If an ACK fails
to arrive after a certain period of time, TCP retransmits the oldest
unacked packet. Taking this as a hint that the network is congested,
TCP waits for the retransmission to be ACKed before it continues, and
it gradually increases the number of packets in flight as long as a
timeout does not occur again.
A retransmission timeout can impose a significant performance
penalty, as the sender is idle during the timeout interval and
restarts with a congestion window of one TCP segment following the
Karn, et al. Best Current Practice [Page 20]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
timeout. To allow faster recovery from the occasional lost packet in
a bulk transfer, an alternate scheme, known as "fast recovery", was
introduced [RFC2581] [RFC2582] [RFC2914] [TCPF98].
Fast recovery relies on the fact that when a single packet is lost in
a bulk transfer, the receiver continues to return ACKs to subsequent
data packets that do not actually acknowledge any newly-received
data. These are known as "duplicate acknowledgments" or "dupacks".
The sending TCP can use dupacks as a hint that a packet has been lost
and retransmit it without waiting for a timeout. Dupacks effectively
constitute a negative acknowledgment (NAK) for the packet sequence
number in the acknowledgment field. TCP waits until a certain number
of dupacks (currently 3) are seen prior to assuming a loss has
occurred; this helps avoid an unnecessary retransmission during
out-of-sequence delivery.
A technique called "Explicit Congestion Notification" (ECN) [RFC3168]
allows routers to directly signal congestion to hosts without
dropping packets. This is done by setting a bit in the IP header.
Since ECN support is likely to remain optional, the lack of an ECN
bit must *never* be interpreted as a lack of congestion. Thus, for
the foreseeable future, TCP must interpret a lost packet as a signal
of congestion.
The TCP "congestion avoidance" [RFC2581] algorithm maintains a
congestion window (cwnd) controlling the amount of data TCP may have
in flight at any moment. Reducing cwnd reduces the overall bandwidth
obtained by the connection; similarly, raising cwnd increases
performance, up to the limit of the available capacity.
TCP probes for available network capacity by initially setting cwnd
to one or two packets and then increasing cwnd by one packet for each
ACK returned from the receiver. This is TCP's "slow start"
mechanism. When a packet loss is detected (or congestion is signaled
by other mechanisms), cwnd is reset to one and the slow start process
is repeated until cwnd reaches one half of its previous setting
before the reset. Cwnd continues to increase past this point, but at
a much slower rate than before. If no further losses occur, cwnd
will ultimately reach the window size advertised by the receiver.
This is an "Additive Increase, Multiplicative Decrease" (AIMD)
algorithm. The steep decrease of cwnd in response to congestion
provides for network stability; the AIMD algorithm also provides for
fairness between long running TCP connections sharing the same path.
Karn, et al. Best Current Practice [Page 21]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
8.5. TCP Performance Characteristics
Caveat
Here we present a current "state-of-the-art" understanding of TCP
performance. This analysis attempts to characterize the performance
of TCP connections over links of varying characteristics.
Link designers may wish to use the techniques in this section to
predict what performance TCP/IP may achieve over a new link-layer
design. Such analysis is encouraged. Because this is a relatively
new analysis, and the theory is based on single-stream TCP
connections under "ideal" conditions, it should be recognized that
the results of such analysis may differ from actual performance in
the Internet. That being said, we have done our best to provide the
designers with helpful information to get an accurate picture of the
capabilities and limitations of TCP under various conditions.
8.5.1. The Formulae
The performance of TCP's AIMD Congestion Avoidance algorithm has been
extensively analyzed. The current best formula for the performance
of the specific algorithms used by Reno TCP (i.e., the TCP specified
in [RFC2581]) is given by Padhye, et al. [PFTK98]. This formula is:
MSS
BW = --------------------------------------------------------
RTT*sqrt(1.33*p) + RTO*p*[1+32*p^2]*min[1,3*sqrt(.75*p)]
where
BW is the maximum TCP throughout achievable by an
individual TCP flow
MSS is the TCP segment size being used by the connection
RTT is the end-to-end round trip time of the TCP connection
RTO is the packet timeout (based on RTT)
p is the packet loss rate for the path
(i.e., .01 if there is 1% packet loss)
Note that the speed of the links making up the Internet path does not
explicitly appear in this formula. Attempting to send faster than
the slowest link in the path causes the queue to grow at the
transmitter driving the bottleneck. This increases the RTT, which in
turn reduces the achievable throughput.
This is currently considered to be the best approximate formula for
Reno TCP performance. A further simplification of this formula is
generally made by assuming that RTO is approximately 5*RTT.
Karn, et al. Best Current Practice [Page 22]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
TCP is constantly being improved. A simpler formula, which gives an
upper bound on the performance of any AIMD algorithm which is likely
to be implemented in TCP in the future, was derived by Ott, et al.
[MSMO97].
MSS 1
BW = C --- -------
RTT sqrt(p)
where C is 0.93.
8.5.2. Assumptions
Both formulae assume that the TCP Receiver Window is not limiting the
performance of the connection. Because the receiver window is
entirely determined by end-hosts, we assume that hosts will maximize
the announced receiver window to maximize their network performance.
Both of these formulae allow BW to become infinite if there is no
loss. However, an Internet path will drop packets at bottlenecked
queues if the load is too high. Thus, a completely lossless TCP/IP
network can never occur (unless the network is being underutilized).
The RTT used is the arithmetic average, including queuing delays.
The formulae are for a single TCP connection. If a path carries many
TCP connections, each will follow the formulae above independently.
The formulae assume long-running TCP connections. For connections
that are extremely short (<10 packets) and don't lose any packets,
performance is driven by the TCP slow-start algorithm. For
connections of medium length, where on average only a few segments
are lost, single connection performance will actually be slightly
better than given by the formulae above.
The difference between the simple and complex formulae above is that
the complex formula includes the effects of TCP retransmission
timeouts. For very low levels of packet loss (significantly less
than 1%), timeouts are unlikely to occur, and the formulae lead to
very similar results. At higher packet losses (1% and above), the
complex formula gives a more accurate estimate of performance (which
will always be significantly lower than the result from the simple
formula).
Note that these formulae break down as p approaches 100%.
Karn, et al. Best Current Practice [Page 23]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
8.5.3. Analysis of Link-Layer Effects on TCP Performance
Consider the following example:
A designer invents a new wireless link layer which, on average, loses
1% of IP packets. The link layer supports packets of up to 1040
bytes, and has a one-way delay of 20 msec.
If this link were to be used on an Internet path with a round trip
time greater than 80ms, the upper bound may be computed by:
For MSS, use 1000 bytes to exclude the 40 bytes of minimum IPv4 and
TCP headers.
For RTT, use 120 msec (80 msec for the Internet part, plus 20 msec
each way for the new wireless link).
For p, use .01. For C, assume 1.
The simple formula gives:
BW = (1000 * 8 bits) / (.120 sec * sqrt(.01)) = 666 kbit/sec
The more complex formula gives:
BW = 402.9 kbit/sec
If this were a 2 Mb/s wireless LAN, the designers might be somewhat
disappointed.
Some observations on performance:
1. We have assumed that the packet losses on the link layer are
interpreted as congestion by TCP. This is a "fact of life" that
must be accepted.
2. The equations for TCP performance are all expressed in terms of
packet loss, but many subnetwork designers think in terms of
bit-error ratio. *If* channel bit errors are independent, then
the probability of a packet being corrupted is:
p = 1 - ([1 - BER]^[FRAME_SIZE*8])
Here we assume FRAME_SIZE is in bytes and "^" represents
exponentiation. It includes the user data and all headers
(TCP,IP and subnetwork). (Note: this analysis assumes the
Karn, et al. Best Current Practice [Page 24]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
subnetwork does not perform ARQ or transparent fragmentation
[RFC3366].) If the inequality
BER * [FRAME_SIZE*8] << 1
holds, the packet loss probability p can be approximated by:
p = BER * [FRAME_SIZE*8]
These equations can be used to apply BER to the performance
equations above.
Note that FRAME_SIZE can vary from one packet to the next. Small
packets (such as TCP acks) generally have a smaller probability
of packet error than, say, a TCP packet carrying one MSS (maximum
segment size) of user data. A flow of small TCP acks can be
expected to be slightly more reliable than a stream of larger TCP
data segments.
It bears repeating that the above analysis assumes that bit
errors are statistically independent. Because this is not true
for many real links, our computation of p is actually an upper
bound, not the exact probability of packet loss.
There are many reasons why bit errors are not independent on real
links. Many radio links are affected by propagation fading or by
interference that lasts over many bit times. Also, links with
Forward Error Correction (FEC) generally have very non-uniform
bit error distributions that depend on the type of FEC, but in
general the uncorrected errors tend to occur in bursts even when
channel symbol errors are independent. In all such cases, our
computation of p from BER can only place an upper limit on the
packet loss rate.
If the distribution of errors under the FEC scheme is known, one
could apply the same type of analysis as above, using the correct
distribution function for the BER. It is more likely in these
FEC cases, however, that empirical methods are needed to
determine the actual packet loss rate.
3. Note that the packet size plays an important role. If the
subnetwork loss characteristics are such that large packets have
the same probability of loss as smaller packets, then larger
packets will yield improved performance.
Karn, et al. Best Current Practice [Page 25]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
4. We have chosen a specific RTT that might occur on a wide-area
Internet path within the USA. It is important to recognize that
a variety of RTT values are experienced in the Internet.
For example, RTTs are typically less than 10 msec in a wired LAN
environment when communicating with a local host. International
connections may have RTTs of 200 msec or more. Modems and other
low-capacity links can add considerable delay due to their long
packet transmission (serialisation) times.
Links over geostationary repeater satellites have one-way speed-
of-light delays of around 250ms, a minimum of 125ms propagation
delay up to the satellite and 125ms down. The RTT of an end-to-
end TCP connection that includes such a link can be expected to
be greater than 250ms.
Queues on heavily-congested links may back up, increasing RTTs.
Finally, virtual private networks (VPNs) and other forms of
encryption and tunneling can add significant end-to-end delay to
network connections.
9. Quality-of-Service (QoS) considerations
It is generally recognized that specific service guarantees are
needed to support real-time multimedia, toll-quality telephony, and
other performance-critical applications. The provision of such
Quality of Service guarantees in the Internet is an active area of
research and standardization. The IETF has not converged on a single
service model, set of services, or single mechanism that will offer
useful guarantees to applications and be scalable to the Internet.
Indeed, the IETF does not have a single definition of Quality of
Service. [RFC2990] represents a current understanding of the
challenges in architecting QoS for the Internet.
There are presently two architectural approaches to providing
mechanisms for QoS support in the Internet.
IP Integrated Services (Intserv) [RFC1633] provides fine-grained
service guarantees to individual flows. Flows are identified by a
flow specification (flowspec), which creates a stateful association
between individual packets by matching fields in the packet header.
Capacity is reserved for the flow, and appropriate traffic
conditioning and scheduling is installed in routers along the path.
The ReSerVation Protocol (RSVP) [RFC2205] [RFC2210] is usually, but
need not necessarily be, used to install the flow QoS state. Intserv
defines two services, in addition to the Default (best effort)
service.
Karn, et al. Best Current Practice [Page 26]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
1. Guaranteed Service (GS) [RFC2212] offers hard upper bounds on
delay to flows that conform to a traffic specification (TSpec).
It uses a fluid-flow model to relate the TSpec and reserved
bandwidth (RSpec) to variable delay. Non-conforming packets are
forwarded on a best-effort basis.
2. Controlled Load Service (CLS) [RFC2211] offers delay and packet
loss equivalent to that of an unloaded network to flows that
conform to a TSpec, but no hard bounds. Non-conforming packets
are forwarded on a best-effort basis.
Intserv requires installation of state information in every
participating router. Performance guarantees cannot be made unless
this state is present in every router along the path. This, along
with RSVP processing and the need for usage-based accounting, is
believed to have scalability problems, particularly in the core of
the Internet [RFC2208].
IP Differentiated Services (Diffserv) [RFC2475] provides a "toolkit"
offering coarse-grained controls to aggregates of flows. Diffserv in
itself does *not* provide QoS guarantees, but can be used to
construct services with QoS guarantees across a Diffserv domain.
Diffserv attempts to address the scaling issues associated with
Intserv by requiring state awareness only at the edge of a Diffserv
domain. At the edge, packets are classified into flows, and the
flows are conditioned (marked, policed, or shaped) to a traffic
conditioning specification (TCS). A Diffserv Codepoint (DSCP),
identifying a per-hop behavior (PHB), is set in each packet header.
The DSCP is carried in the DS-field, subsuming six bits of the former
Type-of-Service (ToS) byte [RFC791] of the IP header [RFC2474]. The
PHB denotes the forwarding behavior to be applied to the packet in
each node in the Diffserv domain. Although there is a "recommended"
DSCP associated with each PHB, the mappings from DSCPs to PHBs are
defined by the DS-domain. In fact, there can be several DSCPs
associated with the same PHB. Diffserv presently defines three PHBs.
1. The class selector PHB [RFC2474] replaces the IP precedence field
of the former ToS byte. It offers relative forwarding
priorities.
2. The Expedited Forwarding (EF) PHB [RFC3246] [RFC3248] guarantees
that packets will have a well-defined minimum departure rate
which, if not exceeded, ensures that the associated queues are
short or empty. EF is intended to support services that offer
tightly-bounded loss, delay, and delay jitter.
Karn, et al. Best Current Practice [Page 27]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
3. The Assured Forwarding (AF) PHB group [RFC2597] offers different
levels of forwarding assurance for each aggregated flow of
packets. Each AF group is independently allocated forwarding
resources. Packets are marked with one of three drop
precedences; those with the highest drop precedence are dropped
with lower probability than those marked with the lowest drop
precedence. DSCPs are recommended for four independent AF
groups, although a DS domain can have more or fewer AF groups.
Ongoing work in the IETF is addressing ways to support Intserv with
Diffserv. There is some belief (e.g., as expressed in [RFC2990])
that such an approach will allow individual flows to receive service
guarantees and scale to the global Internet.
The QoS guarantees that can be offered by the IP layer are a product
of two factors:
1. the concatenation of the QoS guarantees offered by the subnets
along the path of a flow. This implies that a subnet may wish to
offer multiple services (with different QoS guarantees) to the IP
layer, which can then determine which flows use which subnet
service. To put it another way, forwarding behavior in the
subnet needs to be "clued" by the forwarding behavior (service or
PHB) at the IP layer, and
2. the operation of a set of cooperating mechanisms, such as
bandwidth reservation and admission control, policy management,
traffic classification, traffic conditioning (marking, policing
and/or shaping), selective discard, queuing, and scheduling.
Note that support for QoS in subnets may require similar
mechanisms, especially when these subnets are general topology
subnets (e.g., ATM, frame relay, or MPLS) or shared media
subnets.
Many subnetwork designers face inherent tradeoffs between delay,
throughput, reliability, and cost. Other subnetworks have parameters
that manage bandwidth, internal connection state, and the like.
Therefore, the following subnetwork capabilities may be desirable,
although some might be trivial or moot if the subnet is a dedicated
point-to-point link.
1. The subnetwork should have the ability to reserve bandwidth for a
connection or flow and schedule packets accordingly.
2. Bandwidth reservations should be based on a one- or two-token
bucket model, depending on whether the service is intended to
support constant-rate or bursty traffic.
Karn, et al. Best Current Practice [Page 28]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
3. If a connection or flow does not use its reserved bandwidth at a
given time, the unused bandwidth should be available for other
flows.
4. Packets in excess of a connection or flow's agreed rate should be
forwarded as best-effort or discarded, depending on the service
offered by the subnet to the IP layer.
5. If a subnet contains error control mechanisms (retransmission
and/or FEC), it should be possible for the IP layer to influence
the inherent tradeoffs between uncorrected errors, packet losses,
and delay. These capabilities at the subnet/IP layer service
boundary correspond to selection of more or less error control
and/or to selection of particular error control mechanisms within
the subnetwork.
6. The subnet layer should know, and be able to inform the IP layer,
how much fixed delay and delay jitter it offers for a flow or
connection. If the Intserv model is used, the delay jitter
component may be best expressed in terms of the TSpec/RSpec model
described in [RFC2212].
7. Support of the Diffserv class selectors [RFC2474] suggests that
the subnet might consider mechanisms that support priorities.
10. Fairness vs Performance
Subnetwork designers should be aware of the tradeoffs between
fairness and efficiency inherent in many transmission scheduling
algorithms. For example, many local area networks use contention
protocols to resolve access to a shared transmission channel. These
protocols represent overhead. While limiting the amount of data that
a subnet node may transmit per contention cycle helps assure timely
access to the channel for each subnet node, it also increases
contention overhead per unit of data sent.
In some mobile radio networks, capacity is limited by interference,
which in turn depends on average transmitter power. Some receivers
may require considerably more transmitter power (generating more
interference and consuming more channel capacity) than others.
In each case, the scheduling algorithm designer must balance
competing objectives: providing a fair share of capacity to each
subnet node while maximizing the total capacity of the network. One
approach for balancing performance and fairness is outlined in
[ES00].
Karn, et al. Best Current Practice [Page 29]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
11. Delay Characteristics
The TCP sender bases its retransmission timeout (RTO) on measurements
of the round trip delay experienced by previous packets. This allows
TCP to adapt automatically to the very wide range of delays found on
the Internet. The recommended algorithms are described in [RFC2988].
Evaluations of TCP's retransmission timer can be found in [AP99] and
[LS00].
These algorithms model the delay along an Internet path as a
normally-distributed random variable with a slowly-varying mean and
standard deviation. TCP estimates these two parameters by
exponentially smoothing individual delay measurements, and it sets
the RTO to the estimated mean delay plus some fixed number of
standard deviations. (The algorithm actually uses mean deviation as
an approximation to standard deviation, because it is easier to
compute.)
The goal is to compute an RTO that is small enough to detect and
recover from packet losses while minimizing unnecessary ("spurious")
retransmissions when packets are unexpectedly delayed but not lost.
Although these goals conflict, the algorithm works well when the
delay variance along the Internet path is low, or the packet loss
rate is low.
If the path delay variance is high, TCP sets an RTO that is much
larger than the mean of the measured delays. If the packet loss rate
is low, the large RTO is of little consequence, as timeouts occur
only rarely. Conversely, if the path delay variance is low, then TCP
recovers quickly from lost packets; again, the algorithm works well.
However, when delay variance and the packet loss rate are both high,
these algorithms perform poorly, especially when the mean delay is
also high.
Because TCP uses returning acknowledgments as a "clock" to time the
transmission of additional data, excessively high delays (even if the
delay variance is low) also affect TCP's ability to fully utilize a
high-speed transmission pipe. It also slows the recovery of lost
packets, even when delay variance is small.
Subnetwork designers should therefore minimize all three parameters
(delay, delay variance, and packet loss) as much as possible.
In many subnetworks, these parameters are inherently in conflict.
For example, on a mobile radio channel, the subnetwork designer can
use retransmission (ARQ) and/or forward error correction (FEC) to
trade off delay, delay variance, and packet loss in an effort to
improve TCP performance. While ARQ increases delay variance, FEC
Karn, et al. Best Current Practice [Page 30]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
does not. However, FEC (especially when combined with interleaving)
often increases mean delay, even on good channels where ARQ
retransmissions are not needed and ARQ would not increase either the
delay or the delay variance.
The tradeoffs among these error control mechanisms and their
interactions with TCP can be quite complex, and are the subject of
much ongoing research. We therefore recommend that subnetwork
designers provide as much flexibility as possible in the
implementation of these mechanisms, and provide access to them as
discussed above in the section on Quality of Service.
12. Bandwidth Asymmetries
Some subnetworks may provide asymmetric bandwidth (or may cause TCP
packet flows to experience asymmetry in the capacity) and the
Internet protocol suite will generally still work fine. However,
there is a case when such a scenario reduces TCP performance. Since
TCP data segments are "clocked" out by returning acknowledgments, TCP
senders are limited by the rate at which ACKs can be returned
[BPK98]. Therefore, when the ratio of the available capacity of the
Internet path carrying the data to the bandwidth of the return path
of the acknowledgments is too large, the slow return of the ACKs
directly impacts performance. Since ACKs are generally smaller than
data segments, TCP can tolerate some asymmetry, but as a general
rule, designers of subnetworks should be aware that subnetworks with
significant asymmetry can result in reduced performance, unless
issues are taken to mitigate this [RFC3449].
Several strategies have been identified for reducing the impact of
asymmetry of the network path between two TCP end hosts, e.g.,
[RFC3449]. These techniques attempt to reduce the number of ACKs
transmitted over the return path (low bandwidth channel) by changes
at the end host(s), and/or by modification of subnetwork packet
forwarding. While these solutions may mitigate the performance
issues caused by asymmetric subnetworks, they do have associated cost
and may have other implications. A fuller discussion of strategies
and their implications is provided in [RFC3449].
13. Buffering, flow and congestion control
Many subnets include multiple links with varying traffic demands and
possibly different transmission speeds. At each link there must be a
queuing system, including buffering, scheduling, and a capability to
discard excess subnet packets. These queues may also be part of a
subnet flow control or congestion control scheme.
Karn, et al. Best Current Practice [Page 31]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
For the purpose of this discussion, we talk about packets without
regard to whether they refer to a complete IP packet or a subnetwork
frame. At each queue, a packet experiences a delay that depends on
competing traffic and the scheduling discipline, and is subjected to
a local discarding policy.
Some subnets may have flow or congestion control mechanisms in
addition to packet dropping. Such mechanisms can operate on
components in the subnet layer, such as schedulers, shapers, or
discarders, and can affect the operation of IP forwarders at the
edges of the subnet. However, with the exception of Explicit
Congestion Notification [RFC3168] (discussed below), IP has no way to
pass explicit congestion or flow control signals to TCP.
TCP traffic, especially aggregated TCP traffic, is bursty. As a
result, instantaneous queue depths can vary dramatically, even in
nominally stable networks. For optimal performance, packets should
be dropped in a controlled fashion, not just when buffer space is
unavailable. How much buffer space should be supplied is still a
matter of debate, but as a rule of thumb, each node should have
enough buffering to hold one link_bandwidth*link_delay product's
worth of data for each TCP connection sharing the link.
This is often difficult to estimate, since it depends on parameters
beyond the subnetwork's control or knowledge. Internet nodes
generally do not implement admission control policies, and cannot
limit the number of TCP connections that use them. In general, it is
wise to err in favor of too much buffering rather than too little.
It may also be useful for subnets to incorporate mechanisms that
measure propagation delays to assist in buffer sizing calculations.
There is a rough consensus in the research community that active
queue management is important to improving fairness, link
utilization, and throughput [RFC2309]. Although there are questions
and concerns about the effectiveness of active queue management
(e.g., [MBDL99]), it is widely considered an improvement over tail-
drop discard policies.
One form of active queue management is the Random Early Detection
(RED) algorithm [RED93], a family of related algorithms. In one
version of RED, an exponentially-weighted moving average of the queue
depth is maintained:
When this average queue depth is between a maximum threshold
max_th and a minimum threshold min_th, the probability of packets
that are dropped is proportional to the amount by which the
average queue depth exceeds min_th.
Karn, et al. Best Current Practice [Page 32]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
When this average queue depth is equal to max_th, the drop
probability is equal to a configurable parameter max_p.
When this average queue depth is greater than max_th, packets are
always dropped.
Numerous variants on RED appear in the literature, and there are
other active queue management algorithms which claim various
advantages over RED [GM02].
With an active queue management algorithm, dropped packets become a
feedback signal to trigger more appropriate congestion behavior by
the TCPs in the end hosts. Randomization of dropping tends to break
up the observed tendency of TCP windows belonging to different TCP
connections to become synchronized by correlated drops, and it also
imposes a degree of fairness on those connections that implement TCP
congestion avoidance properly. Another important property of active
queue management algorithms is that they attempt to keep average
queue depths short while accommodating large short-term bursts.
Since TCP neither knows nor cares whether congestive packet loss
occurs at the IP layer or in a subnet, it may be advisable for
subnets that perform queuing and discarding to consider implementing
some form of active queue management. This is especially true if
large aggregates of TCP connections are likely to share the same
queue. However, active queue management may be less effective in the
case of many queues carrying smaller aggregates of TCP connections,
e.g., in an ATM switch that implements per-VC queuing.
Note that the performance of active queue management algorithms is
highly sensitive to settings of configurable parameters, and also to
factors such as RTT [MBB00] [FB00].
Some subnets, most notably ATM, perform segmentation and reassembly
at the subnetwork edges. Care should be taken here in designing
discard policies. If the subnet discards a fragment of an IP packet,
then the remaining fragments become an unproductive load on the
subnet that can markedly degrade end-to-end performance [RF95].
Subnetworks should therefore attempt to discard these extra fragments
whenever one of them must be discarded. If the IP packet has already
been partially forwarded when discarding becomes necessary, then
every remaining fragment except the one marking the end of the IP
packet should also be discarded. For ATM subnets, this specifically
means using Early Packet Discard and Partial Packet Discard [ATMFTM].
Some subnets include flow control mechanisms that effectively require
that the rate of traffic flows be shaped upon entry to the subnet.
One example of such a subnet mechanism is in the ATM Available Bit
Karn, et al. Best Current Practice [Page 33]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
rate (ABR) service category [ATMFTM]. Such flow control mechanisms
have the effect of making the subnet nearly lossless by pushing
congestion into the IP routers at the edges of the subnet. In such a
case, adequate buffering and discard policies are needed in these
routers to deal with a subnet that appears to have varying bandwidth.
Whether there is a benefit in this kind of flow control is
controversial; there are numerous simulation and analytical studies
that go both ways. It appears that some of the issues leading to
such different results include sensitivity to ABR parameters, use of
binary rather than explicit rate feedback, use (or not) of per-VC
queuing, and the specific ATM switch algorithms selected for the
study. Anecdotally, some large networks that used IP over ABR to
carry TCP traffic have claimed it to be successful, but have
published no results.
Another possible approach to flow control in the subnet would be to
work with TCP Explicit Congestion Notification (ECN) semantics
[RFC3168] through utilizing explicit congestion indicators in subnet
frames. Routers at the edges of the subnet, rather than shaping,
would set the explicit congestion bit in those IP packets that are
received in subnet frames that have an ECN indication. Nodes in the
subnet would need to implement an active queue management protocol
that marks subnet frames instead of dropping them.
ECN is currently a proposed standard, but it is not yet widely
deployed.
14. Compression
Application data compression is a function that can usually be
omitted in the subnetwork. The endpoints typically have more CPU and
memory resources to run a compression algorithm and a better
understanding of what is being compressed. End-to-end compression
benefits every network element in the path, while subnetwork-layer
compression, by definition, benefits only a single subnetwork.
Data presented to the subnetwork layer may already be in a compressed
format (e.g., a JPEG file), compressed at the application layer
(e.g., the optional "gzip", "compress", and "deflate" compression in
HTTP/1.1 [RFC2616]), or compressed at the IP layer (the IP Payload
Compression Protocol [RFC3173] supports DEFLATE [RFC2394] and LZS
[RFC2395]). Compression at the subnetwork edges is of no benefit for
any of these cases.
The subnetwork may also process data that has been encrypted by the
application (OpenPGP [RFC2440] or S/MIME [RFC2633]), just above TCP
(SSL, TLS [RFC2246]), or just above IP (IPsec ESP [RFC2406]).
Karn, et al. Best Current Practice [Page 34]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Ciphers generate high-entropy bit streams lacking any patterns that
can be exploited by a compression algorithm.
However, much data is still transmitted uncompressed over the
Internet, so subnetwork compression may be beneficial. Any
subnetwork compression algorithm must not expand uncompressible data,
e.g., data that has already been compressed or encrypted.
We make a strong recommendation that subnetworks operating at low
speed or with small MTUs compress IP and transport-level headers (TCP
and UDP) using several header compression schemes developed within
the IETF [RFC3150]. An uncompressed 40-byte TCP/IP header takes
about 33 milliseconds to send at 9600 bps. "VJ" TCP/IP header
compression [RFC1144] compresses most headers to 3-5 bytes, reducing
transmission time to several milliseconds on dialup modem links.
This is especially beneficial for small, latency-sensitive packets in
interactive sessions.
Similarly, RTP compression schemes, such as CRTP [RFC2508] and ROHC
[RFC3095], compress most IP/UDP/RTP headers to 1-4 bytes. The
resulting savings are especially significant when audio packets are
kept small to minimize store-and-forward latency.
Designers should consider the effect of the subnetwork error rate on
the performance of header compression. TCP ordinarily recovers from
lost packets by retransmitting only those packets that were actually
lost; packets arriving correctly after a packet loss are kept on a
resequencing queue and do not need to be retransmitted. In VJ TCP/IP
[RFC1144] header compression, however, the receiver cannot explicitly
notify a sender of data corruption and subsequent loss of
synchronization between compressor and decompressor. It relies
instead on TCP retransmission to re-synchronize the decompressor.
After a packet is lost, the decompressor must discard every
subsequent packet, even if the subnetwork makes no further errors,
until the sending TCP retransmits to re-synchronize the decompressor.
This effect can substantially magnify the effect of subnetwork packet
losses if the sending TCP window is large, as it will often be on a
path with a large bandwidth*delay product [LRKOJ99].
Alternate header compression schemes, such as those described in
[RFC2507], include an explicit request for retransmission of an
uncompressed packet to allow decompressor resynchronization without
waiting for a TCP retransmission. However, these schemes are not yet
in widespread use.
Both TCP header compression schemes do not compress widely-used TCP
options such as selective acknowledgements (SACK). Both fail to
compress TCP traffic that makes use of explicit congestion
Karn, et al. Best Current Practice [Page 35]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
notification (ECN). Work is under way in the IETF ROHC WG to address
these shortcomings in a ROHC header compression scheme for TCP
[RFC3095] [RFC3096].
The subnetwork error rate also is important for RTP header
compression. CRTP uses delta encoding, so a packet loss on the link
causes uncertainty about the subsequent packets, which often must be
discarded until the decompressor has notified the compressor and the
compressor has sent re-synchronizing information. This typically
takes slightly more than the end-to-end path round-trip time. For
links that combine significant error rates with latencies that
require multiple packets to be in flight at a time, this leads to
significant error propagation, i.e., subsequent losses caused by an
initial loss.
For links that are both high-latency (multiple packets in flight from
a typical RTP stream) and error-prone, RTP ROHC provides a more
robust way of RTP header compression, at a cost of higher complexity
at the compressor and decompressor. For example, within a talk
spurt, only extended losses of (depending on the mode chosen) 12-64
packets typically cause error propagation.
15. Packet Reordering
The Internet architecture does not guarantee that packets will arrive
in the same order in which they were originally transmitted;
transport protocols like TCP must take this into account.
However, reordering does come at a cost with TCP as it is currently
defined. Because TCP returns a cumulative acknowledgment (ACK)
indicating the last in-order segment that has arrived, out-of-order
segments cause a TCP receiver to transmit a duplicate acknowledgment.
When the TCP sender notices three duplicate acknowledgments, it
assumes that a segment was dropped by the network and uses the fast
retransmit algorithm [Jac90] [RFC2581] to resend the segment. In
addition, the congestion window is reduced by half, effectively
halving TCP's sending rate. If a subnetwork reorders segments
significantly such that three duplicate ACKs are generated, the TCP
sender needlessly reduces the congestion window and performance
suffers.
Packet reordering frequently occurs in parts of the Internet, and it
seems to be difficult or impossible to eliminate [BPS99]. For this
reason, research on improving TCP's behavior in the face of packet
reordering [LK00] [BA02] has begun.
Karn, et al. Best Current Practice [Page 36]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[BPS99] cites reasons why it may even be undesirable to eliminate
reordering. There are situations where average packet latency can be
reduced, link efficiency can be increased, and/or reliability can be
improved if reordering is permitted. Examples include certain high
speed switches within the Internet backbone and the parallel links
used over many Internet paths for load splitting and redundancy.
This suggests that subnetwork implementers should try to avoid packet
reordering whenever possible, but not if doing so compromises
efficiency, impairs reliability, or increases average packet delay.
Note that every header compression scheme currently standardized for
the Internet requires in-order packet delivery on the link between
compressor and decompressor. PPP is frequently used to carry
compressed TCP/IP packets; since it was originally designed for
point-to-point and dialup links, it is assumed to provide in-order
delivery. For this reason, subnetwork implementers who provide PPP
interfaces to VPNs and other more complex subnetworks, must also
maintain in-order delivery of PPP frames.
16. Mobility
Internet users are increasingly mobile. Not only are many Internet
nodes laptop computers, but pocket organizers and mobile embedded
systems are also becoming nodes on the Internet. These nodes may
connect to many different access points on the Internet over time,
and they expect this to be largely transparent to their activities.
Except when they are not connected to the Internet at all, and for
performance differences when they are connected, they expect that
everything will "just work" regardless of their current Internet
attachment point or local subnetwork technology.
Changing a host's Internet attachment point involves one or more of
the following steps.
First, if use of the local subnetwork is restricted, the user's
credentials must be verified and access granted. There are many ways
to do this. A trivial example would be an "Internet cafe" that
grants physical access to the subnetwork for a fee. Subnetworks may
implement technical access controls of their own; one example is IEEE
802.11 Wireless Equivalent Privacy [IEEE80211]. It is common
practice for both cellular telephone and Internet service providers
(ISPs) to agree to serve one anothers' users; RADIUS [RFC2865] is the
standard method for ISPs to exchange authorization information.
Second, the host may have to be reconfigured with IP parameters
appropriate for the local subnetwork. This usually includes setting
an IP address, default router, and domain name system (DNS) servers.
Karn, et al. Best Current Practice [Page 37]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
On multiple-access networks, the Dynamic Host Configuration Protocol
(DHCP) [RFC2131] is almost universally used for this purpose. On PPP
links, these functions are performed by the IP Control Protocol
(IPCP) [RFC1332].
Third, traffic destined for the mobile host must be routed to its
current location. This roaming function is the most common meaning
of the term "Internet mobility".
Internet mobility can be provided at any of several layers in the
Internet protocol stack, and there is ongoing debate as to which is
the most appropriate and efficient. Mobility is already a feature of
certain application layer protocols; the Post Office Protocol (POP)
[RFC1939] and the Internet Message Access Protocol (IMAP) [RFC3501]
were created specifically to provide mobility in the receipt of
electronic mail.
Mobility can also be provided at the IP layer [RFC3344]. This
mechanism provides greater transparency, viz., IP addresses that
remain fixed as the nodes move, but at the cost of potentially
significant network overhead and increased delay because of the sub-
optimal network routing and tunneling involved.
Some subnetworks may provide internal mobility, transparent to IP, as
a feature of their own internal routing mechanisms. To the extent
that these simplify routing at the IP layer, reduce the need for
mechanisms like Mobile IP, or exploit mechanisms unique to the
subnetwork, this is generally desirable. This is especially true
when the subnetwork covers a relatively small geographic area and the
users move rapidly between the attachment points within that area.
Examples of internal mobility schemes include Ethernet switching and
intra-system handoff in cellular telephony.
However, if the subnetwork is physically large and connects to other
parts of the Internet at multiple geographic points, care should be
taken to optimize the wide-area routing of packets between nodes on
the external Internet and nodes on the subnet. This is generally
done with "nearest exit" routing strategies. Because a given
subnetwork may be unaware of the actual physical location of a
destination on another subnetwork, it simply routes packets bound for
the other subnetwork to the nearest router between the two. This
implies some awareness of IP addressing and routing within the
subnetwork. The subnetwork may wish to use IP routing internally for
wide area routing and restrict subnetwork-specific routing to
constrained geographic areas where the effects of suboptimal routing
are minimized.
Karn, et al. Best Current Practice [Page 38]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
17. Routing
Subnetworks connecting more than two systems must provide their own
internal Layer-2 forwarding mechanisms, either implicitly (e.g.,
broadcast) or explicitly (e.g., switched). Since routing is the
major function of the Internet layer, the question naturally arises
as to the interaction between routing at the Internet layer and
routing in the subnet, and proper division of function between the
two.
Layer-2 subnetworks can be point-to-point, connecting two systems, or
multipoint. Multipoint subnetworks can be broadcast (e.g., shared
media or emulated) or non-broadcast. Generally, IP considers
multipoint subnetworks as broadcast, with shared-medium Ethernet as
the canonical (and historical) example, and point-to-point
subnetworks as a degenerate case. Non-broadcast subnetworks may
require additional mechanisms, e.g., above IP at the routing layer
[RFC2328].
IP is ignorant of the topology of the subnetwork layer. In
particular, reconfiguration of subnetwork paths is not tracked by the
IP layer. IP is only affected by whether it can send/receive packets
sent to the remotely connected systems via the subnetwork interface
(i.e., the reachability from one router to another). IP further
considers that subnetworks are largely static -- that both their
membership and existence are stable at routing timescales (tens of
seconds); changes to these are considered re-provisioning, rather
than routing.
Routing functionality in a subnetwork is related to addressing in
that subnetwork. Resolution of addresses on subnetwork links is
required for forwarding IP packets across links (e.g., ARP for IPv4,
or ND for IPv6). There is unlikely to be direct interaction between
subnetwork routing and IP routing. Where broadcast is provided or
explicitly emulated, address resolution can be used directly; where
not provided, the link layer routing may interface to a protocol for
resolution, e.g., to the Next-Hop Resolution Protocol [RFC2322] to
provide context-dependent address resolution capabilities.
Subnetwork routing can either complement or compete with IP routing.
It complements IP when a subnetwork encapsulates its internal
routing, and where the effects of that routing are not visible at the
IP layer. However, if different paths in the subnetwork have
characteristics that affect IP routing, it can affect or even inhibit
the convergence of IP routing.
Karn, et al. Best Current Practice [Page 39]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Routing protocols generally consider Layer-2 subnetworks, i.e., with
subnet masks and no intermediate IP hops, to have uniform routing
metrics to all members. Routing can break when a link's
characteristics do not match the routing metric, in this case, e.g.,
when some member pairs have different path characteristics. Consider
a virtual Ethernet subnetwork that includes both nearby (sub-
millisecond latency) and remote (100's of milliseconds away) systems.
Presenting that group as a single subnetwork means that some routing
protocols will assume that all pairs have the same delay, and that
that delay is small. Because this is not the case, the routing
tables constructed may be suboptimal or may even fail to converge.
When a subnetwork is used for transit between a set of routers, it
conventionally provides the equivalent of a full mesh of point-to-
point links. Simplicity of the internal subnet structure can be used
(e.g., via NHRP [RFC2332]) to reduce the size of address resolution
tables, but routing exchanges will continue to reflect the full mesh
they emulate. In general, subnetworks should not be used as a
transit among a set of routers where routing protocols would break if
a full mesh of equivalent point-to-point links were used.
Some subnetworks have special features that allow the use of more
effective or responsive routing mechanisms that cannot be implemented
in IP because of its need for generality. One example is the self-
learning bridge algorithm widely used in Ethernet networks. Learning
bridges perform Layer-2 subnetwork forwarding, avoiding the need for
dynamic routing at each subnetwork hop. Another is the "handoff"
mechanism in cellular telephone networks, particularly the "soft
handoff" scheme in IS-95 CDMA.
Subnetworks that cover large geographic areas or include links of
widely-varying capabilities should be avoided. IP routing generally
considers all multipoint subnets equivalent to a local, shared-medium
link with uniform metrics between any pair of systems, and ignores
internal subnetwork topology. Where a subnetwork diverges from that
assumption, it is the obligation of subnetwork designers to provide
compensating mechanisms. Not doing so can affect the scalability and
convergence of IP routing, as noted above.
The subnetwork designer who decides to implement internal routing
should consider whether a custom routing algorithm is warranted, or
if an existing Internet routing algorithm or protocol may suffice.
The designer should consider whether this decision is to reduce the
address resolution table size (possible, but with additional protocol
support required), or is trying to reduce routing table complexity.
The latter may be better achieved by partitioning the subnetwork,
either physically or logically, and using network-layer protocols to
support partitioning (e.g., AS's in BGP). Protocols and routing
Karn, et al. Best Current Practice [Page 40]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
algorithms can be notoriously subtle, complex, and difficult to
implement correctly. Much work can be avoided if existing protocols
or implementations can be readily reused.
18. Security Considerations
Security has become a high priority in the design and operation of
the Internet. The Internet is vast, and countless organizations and
individuals own and operate its various components. A consensus has
emerged for what might be called a "security placement principle": a
security mechanism is most effective when it is placed as close as
possible to, and under the direct control of the owner of the asset
that it protects.
A corollary of this principle is that end-to-end security (e.g.,
confidentiality, authentication, integrity, and access control)
cannot be ensured with subnetwork security mechanisms. Not only are
end-to-end security mechanisms much more closely associated with the
end-user assets they protect, they are also much more comprehensive.
For example, end-to-end security mechanisms cover gaps that can
appear when otherwise good subnetwork mechanisms are concatenated.
This is an important application of the end-to-end principle [SRC81].
Several security mechanisms that can be used end-to-end have already
been deployed in the Internet and are enjoying increasing use. The
most important are the Secure Sockets Layer (SSL) [SSL2] [SSL3] and
TLS [RFC2246] primarily used to protect web commerce, Pretty Good
Privacy (PGP) [RFC1991] and S/MIME [RFCs-2630-2634], primarily used
to protect and authenticate email and software distributions, the
Secure Shell (SSH), used for secure remote access and file transfer,
and IPsec [RFC2401], a general purpose encryption and authentication
mechanism that sits just above IP and can be used by any IP
application. (IPsec can actually be used either on an end-to-end
basis or between security gateways that do not include either or both
end systems.)
Nonetheless, end-to-end security mechanisms are not used as widely as
might be desired. However, the group could not reach consensus on
whether subnetwork designers should be actively encouraged to
implement mechanisms to protect user data.
The clear consensus of the working group held that subnetwork
security mechanisms, especially when weak or incorrectly implemented
[BGW01], may actually be counterproductive. The argument is that
subnetwork security mechanisms can lull end users into a false sense
of security, diminish the incentive to deploy effective end-to-end
Karn, et al. Best Current Practice [Page 41]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
mechanisms, and encourage "risky" uses of the Internet that would not
be made if users understood the inherent limits of subnetwork
security mechanisms.
The other point of view encourages subnetwork security on the
principle that it is better than the default situation, which all too
often is no security at all. Users of especially vulnerable subnets
(such as consumers who have wireless home networks and/or shared
media Internet access) often have control over at most one endpoint
-- usually a client -- and therefore cannot enforce the use of end-
to-end mechanisms. However, subnet security can be entirely adequate
for protecting low-valued assets against the most likely threats. In
any event, subnet mechanisms do not preclude the use of end-to-end
mechanisms, which are typically used to protect highly-valued assets.
This viewpoint recognizes that many security policies implicitly
assume that the entire end-to-end path is composed of a series of
concatenated links that are nominally physically secured. That is,
these policies assume that all endpoints of all links are trusted,
and that access to the physical medium by attackers is difficult. To
meet the assumptions of such policies, explicit mechanisms are needed
for links (especially shared medium links) that lack physical
protection. This, for example, is the rationale that underlies Wired
Equivalent Privacy (WEP) in the IEEE 802.11 [IEEE80211] wireless LAN
standard, and the Baseline Privacy Interface in the DOCSIS [DOCSIS1]
[DOCSIS2] data over cable television networks standards.
We therefore recommend that subnetwork designers who choose to
implement security mechanisms to protect user data be as candid as
possible with the details of such security mechanisms and the
inherent limits of even the most secure mechanisms when implemented
in a subnetwork rather than on an end-to-end basis.
In keeping with the "placement principle", a clear consensus exists
for another subnetwork security role: the protection of the
subnetwork itself. Possible threats to subnetwork assets include
theft of service and denial of service; shared media subnets tend to
be especially vulnerable to such attacks. In some cases, mechanisms
that protect subnet assets can also improve (but cannot ensure) end-
to-end security.
One security service can be provided by the subnetwork that will aid
in the solution of an overall Internet problem: subnetwork security
should provide a mechanism to authenticate the source of a subnetwork
frame. This function is missing in some current protocols, e.g., the
use of ARP [RFC826] to associate an IPv4 address with a MAC address.
The IPv6 Neighbor Discovery (ND) [RFC2461] performs a similar
function.
Karn, et al. Best Current Practice [Page 42]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
There are well-known security flaws with this address resolution
mechanism [Wilbur89]. However, the inclusion of subnetwork frame
source authentication will permit a secure subnetwork address.
Another potential role for subnetwork security is to protect users
against traffic analysis, i.e., identifying the communicating parties
and determining their communication patterns and volumes even when
their actual contents are protected by strong end-to-end security
mechanisms. Lower-layer security can be more effective against
traffic analysis due to its inherent ability to aggregate the
communications of multiple parties sharing the same physical
facilities while obscuring higher-layer protocol information that
indicates specific end points, such as IP addresses and TCP/UDP port
numbers.
However, traffic analysis is a notoriously subtle and difficult
threat to understand and defeat, far more so than threats to
confidentiality and integrity. We therefore urge extreme care in the
design of subnetwork security mechanisms specifically intended to
thwart traffic analysis.
Subnetwork designers must keep in mind that design and implementation
for security is difficult [Schneier00]. [Schneier95] describes
protocols and algorithms which are considered well-understood and
believed to be sound.
Poor design process, subtle design errors and flawed implementation
can result in gaping vulnerabilities. In recent years, a number of
subnet standards have had problems exposed. The following are
examples of mistakes that have been made:
1. Use of weak and untested algorithms [Crypto9912] [BGW01]. For a
variety of reasons, algorithms were chosen which had subtle
flaws, making them vulnerable to a variety of attacks.
2. Use of "security by obscurity" [Schneier00] [Crypto9912]. One
common mistake is to assume that keeping cryptographic algorithms
secret makes them more secure. This is intuitive, but wrong.
Full public disclosure early in the design process attracts peer
review by knowledgeable cryptographers. Exposure of flaws by
this review far outweighs any imagined benefit from forcing
attackers to reverse engineer security algorithms.
3. Inclusion of trapdoors [Schneier00] [Crypto9912]. Trapdoors are
flaws surreptitiously left in an algorithm to allow it to be
broken. This might be done to recover lost keys or to permit
surreptitious access by governmental agencies. Trapdoors can be
discovered and exploited by malicious attackers.
Karn, et al. Best Current Practice [Page 43]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
4. Sending passwords or other identifying information as clear text.
For many years, analog cellular telephones could be cloned and
used to steal service. The cloners merely eavesdropped on the
registration protocols that exchanged everything in clear text.
5. Keys which are common to all systems on a subnet [BGW01].
6. Incorrect use of a sound mechanism. For example [BGW01], one
subnet standard includes an initialization vector which is poorly
designed and poorly specified. A determined attacker can easily
recover multiple ciphertexts encrypted with the same key stream
and perform statistical attacks to decipher them.
7. Identifying information sent in clear text that can be resolved
to an individual, identifiable device. This creates a
vulnerability to attacks targeted to that device (or its owner).
8. Inability to renew and revoke shared secret information.
9. Insufficient key length.
10. Failure to address "man-in-the-middle" attacks, e.g., with mutual
authentication.
11. Failure to provide a form of replay detection, e.g., to prevent a
receiver from accepting packets from an attacker that simply
resends previously captured network traffic.
12. Failure to provide integrity mechanisms when providing
confidentiality schemes [Bel98].
This list is by no means comprehensive. Design problems are
difficult to avoid, but expert review is generally invaluable in
avoiding problems.
In addition, well-designed security protocols can be compromised by
implementation defects. Examples of such defects include use of
predictable pseudo-random numbers [RFC1750], vulnerability to buffer
overflow attacks due to unsafe use of certain I/O system calls
[WFBA2000], and inadvertent exposure of secret data.
19. Contributors
This document represents a consensus of the members of the IETF
Performance Implications of Link Characteristics (PILC) working
group.
Karn, et al. Best Current Practice [Page 44]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
This document would not have been possible without the contributions
of a great number of people in the Performance Implications of Link
Characteristics Working Group. In particular, the following people
provided major contributions of text, editing, and advice on this
document: Mark Allman provided the final editing to complete this
document. Carsten Bormann provided text on robust header
compression. Gorry Fairhurst provided text on broadcast and
multicast issues, routing, and many valuable comments on the entire
document. Aaron Falk provided text on bandwidth on demand. Dan
Grossman provided text on many facets of the document. Reiner Ludwig
provided thorough document review and text on TCP vs. Link-Layer
Retransmission. Jamshid Mahdavi provided text on TCP performance
calculations. Saverio Mascolo provided feedback on the document.
Gabriel Montenegro provided feedback on the document. Marie-Jose
Montpetit provided text on bandwidth on demand. Joe Touch provided
text on multicast, broadcast, and routing, and Lloyd Wood provided
many valuable comments on versions of the document.
20. Informative References
References of the form RFCnnnn are Internet Request for Comments
(RFC) documents available online at www.rfc-editor.org.
[802.1D] Information Technology Telecommunications and
information exchange between systems Local and
metropolitan area networks, Common specifications Media
access control (MAC) bridges, IEEE 802.1D, 1998. ISO
15802-3.
[802.1p] IEEE, 802.1p, Standard for Local and Metropolitan Area
Networks - Supplement to Media Access Control (MAC)
Bridges: Traffic Class Expediting and Multicast.
[AP99] Allman, M. and V. Paxson, On Estimating End-to-End
Network Path Properties, In Proceedings of ACM SIGCOMM
99.
[AR02] Acar, G. and C. Rosenberg, Weighted Fair Bandwidth-on-
Demand (WFBoD) for Geo-Stationary Satellite Networks
with On-Board Processing, Computer Networks, 39(1),
2002.
[ATMFTM] The ATM Forum, "Traffic Management Specification,
Version 4.0", April 1996, document af-tm-0056.000.
http://www.atmforum.com/
Karn, et al. Best Current Practice [Page 45]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[BA02] Blanton, E. and M. Allman, On Making TCP More Robust to
Packet Reordering. ACM Computer Communication Review,
32(1), January 2002.
[Bel98] Bellovin, S., "Cryptography and the Internet", in
Proceedings of CRYPTO '98, August 1998.
http://www.research.att.com/~smb/papers/inet-crypto.pdf
[BGW01] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting
Mobile Communications: The Insecurity of 802.11," In
Proceedings of ACM MobiCom, July 2001.
[BPK98] Balakrishnan, H., Padmanabhan, V. and R. Katz. "The
Effects of Asymmetry on TCP Performance." ACM Mobile
Networks and Applications (MONET), 1998.
[BPS99] Bennet,, J.C.R., Partridge, C. and N. Shectman, "Packet
Reordering is Not Pathological Network Behavior",
IEEE/ACM Transactions on Networking, Vol. 7, No. 6,
December 1999.
[CGMP] Farinacci D., Tweedly A. and T. Speakman, "Cisco Group
Management Protocol (CGMP)", 1996/1997.
ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt
[Crypto9912] Schneier, B., "European Cellular Encryption Algorithms"
Crypto-Gram, December 15, 1999.
http://www.counterpane.com
[DIX82] Digital Equipment Corp, Intel Corp, Xerox Corp,
Ethernet Local Area Network Specification Version 2.0,
November 1982.
[DOCSIS1] Data-Over-Cable Service Interface Specifications, Radio
Frequency Interface Specification 1.0, SP-RFI-I05-
991105, November 1999, Cable Television Laboratories,
Inc.
[DOCSIS2] Data-Over-Cable Service Interface Specifications, Radio
Frequency Interface Specification 1.1, SP-RFIv1.1-I05-
000714, July 2000, Cable Television Laboratories, Inc.
[DOCSIS3] Lai, W.S., "DOCSIS-Based Cable Networks: Impact of
Large Data Packets on Upstream Capacity", 14th ITC
Specialists Seminar on Access Networks and Systems,
Barcelona, Spain, April 25-27, 2001.
Karn, et al. Best Current Practice [Page 46]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[EN301192] ETSI, European Broadcasting Union, Digital Video
Broadcasting (DVB); DVB Specification for Data
Broadcasting, European Standard (Telecommunications
Series) EN 301 192 v1.2.1(1999-06).
[ES00] Eckhardt, D. and P. Steenkiste, "Effort-limited Fair
(ELF) Scheduling for Wireless Networks, Proceedings of
IEEE Infocom 2000.
[FB00] Firoiu V. and M. Borden, "A Study of Active Queue
Management for Congestion Control" to appear in Infocom
2000.
[GM02] Grieco1, L. and S. Mascolo, "TCP Westwood and Easy RED
to Improve Fairness in High-Speed Networks",
Proceedings of the 7th International Workshop on
Protocols for High-Speed Networks, April 2002.
[IEEE8023] IEEE 802.3 CSMA/CD Access Method.
http://standards.ieee.org/
[IEEE80211] IEEE 802.11 Wireless LAN standard.
http://standards.ieee.org/
[ISO3309] ISO/IEC 3309:1991(E), "Information Technology -
Telecommunications and information exchange between
systems - High-level data link control (HDLC)
procedures - Frame structure", International
Organization For Standardization, Fourth edition 1991-
06-01.
[ISO13818] ISO/IEC, ISO/IEC 13818-1:2000(E) Information
Technology - Generic coding of moving pictures and
associated audio information: Systems, Second edition,
2000-12-01 International Organization for
Standardization and International Electrotechnical
Commission.
[ITU-I363] ITU-T I.363.5 B-ISDN ATM Adaptation Layer Specification
Type AAL5, International Standards Organisation (ISO),
1996.
[Jac90] Jacobson, V., Modified TCP Congestion Avoidance
Algorithm. Email to the end2end-interest mailing list,
April 1990.
ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt
Karn, et al. Best Current Practice [Page 47]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[KY02] Khafizov, F. and M. Yavuz, Running TCP Over IS-2000,
Proceedings of IEEE ICC, 2002.
[LK00] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making
TCP Robust Against Spurious Retransmissions", ACM
Computer Communication Review, Vol. 30, No. 1, January
2000.
[LKJK02] Ludwig, R., Konrad, A., Joseph, A. D. and R. H. Katz,
"Optimizing the End-to-End Performance of Reliable
Flows over Wireless Links", Kluwer/ACM Wireless
Networks Journal, Vol. 8, Nos. 2/3, pp. 289-299,
March-May 2002.
[LRKOJ99] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K. and A.
Joseph, Multi-Layer Tracing of TCP over a Reliable
Wireless Link, pp. 144-154, In Proceedings of ACM
SIGMETRICS 99.
[LS00] Ludwig, R. and K. Sklower, The Eifel Retransmission
Timer, ACM Computer Communication Review, Vol. 30, No.
3, July 2000.
[MAGMA-PROXY] Fenner, B., He, H., Haberman, B. and H. Sandick,
"IGMP/MLD-based Multicast Forwarding ("IGMP/MLD
Proxying")", Work in Progress.
[MAGMA-SNOOP] Christensen, M., Kimball, K. and F. Solensky,
"Considerations for IGMP and MLD Snooping Switches",
Work in Progress.
[MBB00] May, M., Bonald, T. and J-C. Bolot, "Analytic
Evaluation of RED Performance", INFOCOM 2000.
[MBDL99] May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not
to deploy RED", Proc. of 7th. International Workshop on
Quality of Service (IWQoS'99), June 1999.
[MSMO97] Mathis, M., Semke, J., Mahdavi, J. and T. Ott, "The
Macroscopic Behavior of the TCP Congestion Avoidance
Algorithm", Computer Communication Review, Vol. 27,
number 3, July 1997.
[MYR95] Boden, N., Cohen, D., Felderman, R., Kulawik, A.,
Seitz, C., et al. MYRINET: A Gigabit per Second Local
Area Network, IEEE-Micro, Vol. 15, No.1, February 1995,
pp. 29-36.
Karn, et al. Best Current Practice [Page 48]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[PFTK98] Padhye, J., Firoiu, V., Towsley, D. and J. Kurose,
"Modeling TCP Throughput: a Simple Model and its
Empirical Validation", UMASS CMPSCI Tech Report TR98-
008, Feb. 1998.
[RED93] Floyd, S. and V. Jacobson, "Random Early Detection
gateways for Congestion Avoidance", IEEE/ACM
Transactions in Networking, Vol. 1 No. 4, August 1993.
http://www.aciri.org/floyd/papers/red/red.html
[RF95] Romanow, A. and S. Floyd, "Dynamics of TCP Traffic over
ATM Networks". IEEE Journal of Selected Areas in
Communication, Vol.13 No. 4, May 1995, p. 633-641.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC826] Plummer, D.C., "Ethernet Address Resolution Protocol:
Or converting network protocol addresses to 48-bit
Ethernet address for transmission on Ethernet
hardware", STD 37, RFC 826, November 1982.
[RFC1071] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet checksum", RFC 1071, September 1988.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD
5, RFC 1112, August 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.
[RFC1332] McGregor, C., "The PPP Internet Protocol Control
Protocol (IPCP)", RFC 1332, May 1992.
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
Karn, et al. Best Current Practice [Page 49]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51,
RFC 1662, July 1994.
[RFC1750] Eastlake 3rd, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October
1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O`Dell,
M., Romanow, A., Weinrib, A. and L. Zhang, "Resource
ReSerVation Protocol (RSVP) -- Version 1 Applicability
Statement Some Guidelines on Deployment", RFC 2208,
September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
Karn, et al. Best Current Practice [Page 50]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C. and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L.,
Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April
1998.
[RFC2322] van den Hout, K., Koopal, A. and R. van Mook,
"Management of IP numbers by peg-dhcp", RFC 2322, 1
April 1998.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)",
RFC 2332, April 1998.
[RFC2364] Gross, G., Kaycee, M., Li, A., Malis, A. and J.
Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE",
RFC 2394, December 1998.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression
Using LZS", RFC 2395, December 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
Karn, et al. Best Current Practice [Page 51]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, February
1999.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification
to TCP's Fast Recovery Algorithm", RFC 2582, April
1999.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
Handling", RFC 2632, June 1999.
Karn, et al. Best Current Practice [Page 52]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol
Encapsulation over ATM Adaptation Layer 5", RFC 2684,
September 1999.
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link
PPP", RFC 2686, September 1999.
[RFC2687] Bormann, C., "PPP in a Real-time Oriented HDLC-like
Framing", RFC 2687, September 1999.
[RFC2689] Bormann, C., "Providing Integrated Services over Low-
bitrate Links", RFC 2689, September 1999.
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC
2784, March 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S. and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001.
Karn, et al. Best Current Practice [Page 53]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[RFC3095] Bormann, C., Ed., Burmeister, C., Degermark, M.,
Fukushima, H., Hannu, H., Jonsson, L-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.
[RFC3096] Degermark, M., Ed., "Requirements for robust IP/UDP/RTP
header compression", RFC 3096, 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.
[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.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3173] Shacham, A., Monsour, B., Pereira, R. and M. Thomas,
"IP Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J.,
Halpern, J., Kumar, B. and J. Schnizlein, "A Delay
Bound alternative revision of RFC 2598", RFC 3248,
March 2002.
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on
link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
August 2002.
Karn, et al. Best Current Practice [Page 54]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
Sooriyabandara, "TCP Performance Implications of
Network Path Asymmetry", BCP 69, RFC 3449, December
2002.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L. and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L.,
Handley, M. and J. Crowcroft, "Layered Coding Transport
(LCT) Building Block", RFC 3451, December 2002.
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
Handley, M. and J. Crowcroft, "Forward Error Correction
(FEC) Building Block", RFC 3452, December 2002.
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
Handley, M. and J. Crowcroft, "The Use of Forward Error
Correction (FEC) in Reliable Multicast", RFC 3453,
December 2002.
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group
Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
Ed. and G. Fairhurst, Ed., "The User Datagram Protocol
(UDP)-Lite Protocol", RFC 3828, June 2004.
[Schneier95] Schneier, B., Applied Cryptography: Protocols,
Algorithms and Source Code in C (John Wiley and Sons,
October 1995).
[Schneier00] Schneier, B., Secrets and Lies: Digital Security in a
Networked World (John Wiley and Sons, August 2000).
[SP2000] Stone, J. and C. Partridge, "When the CRC and TCP
Checksum Disagree", ACM SIGCOMM, September 2000.
http://www.acm.org/sigcomm/sigcomm2000/conf/
paper/sigcomm2000-9-1.pdf
Karn, et al. Best Current Practice [Page 55]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
[SRC81] Saltzer, J., Reed D. and D. Clark, "End-to-End
Arguments in System Design". Second International
Conference on Distributed Computing Systems (April,
1981) pages 509-512. Published with minor changes in
ACM Transactions in Computer Systems 2, 4, November,
1984, pages 277-288. Reprinted in Craig Partridge,
editor Innovations in internetworking. Artech House,
Norwood, MA, 1988, pages 195-206. ISBN 0-89006-337-0.
[SSL2] Hickman, K., "The SSL Protocol", Netscape
Communications Corp., Feb 9, 1995.
[SSL3] Frier, A., Karlton, P. and P. Kocher, "The SSL 3.0
Protocol", Netscape Communications Corp., Nov 18, 1996.
[TCPF98] Lin, D. and H.T. Kung, "TCP Fast Recovery Strategies:
Analysis and Improvements", IEEE Infocom, March 1998.
http://www.eecs.harvard.edu/networking/papers/infocom-
tcp-final-198.pdf
[WFBA2000] Wagner, D., Foster, J., Brewer, E. and A. Aiken, "A
First Step Toward Automated Detection of Buffer Overrun
Vulnerabilities", Proceedings of NDSS2000.
http://www.isoc.org/isoc/conferences/ndss/
2000/proceedings/039.pdf
[Wilbur89] Wilbur, Steve R., Jon Crowcroft, and Yuko Murayama.
"MAC layer Security Measures in Local Area Networks",
Local Area Network Security, Workshop LANSEC '89
Proceedings, Springer-Verlag, April 1989, pp. 53-64.
Karn, et al. Best Current Practice [Page 56]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
21. Contributors' Addresses
Aaron Falk
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, CA 90292
Phone: 310-448-9327
EMail: falk@isi.edu
Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica,
Politecnico di Bari Via Orabona 4, 70125 Bari, Italy
Phone: +39 080 596 3621
EMail: mascolo@poliba.it
URL: http://www-dee.poliba.it/dee-web/Personale/mascolo.html
Marie-Jose Montpetit
MJMontpetit.com
EMail: marie@mjmontpetit.com
Karn, et al. Best Current Practice [Page 57]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
22. Authors' Addresses
Phil Karn, Editor
Qualcomm 5775 Morehouse Drive
San Diego CA 92121
Phone: 858 587 1121
EMail: karn@qualcomm.com
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
D-28334 Bremen, Germany
Phone: +49 421 218 7024
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Godred (Gorry) Fairhurst
Department of Engineering, University of Aberdeen,
Aberdeen, AB24 3UE, United Kingdom
EMail: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
Dan Grossman
Motorola, Inc.
111 Locke Drive
Marlboro, MA 01752
EMail: Dan.Grossman@motorola.com
Reiner Ludwig
Ericsson Research
Ericsson Allee
1 52134 Herzogenrath, Germany
Phone: +49 2407 575 719
EMail: Reiner.Ludwig@ericsson.com
Karn, et al. Best Current Practice [Page 58]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
Jamshid Mahdavi
Novell, Inc.
EMail: jmahdavi@earthlink.net
Gabriel Montenegro
Sun Microsystems Laboratories, Europe
180, Avenue de l'Europe
38334 Saint Ismier CEDEX
France
EMail: gab@sun.com
Joe Touch
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey CA 90292
Phone: 310 448 9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Lloyd Wood
Cisco Systems
9 New Square Park, Bedfont Lakes
Feltham TW14 8HA
United Kingdom
Phone: +44 (0)20 8824 4236
EMail: lwood@cisco.com
URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/
Karn, et al. Best Current Practice [Page 59]
RFC 3819 Advice for Internet Subnetwork Designers July 2004
23. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Karn, et al. Best Current Practice [Page 60]