О документе
RFC3481/part-001 — от заголовка документа до раздела 2.4 включительно, последнее предложение фрагмента: “following reasons.”
Рабочая группа сети H. Inamura, ред.
Запрос комментариев: 3481 NTT DoCoMo, Inc.
BCP: 71 G. Montenegro, ред.
Категория: Лучшая современная практика Sun Microsystems Laboratories
Europe
R. Ludwig
Ericsson Research
A. Gurtov
Sonera
F. Khafizov
Nortel Networks
Февраль 2003
TCP в беспроводных сетях второго (2.5G) и третьего (3G) поколения
1. Введение ................................................................ 3
2. Характеристики каналов 2.5G и 3G ...................................... 4
2.1 Задержка ......................................................... 4
2.2 Скорости передачи данных .......................................... 5
2.3 Асимметрия ....................................................... 6
2.4 Скачки задержки .................................................. 6
2.5 Потеря пакетов вследствие повреждения ............................. 7
2.6 Межсистемные переключения ........................................ 7
2.7 Колебание полосы пропускания ..................................... 7
3. Примеры развёртываний 2.5G и 3G ....................................... 8
3.1 Технологии 2.5G: GPRS, HSCSD и CDMA2000 1XRTT .................... 8
3.2 Технология 3G: W-CDMA ............................................ 8
3.3 Технология 3G: CDMA2000 1X-EV ................................... 10
4. TCP в 2.5G и 3G ..................................................... 10
4.1 Подходящий размер окна (отправитель и получатель) ............... 11
4.2 Увеличенное начальное окно (отправитель) ........................ 11
4.3 Ограниченная передача (отправитель) ............................. 12
4.4 IP MTU больше значения по умолчанию ............................. 12
4.5 Обнаружение Path MTU (отправитель и промежуточные
маршрутизаторы) ................................................. 13
4.6 Выборочные подтверждения (отправитель и получатель) ............. 13
4.7 Явное уведомление о перегрузке (отправитель, получатель
и промежуточные маршрутизаторы) ................................. 13
4.8 Опция временных меток TCP (отправитель и получатель) ............ 13
4.9 Отключение сжатия заголовков TCP/IP по RFC 1144
(беспроводной хост) ............................................. 15
4.10 Резюме .......................................................... 16
5. Открытые вопросы ..................................................... 16
6. Соображения безопасности ............................................. 18
7. Соображения IANA ..................................................... 18
8. Благодарности ......................................................... 19
9. Нормативные ссылки ................................................... 19
10. Информативные ссылки ................................................. 21
11. Адреса авторов ....................................................... 25
12. Полное заявление об авторском праве .................................. 26
1. Введение
Сотовые системы второго поколения обычно называют 2G. Этап 2G начался в 1990-х годах, когда цифровое кодирование речи заменило аналоговые системы (1G). Системы 2G основаны на различных радиотехнологиях, включая множественный доступ с частотным, кодовым и временным разделением. Примерами систем 2G являются GSM (Европа), PDC (Япония) и IS-95 (США). Каналы передачи данных, предоставляемые системами 2G, преимущественно используют коммутацию каналов и имеют скорость передачи 10–20 кбит/с в восходящем и нисходящем направлениях. Спрос на более высокие скорости передачи данных, немедленную доступность и тарификацию по объёму данных, а также нехватка радиочастотного спектра, выделенного для 2G, привели к появлению систем 2.5G (например, GPRS и PDC-P) и 3G (например, Wideband CDMA и cdma2000).
Радиотехнологии как Wideband CDMA (W-CDMA) (принятая, например, в Европе, Японии и т. д.), так и cdma2000 (принятая, например, в США, Южной Корее и т. д.) основаны на множественном доступе с кодовым разделением, что обеспечивает более высокие скорости передачи данных и более эффективное использование спектра, чем системы 2G. Системы 3G предоставляют соединения как с коммутацией пакетов, так и с коммутацией каналов, чтобы удовлетворять требованиям к качеству обслуживания приложений диалогового, интерактивного, потокового режимов и приложений массовой передачи. Ожидается, что переход к 3G будет постепенным процессом. Первоначально 3G будет развёрнута для предоставления высокоёмкого и высокоскоростного доступа в густонаселённых районах. Мобильные пользователи с многорежимными терминалами смогут использовать существующее покрытие систем 2.5G на остальной территории.
Значительная деятельность по разработке и развёртыванию сосредоточена вокруг технологий 2.5G и 3G. Наряду с такими целями, как увеличение ёмкости голосовых каналов, их основной мотивацией является передача данных, в частности доступ к Интернету. Соответственно, ключевыми вопросами являются производительность TCP и несколько методов, которые могут быть применены для её оптимизации в различных беспроводных средах [19].
Этот документ предлагает профиль таких методов (в особенности эффективных для использования с беспроводными сетями 2.5G и 3G). Параметры конфигурации в этом документе обычно присутствуют в современных стеках TCP и являются широко доступными механизмами IETF, находящимися на пути стандартизации, которые сообщество признало безопасными в глобальном Интернете (то есть даже в сценариях с преимущественно небеспроводными сетями). Кроме того, этот документ представляет один набор рекомендаций, охватывающий как сети 2.5G, так и 3G. Поскольку оба поколения беспроводных технологий создают сходные проблемы для производительности TCP (см. раздел 2), оправдан один общий набор.
Двумя примерами применения рекомендаций этого документа являются:
o WAP Forum [25] (часть Open Mobile Alliance [26] с июня 2002 года) — это отраслевая ассоциация, разработавшая стандарты для беспроводных информационных и телефонных служб на цифровых мобильных телефонах. Чтобы обеспечить функциональность WAP для высокоскоростных сетей, таких как сети 2.5G и 3G, и стремиться к сближению со стандартами Интернета, WAP Forum всесторонне пересмотрел свои спецификации. Получившаяся версия 2.0 [31] использует TCP в качестве транспортного протокола и рекомендует механизмы оптимизации TCP, тесно согласованные с описанными в этом документе.
o I-mode [33] — служба беспроводного Интернета, развёрнутая на телефонах в Японии. Более новая версия i-mode работает поверх FOMA [34], реализации W-CDMA. I-mode поверх FOMA развёртывает профиль TCP, описанный в этом документе.
Этот документ имеет следующую структуру: раздел 2 рассматривает характеристики канального уровня сетей 2.5G/3G; раздел 3 даёт краткий обзор некоторых представительных технологий 2.5G/3G, таких как W-CDMA, cdma2000 и GPRS; раздел 4 рекомендует механизмы и параметры конфигурации для реализаций TCP, используемых в сетях 2.5G/3G, включая резюме в виде таблицы в конце раздела; наконец, раздел 5 рассматривает некоторые открытые вопросы.
2. Характеристики каналов 2.5G и 3G
Характеристики канального уровня сетей 2.5G/3G значительно влияют на производительность TCP. В этом разделе представлены различные аспекты характеристик каналов, присущие сетям 2.5G/3G.
2.1 Задержка
Задержка каналов 2.5G/3G велика главным образом вследствие обширной обработки, требуемой на физическом уровне этих сетей, например для FEC и перемежения, а также вследствие задержек передачи в сети радиодоступа [58] (включая повторные передачи на уровне канала). Типичное RTT составляет от нескольких сотен миллисекунд до одной секунды. Связанные с ними радиоканалы работают в сложных условиях распространения сигнала. Поэтому для обеспечения высокой ёмкости в широкой зоне покрытия с эффективным использованием ресурсов необходимо применять мощные, но сложные методы физического уровня. Будем надеяться, что быстрые улучшения во всех областях беспроводных сетей — от методов радиоуровня и обработки сигналов до системной архитектуры — в конечном счёте также приведут к уменьшению задержек в беспроводных системах 3G.
2.2 Скорости передачи данных
Основными стимулами перехода от 2G к 2.5G, а затем к 3G являются увеличение ёмкости голосовой связи и скоростей передачи данных для пользователей. Системы 2.5G имеют скорости передачи данных 10–20 кбит/с в восходящем направлении и 10–40 кбит/с в нисходящем. Ожидается, что начальные системы 3G будут иметь скорости передачи около 64 кбит/с в восходящем направлении и 384 кбит/с в нисходящем. С учётом получающегося произведения полосы пропускания на задержку (BDP), составляющего около 1–5 КБ для 2.5G и 8–50 КБ для 3G, каналы 2.5G можно считать LTN (Long Thin Networks [19]), а каналы 3G приближаются к LFN (Long Fat Networks [2], как некоторые спутниковые сети [48]). Соответственно, заинтересованные читатели могут найти связанные и потенциально уместные вопросы, рассмотренные в RFC 2488 [49]. Для хорошей производительности TCP как LFN, так и LTN требуют поддержания достаточно большого окна неподтверждённых данных. Для LFN особое значение имеет использование доступной полосы пропускания сети. LTN необходимо достаточно большое окно для эффективного восстановления после потерь. В частности, алгоритм быстрой повторной передачи не может быть запущен, если окно меньше четырёх сегментов. Это приводит к длительному восстановлению через тайм-ауты повторной передачи. Алгоритм Limited Transmit RFC 3042 [10] помогает избежать вредных последствий тайм-аутов для соединений с малыми окнами. Тем не менее полное использование информации SACK RFC 2018 [3] для восстановления после потерь как в LFN, так и в LTN может потребовать вдвое большего окна, чем иначе было бы достаточно для использования доступной полосы пропускания.
Этот документ рекомендует только стандартные механизмы, пригодные как для LTN, так и для LFN, а также для любой сети в целом. Однако экспериментальные механизмы, предложенные в разделе 5, могут быть ориентированы либо на LTN [19], либо на LFN [48].
Скорости передачи данных динамически меняются вследствие влияния других пользователей и мобильности. Прибывающие и уходящие пользователи могут уменьшать или увеличивать доступную в соте полосу пропускания. Увеличение расстояния от базовой станции уменьшает полосу пропускания канала из-за снижения качества канала. Наконец, просто перемещаясь в другую соту, пользователь может испытать внезапное изменение доступной полосы пропускания. Например, если при смене сот соединение испытывает внезапное увеличение доступной полосы пропускания, оно может использовать её не полностью, поскольку при предотвращении перегрузки TCP медленно увеличивает скорость отправки. Переход из быстрой соты в медленную обычно хорошо обрабатывается TCP благодаря свойству самотактирования. Однако внезапное увеличение RTT в этом случае может вызвать ложный тайм-аут TCP, как описано в разделе 2.7. Кроме того, большое окно TCP, используемое в быстрой соте, может создать перегрузку, приводящую к чрезмерной буферизации в медленной соте.
2.3 Асимметрия
Системы 2.5G/3G могут работать с асимметричными скоростями передачи данных в восходящем и нисходящем направлениях. Скорость передачи в восходящем направлении ограничивается энергопотреблением батареи и ограничениями сложности мобильных терминалов. Однако асимметрия не превышает 3–6 раз и может быть перенесена TCP без необходимости в таких методах, как управление перегрузкой ACK или фильтрация ACK [50]. Соответственно, этот документ не включает рекомендаций, предназначенных для таких сильно асимметричных сетей.
2.4 Скачки задержки
Скачок задержки — это внезапное увеличение задержки пути связи. Каналы 2.5G/3G, вероятно, будут испытывать скачки задержки, превышающие типичное RTT в несколько раз, по следующим причинам.
1. Длительный всплеск задержки может возникнуть во время восстановления на канальном уровне после обрыва канала из-за временной потери радиопокрытия, например при въезде в туннель или в лифте.
2. Во время хэндовера мобильный терминал и новая базовая станция должны обменяться сообщениями и выполнить некоторые другие требующие времени действия, прежде чем в новой ячейке смогут передаваться данные.
3. Многие беспроводные сети глобального охвата обеспечивают бесшовную мобильность, внутренне перенаправляя пакеты от старой базовой станции к новой, что может вызывать дополнительную задержку.
4. Блокирование трафиком с высоким приоритетом может происходить, когда поступающий вызов с коммутацией каналов или данные с более высоким приоритетом временно вытесняют радиоканал. Это происходит потому, что большинство современных терминалов не способны одновременно обрабатывать голосовой вызов и соединение для передачи данных и в таком случае приостанавливают соединение для передачи данных.
5. Кроме того, планировщик в радиосети может приостановить низкоприоритетную передачу данных, чтобы предоставить радиоканал пользователям с более высоким приоритетом.
Всплески задержки могут вызывать ложные тайм-ауты TCP, ненужные повторные передачи и мультипликативное уменьшение размера окна перегрузки.
2.5 Потеря пакетов из-за повреждений
Даже при высокой вероятности ошибок кадров физического уровня системы 2.5G/3G имеют низкую частоту потерь пакетов благодаря повторным передачам на канальном уровне. Обоснование ARQ канального уровня рассматривается в [23], [22], [44]. В общем случае ARQ и FEC канального уровня могут предоставлять пакетный сервис с пренебрежимо малой вероятностью необнаруженных ошибок (отказов CRC канала) и низким уровнем потерь (недоставки) для трафика верхнего уровня, например IP. Частота потерь IP-пакетов низка благодаря ARQ, но восстановление на канальном уровне проявляется для вышележащих уровней как джиттер задержки, увеличивая вычисленное значение RTO.
2.6 Межсистемные хэндоверы
На начальной стадии развёртывания системы 3G будут использоваться как технология «горячих точек» в районах с высокой плотностью населения, тогда как системы 2.5G будут предоставлять услуги передачи данных с более низкой скоростью в других местах. Это создаёт среду, в которой мобильный пользователь может перемещаться между сетями 2.5G и 3G, сохраняя действующие TCP-соединения. Межсистемный хэндовер, вероятно, вызовет значительный всплеск задержки (раздел 2.4) и может привести к потере данных. Дополнительные проблемы возникают из-за передачи контекста, которая выходит за рамки этого документа, но рассматривается в IETF в других работах, посвящённых бесшовной мобильности [51].
Межсистемные хэндоверы могут неблагоприятно влиять на действующие TCP-соединения, поскольку функции могут согласовываться только при установлении соединения и позднее не могут быть изменены. После межсистемного хэндовера характеристики сети могут радикально отличаться и фактически могут испытывать отрицательное влияние исходной конфигурации. Этот аргумент свидетельствует против преждевременной оптимизации реализацией TCP.
2.7 Колебание пропускной способности
Учитывая ограниченный радиочастотный спектр, удовлетворение потребностей беспроводных систем 2.5G/3G в высокой скорости передачи данных требует динамического совместного использования ресурсов между одновременно работающими пользователями данных. Для максимизации использования ресурсов могут развёртываться различные механизмы планирования. Если несколько пользователей хотят одновременно передавать большие объёмы данных, планировщику, возможно, придётся многократно выделять и освобождать ресурсы для каждого пользователя. Мы называем периодическое выделение и освобождение высокоскоростных каналов колебанием пропускной способности (Bandwidth Oscillation). Эффекты колебания пропускной способности, такие как ложные повторные передачи, были выявлены в других источниках (например, [30]) как факторы, ухудшающие пропускную способность. Имеются исследовательские работы [52], [54], показывающие, что в некоторых случаях колебание пропускной способности может быть единственным наиболее важным фактором снижения пропускной способности. При фиксированных параметрах TCP достижимая пропускная способность зависит от схемы выделения ресурсов.
Когда частота выделения и освобождения ресурсов достаточно высока, ухудшения пропускной способности не происходит. Однако увеличение частоты выделения/освобождения ресурсов может сопровождаться увеличением сигнализации и поэтому может быть нежелательным. Стандарты для беспроводных технологий 3G предусматривают механизмы, которые могут использоваться для противодействия неблагоприятным эффектам колебания пропускной способности. По общему мнению Рабочей группы PILC, наилучшим подходом к предотвращению неблагоприятных эффектов колебания пропускной способности является надлежащее проектирование беспроводной подсети [23].
3. Примеры развёртываний 2.5G и 3G
В этом разделе приводятся дополнительные подробности о нескольких примерах технологий 2.5G/3G. Цель состоит не в полноте, а только в обсуждении некоторых представительных технологий и вопросов, которые могут возникать в связи с производительностью TCP. Другие документы подробнее рассматривают лежащие в основе технологии. Например, ARQ и FEC рассматриваются в [23], а дополнительное обоснование ARQ канального уровня — в [22], [44].
3.1 Технологии 2.5G: GPRS, HSCSD и CDMA2000 1XRTT
Высокоскоростная передача данных с коммутацией каналов (High Speed Circuit-Switched Data, HSCSD) и служба пакетной радиопередачи общего пользования (General Packet Radio Service, GPRS) являются расширениями GSM, предоставляющими пользователю высокие скорости передачи данных. Оба расширения были сначала разработаны ETSI, а позднее — 3GPP. В GSM пользователю назначается один временной слот нисходящей линии и один временной слот восходящей линии. HSCSD выделяет пользователю несколько временных слотов, создавая быстрое соединение с коммутацией каналов. GPRS основана на технологии коммутации пакетов, которая позволяет эффективно совместно использовать радиоресурсы между пользователями и обеспечивает постоянную готовность к работе. Несколько терминалов могут совместно использовать временные слоты. Сеть GPRS использует в качестве сети доступа обновлённую подсистему базовых станций GSM; базовая сеть GPRS включает обслуживающие узлы поддержки GPRS (Serving GPRS Support Nodes, SGSN) и шлюзовые узлы поддержки GPRS (Gateway GPRS Support Nodes, GGSN). Протокол RLC, работающий между контроллером базовой станции и терминалом, обеспечивает возможность ARQ по радиоканалу. Протокол Logical Link Control (LLC) между SGSN и терминалом также имеет возможность ARQ, используемую во время хэндоверов.
3.2 Технология 3G: W-CDMA
Международный союз электросвязи (International Telecommunication Union, ITU) выбрал Wideband Code Division Multiple Access (W-CDMA) в качестве одной из глобальных телекоммуникационных систем для стандарта мобильной связи 3G IMT-2000. Спецификации W-CDMA создаются в рамках Проекта партнёрства третьего поколения (3rd Generation Partnership Project, 3GPP).
Характеристиками канального уровня сети 3G, которые оказывают наибольшее влияние на производительность TCP по каналу, являются схемы контроля ошибок, такие как ARQ уровня два (L2 ARQ) и FEC (прямое исправление ошибок).
W-CDMA использует RLC (Radio Link Control) [20], ARQ с избирательным повтором и скользящим окном. RLC использует блоки данных протокола (PDUs) с 16-битным заголовком RLC. Размер PDU может различаться. Обычно реализуются PDU размером 336 бит [34]. Это единица повторной передачи канального уровня. IP-пакет фрагментируется на PDU для передачи посредством RLC. (Дополнительное обсуждение фрагментации см. в разделе 4.4.)
В W-CDMA от одного до двенадцати PDU (кадров RLC) составляют один кадр FEC, фактический размер которого зависит от условий канала и распределения полосы пропускания. Кадр FEC является единицей перемежения. Такое накопление PDU для FEC добавляет часть задержки, упомянутой в разделе 2.1.
Для надёжной передачи RLC имеет подтверждаемый режим повторной передачи PDU. RLC использует ARQ с контрольными точками [20] с подтверждениями типа «status report»; бит poll в заголовке явно запрашивает у партнёра отчёт о состоянии, содержащий номер последовательности, который партнёр подтверждает. Использование бита poll контролируется таймерами и размером доступного буферного пространства в RLC. Кроме того, когда партнёр обнаруживает разрыв между номерами последовательностей в принятых кадрах, он может выдать отчёт о состоянии для инициирования повторной передачи. RLC сохраняет порядок доставки пакетов.
Максимальное число повторных передач является настраиваемым параметром RLC, который задаётся RRC [39] (Radio Resource Controller) посредством инициализации соединения RLC. RRC может установить максимальное число повторных передач (до максимума в 40). Поэтому RLC можно описать как ARQ, который в соответствии с терминологией [22] может быть настроен либо как HIGH-PERSISTENCE, либо как LOW-PERSISTENCE, но не как PERFECT-PERSISTENCE.
Поскольку RRC управляет состоянием соединения RLC, колебание пропускной способности (раздел 2.7) может быть устранено тем, что RRC сохраняет радиочастотный ресурс за соединением RLC, в очереди которого имеются данные. Это предотвращает освобождение ресурса в середине передачи данных.
В итоге ARQ и FEC канального уровня могут предоставлять пакетный сервис с пренебрежимо малой вероятностью необнаруженной ошибки (отказа CRC канала) и низким уровнем потерь (недоставки) для трафика верхнего уровня, то есть IP. Повторная передача PDU посредством ARQ вносит в IP-поток задержку и джиттер задержки. Поэтому транспортный уровень воспринимает лежащую в основе сеть W-CDMA как сеть с
относительно большим BDP (Bandwidth-Delay Product) — до 50 KB для радиоканала 384 kbps.
3.3 Технология 3G: CDMA2000 1X-EV
Одним из стандартов наземного радиоинтерфейса для беспроводных систем 3G, предложенных в рамках International Mobile Telecommunications-2000, является cdma2000 [55]. Он использует технологию многочастотного кодового разделения множественного доступа (Multi-Carrier Code Division Multiple Access, CDMA) с радиочастотной полосой одного несущего канала 1.25 MHz. cdma2000 произошёл от IS-95 [56], стандарта 2G на основе технологии CDMA. На первом этапе cdma2000 используется одна несущая; он предназначен для удвоения голосовой ёмкости существующих сетей CDMA (IS-95) и поддержки постоянно готовой передачи данных со скоростью до 316.8 kbps. Как упоминалось выше, эти расширенные возможности предоставляет cdma2000 1XRTT. Скорости 3G в 2 Mbps предоставляет cdma2000 1X-EV. На физическом уровне стандарт допускает передачу во временных кадрах 5,10,20,40 или 80 ms. Для идентификации каналов и достижения более высоких скоростей передачи данных используются различные ортогональные коды (Walsh).
Radio Link Protocol Type 3 (RLP) [57] используется с Traffic Channel cdma2000 для поддержки служб передачи данных CDMA. RLP предоставляет транспортную службу потока октетов и не учитывает кадрирование верхних уровней. Существует несколько форматов кадров RLP. Форматы кадров RLP с большей полезной нагрузкой были разработаны для более высоких скоростей передачи данных. В зависимости от скорости канала в одном кадре физического уровня может передаваться один или несколько кадров RLP.
RLP может существенно уменьшать частоту ошибок, наблюдаемую в каналах трафика CDMA [53]. При передаче данных RLP является чистым протоколом конечного избирательного повтора на основе NAK. Приёмник не подтверждает успешно принятые кадры данных. Если отсутствует один или несколько кадров данных RLP, принимающий RLP предпринимает несколько попыток (называемых раундами NAK) восстановить их, отправляя передатчику один или несколько управляющих кадров NAK. Каждый кадр NAK должен отправляться в отдельном кадре физического уровня. Когда RLP выдаёт последний управляющий кадр NAK конкретного раунда NAK, устанавливается таймер повторной передачи. Если отсутствующий кадр не получен к истечению таймера, RLP может попытаться выполнить другой раунд NAK. RLP может не восстановить все отсутствующие кадры. Если после всех раундов RLP кадр всё ещё отсутствует, RLP передаёт данные с отсутствующим кадром протоколам верхнего уровня.
4. TCP поверх 2.5G и 3G
Далее приводится набор рекомендаций для параметров конфигурации стеков протоколов, которые будут использоваться для поддержки TCP-соединений поверх беспроводных сетей 2.5G и 3G. Некоторые из этих рекомендаций предполагают специальную конфигурацию:
o у приёмника данных (часто это стек на беспроводном устройстве или рядом с ним),
o у отправителя данных (часто это хост в Интернете либо, возможно, шлюз или прокси на границе беспроводной сети), или
o у обоих.
Эти параметры конфигурации являются обычно доступными механизмами IETF, проходящими по стандартному треку и считающимися безопасными в общем Интернете. Однако системным администраторам следует учитывать, что увеличение размера MTU (раздел 4.4) и отключение сжатия заголовков RFC 1144 (раздел 4.9) могут повлиять на эффективность хоста, а изменять такие параметры следует с осторожностью.
4.1 Подходящий размер окна (отправитель и получатель)
TCP поверх 2.5G/3G следует поддерживать подходящие размеры окна на основе произведения пропускной способности на задержку (Bandwidth Delay Product, BDP) сквозного пути (см. раздел 2.2). Спецификация TCP [14] ограничивает размер окна получателя значением 64 KB. Если ожидается, что сквозной BDP будет больше 64 KB, для преодоления этого ограничения может использоваться опция масштабирования окна [2]. Многие операционные системы по умолчанию используют небольшие буферы приёма и отправки TCP — около 16KB. Поэтому даже при BDP менее 64 KB настройку размера буфера по умолчанию следует увеличить как у отправителя, так и у получателя, чтобы допустить достаточно большое окно.
4.2 Увеличенное начальное окно (отправитель)
TCP управляет скоростью передачи с помощью механизма окна перегрузки.
Традиционное начальное значение окна в один сегмент в сочетании с
механизмом отложенного ACK [17] подразумевает ненужные простои на
начальном этапе соединения, включая время ожидания отложенного ACK
(обычно 200 мс, но потенциально до 500 мс) [4]. Отправители
могут избежать этого, используя большее начальное окно до четырёх
сегментов (примерно не более 4 КБ) [4]. Эксперименты с увеличенными
начальными окнами и связанные с ними измерения показали: (1) что
развёртывание этого механизма безопасно (то есть он не приводит к
коллапсу перегрузки) и (2) что он особенно эффективен для передачи
объёма данных в несколько TCP-сегментов (что является поведением,
обычно наблюдаемым в таких приложениях, как мобильные беспроводные
устройства с доступом к Интернету). Для крупных передач данных,
с другой стороны, влияние этого механизма пренебрежимо мало.
TCP поверх 2.5G/3G СЛЕДУЕТ (SHOULD) устанавливать начальный CWND
(congestion window) согласно уравнению 1 из [4]:
min (4*MSS, max (2*MSS, 4380 bytes))
Это увеличивает допустимое начальное окно с одного до значения от двух
до четырёх сегментов (примерно не более 4 КБ).
4.3 Limited Transmit (Отправитель)
RFC 3042 [10], Limited Transmit, расширяет Fast Retransmit/Fast
Recovery для TCP-соединений с малыми окнами перегрузки, которые,
вероятно, не создадут три дублирующих подтверждения, требуемых для
запуска Fast Retransmit [1]. Если у отправителя имеются ранее не
отправленные данные, поставленные в очередь на передачу, механизм
Limited Transmit предписывает отправлять новый сегмент данных в ответ
на каждое из первых двух дублирующих подтверждений, поступивших
отправителю. Этот механизм эффективен при малом размере окна
перегрузки или при потере большого числа сегментов в окне. Он может
предотвратить некоторые повторные передачи, вызванные тайм-аутами TCP.
В частности, некоторые исследования [10] показали, что более половины
повторных передач занятого сервера были вызваны истечением RTO (в
отличие от Fast Retransmit) и что примерно 25 % из них можно было бы
предотвратить с помощью Limited Transmit. Аналогично обсуждению в
разделе 4.2, этот механизм полезен для передачи малых объёмов данных.
Реализации TCP поверх 2.5G/3G СЛЕДУЕТ (SHOULD) реализовывать Limited
Transmit.
4.4 IP MTU больше значения по умолчанию
Максимальный размер IP-дейтаграммы, поддерживаемый канальным уровнем,
— это MTU (Maximum Transfer Unit). Канальный уровень, в свою очередь,
может фрагментировать IP-дейтаграммы на PDU. Например, на линиях с
высокими уровнями ошибок меньший размер PDU канального уровня
увеличивает вероятность успешной передачи. При наличии ARQ второго
уровня и прозрачной фрагментации канального уровня сетевой уровень
может использовать большее MTU даже при относительно высоком BER (Bit
Error Rate). Без этих функций в линии рекомендуется меньшее MTU.
TCP поверх 2.5G/3G следует предоставлять разработчикам свободу выбора
значений MTU в диапазоне от малых значений (таких как 576 байтов) до
большого значения, поддерживаемого используемым типом линии (такого
как 1500 байтов для IP-пакетов в Ethernet). Поскольку окно измеряется
в единицах сегментов, большее MTU позволяет TCP быстрее увеличивать
окно перегрузки [5]. Поэтому разработчикам в целом рекомендуется
выбирать большие значения. Они могут превышать стандартные значения
IP MTU: 576 байтов для IPv4 RFC 1191 [6] и 1280 байтов для IPv6 [18].
Хотя эта рекомендация применима к сетям 3G, при работе в сетях 2.5G
следует проявлять осторожность в соответствии с рекомендациями RFC
4.5 Обнаружение Path MTU (Отправитель и промежуточные маршрутизаторы)
Обнаружение Path MTU позволяет отправителю определить максимальный
размер блока передачи от конца до конца (без IP-фрагментации) для
заданного пути маршрутизации. RFC 1191 [6] и RFC 1981 [8] описывают
процедуру обнаружения MTU для IPv4 и IPv6 соответственно. Это
позволяет TCP-отправителям использовать большие размеры сегментов
(не вызывая фрагментации на уровне IP) вместо предположения малого MTU
по умолчанию. Реализациям TCP поверх 2.5G/3G следует реализовывать
Path MTU Discovery. Path MTU Discovery требует, чтобы промежуточные
маршрутизаторы поддерживали формирование необходимых сообщений ICMP.
RFC 1435 [7] содержит рекомендации, которые могут быть релевантны для
некоторых реализаций маршрутизаторов.
4.6 Выборочные подтверждения (Отправитель и получатель)
Опция выборочного подтверждения (SACK), RFC 2018 [3], эффективна при
потере нескольких TCP-сегментов в одном TCP-окне [24]. В частности,
если путь от конца до конца имеет большой BDP и высокую вероятность
потери пакетов, возрастает вероятность потери нескольких сегментов в
одном окне данных. В таких случаях SACK обеспечивает устойчивость,
превосходящую TCP-Tahoe и TCP-Reno [21]. TCP поверх 2.5G/3G СЛЕДУЕТ
(SHOULD) поддерживать SACK.
При отсутствии функции SACK TCP следует использовать NewReno RFC 2582
[15].
4.7 Явное уведомление о перегрузке (Отправитель, получатель и
промежуточные маршрутизаторы)
Explicit Congestion Notification, RFC 3168 [9], позволяет получателю
TCP информировать отправителя о перегрузке в сети путём установки
флага ECN-Echo при получении IP-пакета, помеченного битом (битами) CE.
Затем TCP-отправитель уменьшит своё окно перегрузки. Таким образом,
считается, что использование ECN обеспечивает преимущества для
производительности [32], [43]. RFC 3168 [9] также устанавливает
требования к промежуточным маршрутизаторам (например, активное
управление очередью и установку бита (битов) CE в IP-заголовке для
индикации перегрузки). Поэтому потенциальное повышение
производительности может быть достигнуто только тогда, когда на пути
развёрнуты маршрутизаторы с поддержкой ECN. TCP поверх 2.5G/3G
СЛЕДУЕТ (SHOULD) поддерживать ECN.
4.8 Опция TCP Timestamps (Отправитель и получатель)
Традиционно TCP собирают по одному образцу RTT на окно данных [14],
[17]. Это может привести к занижению RTT и ложным тайм-аутам на путях,
где задержка передачи пакета доминирует в RTT. Это справедливо даже
при консервативном таймере повторной передачи, таком как заданный в
RFC 2988 [11]. TCP-соединения с большими окнами могут извлечь пользу
из более частых образцов RTT, предоставляемых метками времени, быстрее
адаптируясь к изменяющимся условиям сети [2]. Однако имеются некоторые
эмпирические свидетельства, что для TCP с таймером RFC 2988 [11] метки
времени дают малую пользу или не дают её вовсе на магистральных путях
Интернета [59]. Использование опции TCP Timestamps имеет преимущество:
повторно переданные сегменты могут использоваться для измерения RTT,
что в противном случае запрещено алгоритмом Карна [17], [11]. Кроме
того, опция TCP Timestamps является основой для обнаружения ложных
повторных передач с использованием алгоритма Eifel [30].
Линия (уровень) 2.5/3G выделена одному хосту. Поэтому она испытывает
лишь низкую степень статистического мультиплексирования между разными
потоками. Кроме того, задержки передачи пакетов и постановки в очередь
на линии 2.5/3G часто доминируют в RTT пути. Уже это приводит к
большим изменениям RTT: пакеты заполняют очередь, пока TCP-отправитель
зондирует дополнительную пропускную способность, либо пакеты покидают
очередь, пока TCP-отправитель уменьшает нагрузку в ответ на потерю
пакета. Вдобавок всплески задержки на линии 2.5/3G (см. раздел 2.4)
часто могут превышать RTT от конца до конца. Возникающие в результате
большие изменения RTT пути часто могут вызывать ложные тайм-ауты.
Поэтому при работе TCP в таком окружении выгодно измерять RTT пути
чаще, чем только один раз за RTT. Это позволяет TCP-отправителю точнее
отслеживать изменения RTT. В частности, TCP-отправитель может быстрее
реагировать на внезапные увеличения RTT, раньше обновляя RTO до более
консервативного значения. Опция TCP Timestamps [2] предоставляет эту
возможность, позволяя TCP-отправителю измерять RTT по каждому
подтверждённому сегменту. Использование меток времени в упомянутом
сценарии приводит к более консервативному таймеру повторной передачи
TCP и снижает риск срабатывания ложных тайм-аутов [45], [52], [54],
[60].
С использованием меток времени связаны две проблемы:
o 12 байтов накладных расходов создаются за счёт переноса опции TCP
Timestamps и выравнивания в заголовке TCP. При малом размере MTU
это может представлять значительные накладные расходы. Например,
для MTU 296 байтов дополнительные накладные расходы составляют 4 %.
Для MTU 1500 байтов дополнительные накладные расходы составляют
лишь 0,8 %.
o Текущие схемы сжатия заголовков TCP ограничены в обработке поля
опций TCP. Для RFC 2507 [13] любое изменение поля опций (вызванное,
например, метками времени или SACK) делает всё поле несжимаемым
(однако сам заголовок TCP/IP остаётся сжимаемым). Более того, для
RFC 1144 [40] такое изменение поля опций фактически полностью
отключает сжатие заголовка TCP/IP. Это имеет место, когда соединение
использует опцию TCP Timestamps. Это поле опций используется как на
пути данных, так и на пути ACK, и его значение обычно меняется от
одного пакета к следующему. На момент написания документа IETF
разрабатывала устойчивую схему сжатия заголовков TCP/IP с улучшенной
поддержкой опций TCP [29].
Первоначальное определение опции timestamps [2] указывает, что
дублирующие сегменты ниже кумулятивного ACK не обновляют кэшированное
значение метки времени у получателя. Это может привести к завышенной
оценке RTT для повторно переданных сегментов. Возможное решение [47]
позволяет получателю использовать более свежую метку времени из
дублирующего сегмента. Однако это предложение допускает атаки
подмены против получателя TCP. Поэтому при реализации этого решения
требуется тщательное рассмотрение.
Рекомендация: TCP СЛЕДУЕТ (SHOULD) использовать опцию TCP Timestamps.
Она обеспечивает лучшую оценку RTT и снижает риск ложных тайм-аутов.
4.9 Отключение сжатия заголовков TCP/IP RFC 1144 (Беспроводной хост)
Хорошо известно (и показано экспериментальными данными), что сжатие
заголовков TCP RFC 1144 [40] работает плохо при наличии потерь пакетов
[43], [52]. Если ошибка беспроводной линии не восстановлена, она
вызовет потерю сегмента TCP между компрессором и декомпрессором, и
тогда сжатие заголовков RFC 1144 не позволяет TCP использовать
механизм Fast Retransmit Fast Recovery. Алгоритм сжатия заголовков RFC
1144 передаёт не полные заголовки TCP/IP, а только изменения в
заголовках последовательных сегментов. Поэтому потеря одного сегмента
TCP на линии приводит к рассинхронизации передаваемых и принимаемых
порядковых номеров TCP. Следовательно, когда сегмент TCP теряется
после компрессора, декомпрессор сформирует ложные заголовки TCP. В
результате получатель TCP отбросит все оставшиеся пакеты в текущем
окне из-за ошибки контрольной суммы. Это продолжается, пока компрессор
не получит первую повторную передачу, которая пересылается без сжатия
для синхронизации декомпрессора [40].
Как ранее рекомендовано в RFC 3150 [5], сжатие заголовков RFC 1144
НЕ СЛЕДУЕТ (SHOULD NOT) включать, если только вероятность потери
пакетов между компрессором и декомпрессором не очень мала. Фактически
включение опции Timestamps приводит по существу к тому же результату
(см. раздел 4.8). Другие схемы сжатия заголовков, такие как RFC 2507
[13] и Robust Header Compression [12], предназначены для устранения
недостатков сжатия заголовков RFC 1144. На момент написания этого
документа IETF работала над несколькими расширениями Robust Header
Compression (согласование Robust Header Compression поверх PPP,
сжатие опций TCP и т. д.) [16].
4.10 Сводка
Пункты Комментарии
----------------------------------------------------------------
Подходящий размер окна (отправитель и получатель)
на основе BDP от конца до конца
Опция масштабирования окна (отправитель и получатель)
[RFC1323] Размер окна > 64KB
Увеличенное начальное окно (отправитель)
[RFC3390] CWND = min (4*MSS,
max (2*MSS, 4380 bytes))
Limited Transmit (отправитель)
[RFC3042]
IP MTU больше значения более применимо к 3G
по умолчанию
Path MTU Discovery (отправитель и промежуточные маршрутизаторы)
[RFC1191,RFC1981]
Опция Selective Acknowledgment
(SACK)
[RFC2018] (отправитель и получатель)
Explicit Congestion
Notification(ECN)
[RFC3168] (отправитель, получатель и
промежуточные маршрутизаторы)
Опция Timestamps (отправитель и получатель)
[RFC1323, R.T.Braden's ID]
Отключение RFC1144
сжатия заголовков TCP/IP
[RFC1144] (беспроводной хост)
5. Открытые вопросы
В этом разделе описываются дополнительные механизмы и настройки параметров,
которые могут повысить сквозную производительность при работе TCP через
сети 2.5G/3G. Обратите внимание, что, за исключением обсуждения начального
значения RTO, на момент написания настоящего документа эти механизмы и
настройки параметров не являются частью какого-либо RFC уровня стандартов.
Поэтому они не могут быть рекомендованы для Интернета в целом.
Другие механизмы повышения производительности TCP включают улучшенные
схемы сжатия заголовков TCP/IP [29], активное управление очередями RFC 2309
[28], схемы повторной передачи канального уровня [23], а также кэширование
пакетов во время временных отказов канала для их локальной повторной
передачи при восстановлении работы канала [23].
Недостатки существующих схем сжатия заголовков TCP/IP (RFC 1144
[40], RFC 2507 [13]) заключаются в том, что они не сжимают заголовки
пакетов установления соединения (SYN и FIN) и не обеспечивают надлежащую
обработку полей опций TCP (например, SACK или меток времени) (см. раздел
4.8). Хотя RFC 3095 [12] пока не решает эту проблему, IETF разрабатывает
улучшенные схемы сжатия заголовков TCP/IP, включая улучшенную обработку
опций TCP, таких как метки времени и выборочные подтверждения. В частности,
если через канал проходит много короткоживущих TCP-соединений, сжатие
пакетов установления соединения может значительно повысить общий
коэффициент сжатия заголовков.
Реализация активного управления очередями привлекательна по ряду причин,
изложенных в RFC 2309 [28]. Одно важное преимущество для сетей 2.5G/3G
состоит в том, что оно минимизирует объём потенциально устаревших данных,
которые могут находиться в очереди сети («переход со страницы на страницу»
до завершения загрузки предыдущей страницы). Предотвращение передачи
устаревших данных по радиоканалу 2.5G/3G экономит мощность передачи
(заряд батареи) и увеличивает отношение полезных данных к общему объёму
переданных данных. Другое важное преимущество активного управления
очередями для сетей 2.5G/3G состоит в том, что оно снижает риск ложного
тайм-аута для первого сегмента данных, как описано ниже.
Поскольку сети 2.5G/3G обычно характеризуются большими задержками,
особенно привлекательно избегать ненужных времён кругового обхода.
Это особенно полезно для короткоживущих транзакционных TCP-сеансов
(в стиле «запрос/ответ»), которые обычно возникают при просмотре Web
со смартфона. Однако существующие решения, такие как T/TCP RFC 1644 [27],
не были приняты вследствие известных проблем безопасности [38].
Ложные тайм-ауты, изменение порядка пакетов и дублирование пакетов могут
снижать производительность TCP. Поэтому желательно сделать TCP более
устойчивым к таким событиям. Решения этой проблемы были предложены
в [30], [35], [41], и на момент написания настоящего документа в IETF
продолжается работа по стандартизации. Эти решения включают восстановление
состояния управления перегрузкой после обнаружения такого события, а также
адаптацию таймера повторной передачи и порога дублирующих подтверждений.
Развёртывание таких решений может быть особенно полезным при работе TCP
через беспроводные сети, поскольку беспроводные каналы доступа часто могут
подвергаться передачам обслуживания и вытеснению ресурсов, либо мобильный
передатчик может проходить через зону отсутствия радиопокрытия. Такие
нарушающие работу события могут легко вызвать ложный тайм-аут, несмотря
на консервативный таймер повторной передачи. Кроме того, механизмы
мобильности некоторых беспроводных сетей могут вызывать дублирование
пакетов.
Алгоритм вычисления таймера повторной передачи TCP задан в RFC 2988 [11].
Стандарт указывает, что начальное значение тайм-аута повторной передачи
(RTO) не должно быть меньше 3 секунд. Это значение может быть слишком
малым при работе TCP через сети 2.5G/3G. Помимо больших задержек, эти сети
могут работать на скоростях передачи, столь низких, как примерно 10 kb/s,
что приводит к большим задержкам передачи пакетов. В этом случае RTT для
первого сегмента данных может легко превысить начальную настройку таймера
повторной передачи TCP в 3 секунды. Это тогда вызвало бы ложный тайм-аут
для этого сегмента. Следовательно, в таких ситуациях может быть целесообразно
установить начальный RTO TCP в значение больше 3 секунд. Кроме того,
вследствие потенциально больших задержек передачи пакетов отправитель TCP
может предпочесть не инициализировать свой RTO по RTT, измеренному для SYN,
а вместо этого использовать RTT, измеренное для первого сегмента данных.
Некоторые рекомендации RFC 2988 [11] являются необязательными и соблюдаются
не всеми реализациями TCP. В частности, некоторые стеки TCP допускают
минимальный RTO меньше рекомендуемого значения в 1 секунду (раздел 2.4
[11]), а некоторые реализации не реализуют рекомендуемый перезапуск таймера
RTO при получении ACK (раздел 5.3 [11]). Некоторые эксперименты [52], [54]
показали, что при колебаниях пропускной способности использование
рекомендуемого минимального значения RTO в 1 с (вместе с также
рекомендуемым начальным RTO в 3 с) уменьшает число ложных повторных
передач по сравнению с использованием малых минимальных значений RTO,
равных 200 или 400 ms. Кроме того, стеки TCP, перезапускающие таймер
повторной передачи при получении ACK, испытывают значительно меньше
ложных повторных передач, чем реализации, которые не перезапускают таймер
RTO при получении ACK. Поэтому на момент написания настоящего документа
представляется предпочтительным, чтобы реализации TCP, используемые для
передачи данных в беспроводных сетях 3G, соблюдали все рекомендации
RFC 2988.
6. Соображения безопасности
В беспроводных сетях 2.5G/3G данные передаются по эфиру в виде шифротекста
и в открытом виде между Radio Access Network (RAN) и базовой сетью.
Для сквозной безопасности пользовательские устройства могут развёртывать
IP security RFC 2401 [37] или TLS RFC 2246 [36].
7. Соображения IANA
Эта спецификация не требует никаких действий IANA.
8. Благодарности
Авторы хотели бы отметить вклад в текст следующих лиц:
Max Hata, NTT DoCoMo, Inc. (hata@mml.yrp.nttdocomo.co.jp)
Masahiro Hara, Fujitsu, Inc. (mhara@FLAB.FUJITSU.CO.JP)
Joby James, Motorola, Inc. (joby@MIEL.MOT.COM)
William Gilliam, Hewlett-Packard Company (wag@cup.hp.com)
Alan Hameed, Fujitsu FNC, Inc. (Alan.Hameed@fnc.fujitsu.com)
Rodrigo Garces, Mobility Network Systems
(rodrigo.garces@mobilitynetworks.com)
Peter Ford, Microsoft (peterf@Exchange.Microsoft.com)
Fergus Wills, Openwave (fergus.wills@openwave.com)
Michael Meyer (Michael.Meyer@eed.ericsson.se)
Авторы с благодарностью отмечают ценные советы следующих лиц:
Gorry Fairhurst (gorry@erg.abdn.ac.uk)
Mark Allman (mallman@grc.nasa.gov)
Aaron Falk (falk@ISI.EDU)
9. Нормативные ссылки
[1] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control",
RFC 2581, April 1999.
[2] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[3] Mathis, M., Mahdavi, J., Floyd, S. and R. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[4] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
[5] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end
Performance Implications of Slow Links", BCP 48, RFC 3150, July
2001.
[6] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[7] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
version 6", RFC 1981, August 1996.
[9] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[10] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss
Recovery Using Limited Transmit", RFC 3042, January 2001.
[11] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[12] Bormann, C., 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.
[13] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[14] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, September 1981.
[15] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's
Fast Recovery Algorithm", RFC 2582, April 1999.
[16] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC
3241, April 2002.
[17] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[18] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
10. Справочные ссылки
[19] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N.
Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[20] Third Generation Partnership Project, "RLC Protocol
Specification (3G TS 25.322:)", 1999.
[21] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe,
Reno, and SACK TCP", Computer Communication Review, 26(3) , July
1996.
[22] Fairhurst, G. and L. Wood, "Advice to link designers on link
Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
[23] Karn, P., "Advice for Internet Subnetwork Designers", Work in
Progress.
[24] Dawkins, S., Montenegro, G., Magret, V., Vaidya, N. and M.
Kojo, "End-to-end Performance Implications of Links with
Errors", BCP 50, RFC 3135, August 2001.
[25] Wireless Application Protocol, "WAP Specifications", 2002,
<http://www.wapforum.org>.
[26] Open Mobile Alliance, "Open Mobile Alliance", 2002,
<http://www.openmobilealliance.org/>.
[27] Braden, R., "T/TCP -- TCP Extensions for Transactions", RFC
1644, July 1994.
[28] Braden, R., 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.
[29] IETF, "Robust Header Compression", 2001,
<http://www.ietf.org/html.charters/rohc-charter.html>.
[30] Ludwig, R. and R. H. Katz, "The Eifel Algorithm: Making TCP
Robust Against Spurious Retransmissions", ACM Computer
Communication Review 30(1), January 2000.
[31] Wireless Application Protocol, "WAP Wireless Profiled TCP",
WAP-225-TCP-20010331-a, April 2001,
<http://www.wapforum.com/what/technical.htm>.
[32] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit
Congestion Notification (ECN) in IP Networks", RFC 2884, July
2000.
[33] NTT DoCoMo Technical Journal, "Special Issue on i-mode Service",
October 1999.
[34] NTT DoCoMo Technical Journal, "Special Article on IMT-2000
Services", September 2001.
[35] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000.
[36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[37] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[38] de Vivo, M., O. de Vivo, G., Koeneke, R. and G. Isern, "Internet
Vulnerabilities Related to TCP/IP and T/TCP", ACM Computer
Communication Review 29(1), January 1999.
[39] Third Generation Partnership Project, "RRC Protocol
Specification (3GPP TS 25.331:)", September 2001.
[40] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial
Links", RFC 1144, February 1990.
[41] Blanton, E. and M. Allman, "On Making TCP More Robust to Packet
Reordering", ACM Computer Communication Review 32(1), January
2002, <http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-
ccr.ps>.
[42] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates
in Reliable Transport Protocols", ACM SIGCOMM 87, 1987.
[43] Ludwig, R., Rathonyi, B., Konrad, A. and A. Joseph, "Multi-layer
tracing of TCP over a reliable wireless link", ACM SIGMETRICS
99, May 1999.
[44] Ludwig, R., Konrad, A., Joseph, A. and R. 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.
[45] Gurtov, A., "Making TCP Robust Against Delay Spikes", University
of Helsinki, Department of Computer Science, Series of
Publications C, C-2001-53, Nov 2001,
<http://www.cs.helsinki.fi/u/gurtov/papers/report01.html>.
[46] Stevens, W., "TCP/IP Illustrated, Volume 1; The Protocols",
Addison Wesley, 1995.
[47] Braden, R., "TCP Extensions for High Performance: An Update",
Work in Progress.
[48] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann,
S., Scott, K. and J. Semke, "Ongoing TCP Research Related to
Satellites", RFC 2760, February 2000.
[49] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488,
January 1999.
[50] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
Sooriyabandara, "TCP Performance Implications of Network
Asymmetry", RFC 3449, December 2002.
[51] Kempf, J., "Problem Description: Reasons For Performing Context
Transfers Between Nodes in an IP Access Network", RFC 3374,
September 2002.
[52] Khafizov, F. and M. Yavuz, "Running TCP over IS-2000", Proc. of
IEEE ICC, 2002.
[53] Khafizov, F. and M. Yavuz, "Analytical Model of RLP in IS-2000
CDMA Networks", Proc. of IEEE Vehicular Technology Conference,
September 2002.
[54] Yavuz, M. and F. Khafizov, "TCP over Wireless Links with
Variable Bandwidth", Proc. of IEEE Vehicular Technology
Conference, September 2002.
[55] TIA/EIA/cdma2000, "Mobile Station - Base Station Compatibility
Standard for Dual-Mode Wideband Spread Spectrum Cellular
Systems", Washington: Telecommunication Industry Association,
1999.
[56] TIA/EIA/IS-95 Rev A, "Mobile Station - Base Station
Compatibility Standard for Dual-Mode Wideband Spread Spectrum
Cellular Systems", Washington: Telecommunication Industry
Association, 1995.
[57] TIA/EIA/IS-707-A-2.10, "Data Service Options for Spread Spectrum
Systems: Radio Link Protocol Type 3", January 2000.
[58] Dahlman, E., Beming, P., Knutsson, J., Ovesjo, F., Persson, M.
and C. Roobol, "WCDMA - The Radio Interface for Future Mobile
Multimedia Communications", IEEE Trans. on Vehicular Technology,
vol. 47, no. 4, pp. 1105-1118, November 1998.
[59] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path
Properties", ACM SIGCOMM 99, September 1999.
[60] Gurtov, A. and R. Ludwig, "Responding to Spurious Timeouts in
TCP", IEEE INFOCOM'03, March 2003.
11. Адреса авторов
Hiroshi Inamura
NTT DoCoMo, Inc.
3-5 Hikarinooka
Yokosuka Shi, Kanagawa Ken 239-8536
Japan
EMail: inamura@mml.yrp.nttdocomo.co.jp
URI: http://www.nttdocomo.co.jp/
Gabriel Montenegro
Sun Microsystems Laboratories, Europe
Avenue de l'Europe
ZIRST de Montbonnot
38334 Saint Ismier CEDEX
France
EMail: gab@sun.com
Reiner Ludwig
Ericsson Research
Ericsson Allee 1
52134 Herzogenrath
Germany
EMail: Reiner.Ludwig@Ericsson.com
Andrei Gurtov
Sonera
P.O. Box 970, FIN-00051
Helsinki,
Finland
EMail: andrei.gurtov@sonera.com
URI: http://www.cs.helsinki.fi/u/gurtov/
Farid Khafizov
Nortel Networks
2201 Lakeside Blvd
Richardson, TX 75082,
USA
EMail: faridk@nortelnetworks.com
12. Полное заявление об авторских правах
Copyright (C) The Internet Society (2003). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, комментирующие или иным образом
разъясняющие его либо содействующие его реализации, могут подготавливаться,
копироваться, публиковаться и распространяться полностью или частично,
без каких-либо ограничений, при условии, что приведённое выше уведомление
об авторских правах и этот абзац включены во все такие копии и производные
работы. Однако сам этот документ не может быть каким-либо образом изменён,
например путём удаления уведомления об авторских правах или ссылок на
Internet Society либо другие интернет-организации, за исключением случаев,
когда это необходимо для разработки интернет-стандартов, в котором случае
должны соблюдаться процедуры для авторских прав, определённые процессом
разработки Internet Standards, или когда это требуется для его перевода на
языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не
будут отозваны Internet Society либо её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
"AS IS", И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО
ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ
ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ
ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.