TCP over Second (2.5G) and Third (3G) Generation Wireless Networks
RFC 3481 описывает профиль настройки TCP для путей, включающих беспроводные сети 2.5G и 3G, с учётом высокой задержки, изменчивой пропускной способности, задержек при хэндовере и иных свойств радиоканала. TCP для таких путей следует (SHOULD) настраивать с размером окна по сквозному BDP, увеличенным начальным CWND по формуле min(4*MSS, max(2*MSS, 4380 bytes)), Limited Transmit, Path MTU Discovery, SACK, ECN и опцией временных меток TCP; потенциальный выигрыш ECN возможен лишь при развёртывании ECN-способных маршрутизаторов вдоль пути. RFC 1144 TCP/IP Header Compression не следует включать (SHOULD NOT), если вероятность потерь между компрессором и декомпрессором не очень низка; выбор увеличенного IP MTU следует делать с учётом особенностей канала, причём для 2.5G требуется осторожность. Дополнительно рассматриваются механизмы и настройки, которые на момент публикации, кроме обсуждения начального RTO, не были частью standards-track RFC и поэтому не рекомендуются для Интернета в целом.
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) поколения
Статус данного меморандума
Этот документ определяет Лучшую современную практику Интернета для интернет-сообщества и запрашивает обсуждение и предложения по улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторском праве
Copyright (C) The Internet Society (2003). Все права защищены.
Аннотация
Этот документ описывает профиль оптимизации TCP для его адаптации к путям, включающим беспроводные сети второго (2.5G) и третьего (3G) поколения. В нём описываются соответствующие характеристики сетей 2.5G и 3G, а также особенности примеров развёртывания таких сетей. Затем он рекомендует выбор алгоритмов TCP для узлов, о которых известно, что они являются началом или концом таких путей, а также рассматривает открытые вопросы. Рекомендуемые в этом документе параметры конфигурации обычно присутствуют в современных стеках TCP и являются широко доступными механизмами IETF, находящимися на пути стандартизации, которые сообщество считает безопасными для использования в глобальном Интернете.
Inamura и др. Лучшая современная практика [Страница 1]
RFC 3481 TCP в 2.5G/3G Февраль 2003
Содержание
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
Inamura и др. Лучшая современная практика [Страница 2]
RFC 3481 TCP в 2.5G/3G Февраль 2003
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), оправдан один общий набор.
Inamura и др. Лучшая современная практика [Страница 3]
RFC 3481 TCP в 2.5G/3G Февраль 2003
Двумя примерами применения рекомендаций этого документа являются:
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.
Inamura и др. Лучшая современная практика [Страница 4]
RFC 3481 TCP в 2.5G/3G Февраль 2003
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, используемое в быстрой соте, может создать перегрузку, приводящую к чрезмерной буферизации в медленной соте.
Inamura и др. Лучшая современная практика [Страница 5]
RFC 3481 TCP в 2.5G/3G Февраль 2003
2.3 Асимметрия
Системы 2.5G/3G могут работать с асимметричными скоростями передачи данных в восходящем и нисходящем направлениях. Скорость передачи в восходящем направлении ограничивается энергопотреблением батареи и ограничениями сложности мобильных терминалов. Однако асимметрия не превышает 3–6 раз и может быть перенесена TCP без необходимости в таких методах, как управление перегрузкой ACK или фильтрация ACK [50]. Соответственно, этот документ не включает рекомендаций, предназначенных для таких сильно асимметричных сетей.
2.4 Скачки задержки
Скачок задержки — это внезапное увеличение задержки пути связи. Каналы 2.5G/3G, вероятно, будут испытывать скачки задержки, превышающие типичное RTT в несколько раз, по следующим причинам.1. Длительный всплеск задержки может возникнуть во время восстановления на канальном уровне после обрыва канала из-за временной потери радиопокрытия, например при въезде в туннель или в лифте.
2. Во время хэндовера мобильный терминал и новая базовая станция должны обменяться сообщениями и выполнить некоторые другие требующие времени действия, прежде чем в новой ячейке смогут передаваться данные.
3. Многие беспроводные сети глобального охвата обеспечивают бесшовную мобильность, внутренне перенаправляя пакеты от старой базовой станции к новой, что может вызывать дополнительную задержку.
4. Блокирование трафиком с высоким приоритетом может происходить, когда поступающий вызов с коммутацией каналов или данные с более высоким приоритетом временно вытесняют радиоканал. Это происходит потому, что большинство современных терминалов не способны одновременно обрабатывать голосовой вызов и соединение для передачи данных и в таком случае приостанавливают соединение для передачи данных.
5. Кроме того, планировщик в радиосети может приостановить низкоприоритетную передачу данных, чтобы предоставить радиоканал пользователям с более высоким приоритетом.
Всплески задержки могут вызывать ложные тайм-ауты TCP, ненужные повторные передачи и мультипликативное уменьшение размера окна перегрузки.
Inamura, et al. Best Current Practice [Page 6]
RFC 3481 TCP over 2.5G/3G February 2003
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 достижимая пропускная способность зависит от схемы выделения ресурсов.
Inamura, et al. Best Current Practice [Page 7]
RFC 3481 TCP over 2.5G/3G February 2003
Когда частота выделения и освобождения ресурсов достаточно высока, ухудшения пропускной способности не происходит. Однако увеличение частоты выделения/освобождения ресурсов может сопровождаться увеличением сигнализации и поэтому может быть нежелательным. Стандарты для беспроводных технологий 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).
Inamura, et al. Best Current Practice [Page 8]
RFC 3481 TCP over 2.5G/3G February 2003
Характеристиками канального уровня сети 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 как сеть с
Inamura, et al. Best Current Practice [Page 9]
RFC 3481 TCP over 2.5G/3G February 2003
относительно большим 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. Некоторые из этих рекомендаций предполагают специальную конфигурацию:
Inamura, et al. Best Current Practice [Page 10]
RFC 3481 TCP over 2.5G/3G February 2003
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))
Inamura, et al. Best Current Practice [Page 11]
RFC 3481 TCP over 2.5G/3G February 2003
Это увеличивает допустимое начальное окно с одного до значения от двух
до четырёх сегментов (примерно не более 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
3150 [5].
Inamura, et al. Best Current Practice [Page 12]
RFC 3481 TCP over 2.5G/3G February 2003
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].
Inamura, et al. Best Current Practice [Page 13]
RFC 3481 TCP over 2.5G/3G February 2003
Линия (уровень) 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].
Inamura, et al. Best Current Practice [Page 14]
RFC 3481 TCP over 2.5G/3G February 2003
Первоначальное определение опции 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].
Inamura, et al. Best Current Practice [Page 15]
RFC 3481 TCP over 2.5G/3G February 2003
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 уровня стандартов.
Поэтому они не могут быть рекомендованы для Интернета в целом.
Inamura, et al. Best Current Practice [Page 16]
RFC 3481 TCP over 2.5G/3G February 2003
Другие механизмы повышения производительности 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
через беспроводные сети, поскольку беспроводные каналы доступа часто могут
подвергаться передачам обслуживания и вытеснению ресурсов, либо мобильный
передатчик может проходить через зону отсутствия радиопокрытия. Такие
Inamura, et al. Best Current Practice [Page 17]
RFC 3481 TCP over 2.5G/3G February 2003
нарушающие работу события могут легко вызвать ложный тайм-аут, несмотря
на консервативный таймер повторной передачи. Кроме того, механизмы
мобильности некоторых беспроводных сетей могут вызывать дублирование
пакетов.
Алгоритм вычисления таймера повторной передачи 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.
Inamura, et al. Best Current Practice [Page 18]
RFC 3481 TCP over 2.5G/3G February 2003
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.
Inamura, et al. Best Current Practice [Page 19]
RFC 3481 TCP over 2.5G/3G February 2003
[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.
Inamura, et al. Best Current Practice [Page 20]
RFC 3481 TCP over 2.5G/3G February 2003
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>.
Inamura, et al. Best Current Practice [Page 21]
RFC 3481 TCP over 2.5G/3G February 2003
[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.
Inamura, et al. Best Current Practice [Страница 22]
RFC 3481 TCP over 2.5G/3G Февраль 2003
[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.
Inamura, et al. Best Current Practice [Страница 23]
RFC 3481 TCP over 2.5G/3G Февраль 2003
[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.
Inamura, et al. Best Current Practice [Страница 24]
RFC 3481 TCP over 2.5G/3G Февраль 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
Inamura, et al. Best Current Practice [Страница 25]
RFC 3481 TCP over 2.5G/3G Февраль 2003
12. Полное заявление об авторских правах
Copyright (C) The Internet Society (2003). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, комментирующие или иным образом
разъясняющие его либо содействующие его реализации, могут подготавливаться,
копироваться, публиковаться и распространяться полностью или частично,
без каких-либо ограничений, при условии, что приведённое выше уведомление
об авторских правах и этот абзац включены во все такие копии и производные
работы. Однако сам этот документ не может быть каким-либо образом изменён,
например путём удаления уведомления об авторских правах или ссылок на
Internet Society либо другие интернет-организации, за исключением случаев,
когда это необходимо для разработки интернет-стандартов, в котором случае
должны соблюдаться процедуры для авторских прав, определённые процессом
разработки Internet Standards, или когда это требуется для его перевода на
языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не
будут отозваны Internet Society либо её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
"AS IS", И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО
ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ
ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ
ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.
Inamura, et al. Best Current Practice [Страница 26]
Network Working Group H. Inamura, Ed.
Request for Comments: 3481 NTT DoCoMo, Inc.
BCP: 71 G. Montenegro, Ed.
Category: Best Current Practice Sun Microsystems Laboratories
Europe
R. Ludwig
Ericsson Research
A. Gurtov
Sonera
F. Khafizov
Nortel Networks
February 2003
TCP over Second (2.5G) and Third (3G) Generation Wireless Networks
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 (2003). All Rights Reserved.
Abstract
This document describes a profile for optimizing TCP to adapt so that
it handles paths including second (2.5G) and third (3G) generation
wireless networks. It describes the relevant characteristics of 2.5G
and 3G networks, and specific features of example deployments of such
networks. It then recommends TCP algorithm choices for nodes known
to be starting or ending on such paths, and it also discusses open
issues. The configuration options recommended in this document are
commonly found in modern TCP stacks, and are widely available
standards-track mechanisms that the community considers safe for use
on the general Internet.
Inamura, et al. Best Current Practice [Page 1]
RFC 3481 TCP over 2.5G/3G February 2003
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 2.5G and 3G Link Characteristics. . . . . . . . . . . . . . . 4
2.1 Latency. . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Data Rates . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Asymmetry . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Delay Spikes . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Packet Loss Due to Corruption. . . . . . . . . . . . . . 7
2.6 Intersystem Handovers. . . . . . . . . . . . . . . . . . 7
2.7 Bandwidth Oscillation. . . . . . . . . . . . . . . . . . 7
3. Example 2.5G and 3G Deployments . . . . . . . . . . . . . . . 8
3.1 2.5G Technologies: GPRS, HSCSD and CDMA2000 1XRTT. . . . 8
3.2 A 3G Technology: W-CDMA. . . . . . . . . . . . . . . . . 8
3.3 A 3G Technology: CDMA2000 1X-EV. . . . . . . . . . . . . 10
4. TCP over 2.5G and 3G. . . . . . . . . . . . . . . . . . . . . 10
4.1 Appropriate Window Size (Sender & Receiver). . . . . . . 11
4.2 Increased Initial Window (Sender). . . . . . . . . . . . 11
4.3 Limited Transmit (Sender). . . . . . . . . . . . . . . . 12
4.4 IP MTU Larger than Default . . . . . . . . . . . . . . . 12
4.5 Path MTU Discovery (Sender & Intermediate Routers) . . . 13
4.6 Selective Acknowledgments (Sender & Receiver). . . . . . 13
4.7 Explicit Congestion Notification (Sender, Receiver &
Intermediate Routers). . . . . . . . . . . . . . . . . . 13
4.8 TCP Timestamps Option (Sender & Receiver). . . . . . . . 13
4.9 Disabling RFC 1144 TCP/IP Header Compression (Wireless
Host) . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. Normative References . . . . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . . 21
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
Inamura, et al. Best Current Practice [Page 2]
RFC 3481 TCP over 2.5G/3G February 2003
1. Introduction
The second generation cellular systems are commonly referred to as
2G. The 2G phase began in the 1990s when digital voice encoding had
replaced analog systems (1G). 2G systems are based on various radio
technologies including frequency-, code- and time- division multiple
access. Examples of 2G systems include GSM (Europe), PDC (Japan),
and IS-95 (USA). Data links provided by 2G systems are mostly
circuit-switched and have transmission speeds of 10-20 kbps uplink
and downlink. Demand for higher data rates, instant availability and
data volume-based charging, as well as lack of radio spectrum
allocated for 2G led to the introduction of 2.5G (for example, GPRS
and PDC-P) and 3G (for example, Wideband CDMA and cdma2000) systems.
Radio technology for both Wideband CDMA (W-CDMA) (adopted, for
example, in Europe, Japan, etc) and cdma2000 (adopted, for example,
in US, South Korea, etc) is based on code division multiple access
allowing for higher data rates and more efficient spectrum
utilization than 2G systems. 3G systems provide both packet-switched
and circuit-switched connectivity in order to address the quality of
service requirements of conversational, interactive, streaming, and
bulk transfer applications. The transition to 3G is expected to be a
gradual process. Initially, 3G will be deployed to introduce high
capacity and high speed access in densely populated areas. Mobile
users with multimode terminals will be able to utilize existing
coverage of 2.5G systems on the rest of territory.
Much development and deployment activity has centered around 2.5G and
3G technologies. Along with objectives like increased capacity for
voice channels, a primary motivation for these is data communication,
and, in particular, Internet access. Accordingly, key issues are TCP
performance and the several techniques which can be applied to
optimize it over different wireless environments [19].
This document proposes a profile of such techniques, (particularly
effective for use with 2.5G and 3G wireless networks). The
configuration options in this document are commonly found in modern
TCP stacks, and are widely available IETF standards-track mechanisms
that the community has judged to be safe on the general Internet
(that is, even in predominantly non-wireless scenarios).
Furthermore, this document makes one set of recommendations that
covers both 2.5G and 3G networks. Since both generations of wireless
technologies exhibit similar challenges to TCP performance (see
Section 2), one common set is warranted.
Inamura, et al. Best Current Practice [Page 3]
RFC 3481 TCP over 2.5G/3G February 2003
Two example applications of the recommendations in this document are:
o The WAP Forum [25] (part of the Open Mobile Alliance [26] as of
June 2002) is an industry association that has developed standards
for wireless information and telephony services on digital mobile
phones. In order to address WAP functionality for higher speed
networks such as 2.5G and 3G networks, and to aim at convergence
with Internet standards, the WAP Forum thoroughly revised its
specifications. The resultant version 2.0 [31] adopts TCP as its
transport protocol, and recommends TCP optimization mechanisms
closely aligned with those described in this document.
o I-mode [33] is a wireless Internet service deployed on handsets in
Japan. The newer version of i-mode runs on FOMA [34], an
implementation of W-CDMA. I-mode over FOMA deploys the profile of
TCP described in this document.
This document is structured as follows: Section 2 reviews the link
layer characteristics of 2.5G/3G networks; Section 3 gives a brief
overview of some representative 2.5G/3G technologies like W-CDMA,
cdma2000 and GPRS; Section 4 recommends mechanisms and configuration
options for TCP implementations used in 2.5G/3G networks, including a
summary in chart form at the end of the section; finally, Section 5
discusses some open issues.
2. 2.5G and 3G Link Characteristics
Link layer characteristics of 2.5G/3G networks have significant
effects on TCP performance. In this section we present various
aspects of link characteristics unique to the 2.5G/3G networks.
2.1 Latency
The latency of 2.5G/3G links is high mostly due to the extensive
processing required at the physical layer of those networks, e.g.,
for FEC and interleaving, and due to transmission delays in the radio
access network [58] (including link-level retransmissions). A
typical RTT varies between a few hundred milliseconds and one second.
The associated radio channels suffer from difficult propagation
environments. Hence, powerful but complex physical layer techniques
need to be applied to provide high capacity in a wide coverage area
in a resource efficient way. Hopefully, rapid improvements in all
areas of wireless networks ranging from radio layer techniques over
signal processing to system architecture will ultimately also lead to
reduced delays in 3G wireless systems.
Inamura, et al. Best Current Practice [Page 4]
RFC 3481 TCP over 2.5G/3G February 2003
2.2 Data Rates
The main incentives for transition from 2G to 2.5G to 3G are the
increase in voice capacity and in data rates for the users. 2.5G
systems have data rates of 10-20 kbps in uplink and 10-40 kbps in
downlink. Initial 3G systems are expected to have bit rates around
64 kbps in uplink and 384 kbps in downlink. Considering the
resulting bandwidth-delay product (BDP) of around 1-5 KB for 2.5G and
8-50 KB for 3G, 2.5G links can be considered LTNs (Long Thin Networks
[19]), and 3G links approach LFNs (Long Fat Networks [2], as
exemplified by some satellite networks [48]). Accordingly,
interested readers might find related and potentially relevant issues
discussed in RFC 2488 [49]. For good TCP performance both LFNs and
LTNs require maintaining a large enough window of outstanding data.
For LFNs, utilizing the available network bandwidth is of particular
concern. LTNs need a sufficiently large window for efficient loss
recovery. In particular, the fast retransmit algorithm cannot be
triggered if the window is less than four segments. This leads to a
lengthy recovery through retransmission timeouts. The Limited
Transmit algorithm RFC 3042 [10] helps avoid the deleterious effects
of timeouts on connections with small windows. Nevertheless, making
full use of the SACK RFC 2018 [3] information for loss recovery in
both LFNs and LTNs may require twice the window otherwise sufficient
to utilize the available bandwidth.
This document recommends only standard mechanisms suitable both for
LTNs and LFNs, and to any network in general. However, experimental
mechanisms suggested in Section 5 can be targeted either for LTNs
[19] or LFNs [48].
Data rates are dynamic due to effects from other users and from
mobility. Arriving and departing users can reduce or increase the
available bandwidth in a cell. Increasing the distance from the base
station decreases the link bandwidth due to reduced link quality.
Finally, by simply moving into another cell the user can experience a
sudden change in available bandwidth. For example, if upon changing
cells a connection experiences a sudden increase in available
bandwidth, it can underutilize it, because during congestion
avoidance TCP increases the sending rate slowly. Changing from a
fast to a slow cell normally is handled well by TCP due to the self-
clocking property. However, a sudden increase in RTT in this case
can cause a spurious TCP timeout as described in Section 2.7. In
addition, a large TCP window used in the fast cell can create
congestion resulting in overbuffering in the slow cell.
Inamura, et al. Best Current Practice [Page 5]
RFC 3481 TCP over 2.5G/3G February 2003
2.3 Asymmetry
2.5G/3G systems may run asymmetric uplink and downlink data rates.
The uplink data rate is limited by battery power consumption and
complexity limitations of mobile terminals. However, the asymmetry
does not exceed 3-6 times, and can be tolerated by TCP without the
need for techniques like ACK congestion control or ACK filtering
[50]. Accordingly, this document does not include recommendations
meant for such highly asymmetric networks.
2.4 Delay Spikes
A delay spike is a sudden increase in the latency of the
communication path. 2.5G/3G links are likely to experience delay
spikes exceeding the typical RTT by several times due to the
following reasons.
1. A long delay spike can occur during link layer recovery from a
link outage due to temporal loss of radio coverage, for example,
while driving into a tunnel or within an elevator.
2. During a handover the mobile terminal and the new base station
must exchange messages and perform some other time-consuming
actions before data can be transmitted in a new cell.
3. Many wide area wireless networks provide seamless mobility by
internally re-routing packets from the old to the new base station
which may cause extra delay.
4. Blocking by high-priority traffic may occur when an arriving
circuit-switched call or higher priority data temporarily preempts
the radio channel. This happens because most current terminals
are not able to handle a voice call and a data connection
simultaneously and suspend the data connection in this case.
5. Additionally, a scheduler in the radio network can suspend a low-
priority data transfer to give the radio channel to higher
priority users.
Delay spikes can cause spurious TCP timeouts, unnecessary
retransmissions and a multiplicative decrease in the congestion
window size.
Inamura, et al. Best Current Practice [Page 6]
RFC 3481 TCP over 2.5G/3G February 2003
2.5 Packet Loss Due to Corruption
Even in the face of a high probability of physical layer frame
errors, 2.5G/3G systems have a low rate of packet losses thanks to
link-level retransmissions. Justification for link layer ARQ is
discussed in [23], [22], [44]. In general, link layer ARQ and FEC
can provide a packet service with a negligibly small probability of
undetected errors (failures of the link CRC), and a low level of loss
(non-delivery) for the upper layer traffic, e.g., IP. The loss rate
of IP packets is low due to the ARQ, but the recovery at the link
layer appears as delay jitter to the higher layers lengthening the
computed RTO value.
2.6 Intersystem Handovers
In the initial phase of deployment, 3G systems will be used as a 'hot
spot' technology in high population areas, while 2.5G systems will
provide lower speed data service elsewhere. This creates an
environment where a mobile user can roam between 2.5G and 3G networks
while keeping ongoing TCP connections. The inter-system handover is
likely to trigger a high delay spike (Section 2.4), and can result in
data loss. Additional problems arise because of context transfer,
which is out of scope of this document, but is being addressed
elsewhere in the IETF in activities addressing seamless mobility
[51].
Intersystem handovers can adversely affect ongoing TCP connections
since features may only be negotiated at connection establishment and
cannot be changed later. After an intersystem handover, the network
characteristics may be radically different, and, in fact, may be
negatively affected by the initial configuration. This point argues
against premature optimization by the TCP implementation.
2.7 Bandwidth Oscillation
Given the limited RF spectrum, satisfying the high data rate needs of
2.5G/3G wireless systems requires dynamic resource sharing among
concurrent data users. Various scheduling mechanisms can be deployed
in order to maximize resource utilization. If multiple users wish to
transfer large amounts of data at the same time, the scheduler may
have to repeatedly allocate and de-allocate resources for each user.
We refer to periodic allocation and release of high-speed channels as
Bandwidth Oscillation. Bandwidth Oscillation effects such as
spurious retransmissions were identified elsewhere (e.g., [30]) as
factors that degrade throughput. There are research studies [52],
[54], which show that in some cases Bandwidth Oscillation can be the
single most important factor in reducing throughput. For fixed TCP
parameters the achievable throughput depends on the pattern of
Inamura, et al. Best Current Practice [Page 7]
RFC 3481 TCP over 2.5G/3G February 2003
resource allocation. When the frequency of resource allocation and
de-allocation is sufficiently high, there is no throughput
degradation. However, increasing the frequency of resource
allocation/de-allocation may come at the expense of increased
signaling, and, therefore, may not be desirable. Standards for 3G
wireless technologies provide mechanisms that can be used to combat
the adverse effects of Bandwidth Oscillation. It is the consensus of
the PILC Working Group that the best approach for avoiding adverse
effects of Bandwidth Oscillation is proper wireless sub-network
design [23].
3. Example 2.5G and 3G Deployments
This section provides further details on a few example 2.5G/3G
technologies. The objective is not completeness, but merely to
discuss some representative technologies and the issues that may
arise with TCP performance. Other documents discuss the underlying
technologies in more detail. For example, ARQ and FEC are discussed
in [23], while further justification for link layer ARQ is discussed
in [22], [44].
3.1 2.5G Technologies: GPRS, HSCSD and CDMA2000 1XRTT
High Speed Circuit-Switched Data (HSCSD) and General Packet Radio
Service (GPRS) are extensions of GSM providing high data rates for a
user. Both extensions were developed first by ETSI and later by
3GPP. In GSM, a user is assigned one timeslot downlink and one
uplink. HSCSD allocates multiple timeslots to a user creating a fast
circuit-switched link. GPRS is based on packet-switched technology
that allows efficient sharing of radio resources among users and
always-on capability. Several terminals can share timeslots. A GPRS
network uses an updated base station subsystem of GSM as the access
network; the GPRS core network includes Serving GPRS Support Nodes
(SGSN) and Gateway GPRS Support Nodes (GGSN). The RLC protocol
operating between a base station controller and a terminal provides
ARQ capability over the radio link. The Logical Link Control (LLC)
protocol between the SGSN and the terminal also has an ARQ capability
utilized during handovers.
3.2 A 3G Technology: W-CDMA
The International Telecommunication Union (ITU) has selected Wideband
Code Division Multiple Access (W-CDMA) as one of the global telecom
systems for the IMT-2000 3G mobile communications standard. W-CDMA
specifications are created in the 3rd Generation Partnership Project
(3GPP).
Inamura, et al. Best Current Practice [Page 8]
RFC 3481 TCP over 2.5G/3G February 2003
The link layer characteristics of the 3G network which have the
largest effect on TCP performance over the link are error controlling
schemes such as layer two ARQ (L2 ARQ) and FEC (forward error
correction).
W-CDMA uses RLC (Radio Link Control) [20], a Selective Repeat and
sliding window ARQ. RLC uses protocol data units (PDUs) with a 16
bit RLC header. The size of the PDUs may vary. Typically, 336 bit
PDUs are implemented [34]. This is the unit for link layer
retransmission. The IP packet is fragmented into PDUs for
transmission by RLC. (For more fragmentation discussion, see Section
4.4.)
In W-CDMA, one to twelve PDUs (RLC frames) constitute one FEC frame,
the actual size of which depends on link conditions and bandwidth
allocation. The FEC frame is the unit of interleaving. This
accumulation of PDUs for FEC adds part of the latency mentioned in
Section 2.1.
For reliable transfer, RLC has an acknowledged mode for PDU
retransmission. RLC uses checkpoint ARQ [20] with "status report"
type acknowledgments; the poll bit in the header explicitly solicits
the peer for a status report containing the sequence number that the
peer acknowledges. The use of the poll bit is controlled by timers
and by the size of available buffer space in RLC. Also, when the
peer detects a gap between sequence numbers in received frames, it
can issue a status report to invoke retransmission. RLC preserves
the order of packet delivery.
The maximum number of retransmissions is a configurable RLC parameter
that is specified by RRC [39] (Radio Resource Controller) through RLC
connection initialization. The RRC can set the maximum number of
retransmissions (up to a maximum of 40). Therefore, RLC can be
described as an ARQ that can be configured for either HIGH-
PERSISTENCE or LOW-PERSISTENCE, not PERFECT-PERSISTENCE, according to
the terminology in [22].
Since the RRC manages RLC connection state, Bandwidth Oscillation
(Section 2.7) can be eliminated by the RRC's keeping RF resource on
an RLC connection with data in its queue. This avoids resource de-
allocation in the middle of transferring data.
In summary, the link layer ARQ and FEC can provide a packet service
with a negligibly small probability of undetected error (failure of
the link CRC), and a low level of loss (non-delivery) for the upper
layer traffic, i.e., IP. Retransmission of PDUs by ARQ introduces
latency and delay jitter to the IP flow. This is why the transport
layer sees the underlying W-CDMA network as a network with a
Inamura, et al. Best Current Practice [Page 9]
RFC 3481 TCP over 2.5G/3G February 2003
relatively large BDP (Bandwidth-Delay Product) of up to 50 KB for the
384 kbps radio bearer.
3.3 A 3G Technology: CDMA2000 1X-EV
One of the Terrestrial Radio Interface standards for 3G wireless
systems, proposed under the International Mobile Telecommunications-
2000 umbrella, is cdma2000 [55]. It employs Multi-Carrier Code
Division Multiple Access (CDMA) technology with a single-carrier RF
bandwidth of 1.25 MHz. cdma2000 evolved from IS-95 [56], a 2G
standard based on CDMA technology. The first phase of cdma2000
utilizes a single carrier and is designed to double the voice
capacity of existing CDMA (IS-95) networks and to support always-on
data transmission speeds of up to 316.8 kbps. As mentioned above,
these enhanced capabilities are delivered by cdma2000 1XRTT. 3G
speeds of 2 Mbps are offered by cdma2000 1X-EV. At the physical
layer, the standard allows transmission in 5,10,20,40 or 80 ms time
frames. Various orthogonal (Walsh) codes are used for channel
identification and to achieve higher data rates.
Radio Link Protocol Type 3 (RLP) [57] is used with a cdma2000 Traffic
Channel to support CDMA data services. RLP provides an octet stream
transport service and is unaware of higher layer framing. There are
several RLP frame formats. RLP frame formats with higher payload
were designed for higher data rates. Depending on the channel speed,
one or more RLP frames can be transmitted in a single physical layer
frame.
RLP can substantially decrease the error rate exhibited by CDMA
traffic channels [53]. When transferring data, RLP is a pure NAK-
based finite selective repeat protocol. The receiver does not
acknowledge successfully received data frames. If one or more RLP
data frames are missing, the receiving RLP makes several attempts
(called NAK rounds) to recover them by sending one or more NAK
control frames to the transmitter. Each NAK frame must be sent in a
separate physical layer frame. When RLP supplies the last NAK
control frame of a particular NAK round, a retransmission timer is
set. If the missing frame is not received when the timer expires,
RLP may try another NAK round. RLP may not recover all missing
frames. If after all RLP rounds, a frame is still missing, RLP
supplies data with a missing frame to the higher layer protocols.
4. TCP over 2.5G and 3G
What follows is a set of recommendations for configuration parameters
for protocol stacks which will be used to support TCP connections
over 2.5G and 3G wireless networks. Some of these recommendations
imply special configuration:
Inamura, et al. Best Current Practice [Page 10]
RFC 3481 TCP over 2.5G/3G February 2003
o at the data receiver (frequently a stack at or near the wireless
device),
o at the data sender (frequently a host in the Internet or possibly
a gateway or proxy at the edge of a wireless network), or
o at both.
These configuration options are commonly available IETF standards-
track mechanisms considered safe on the general Internet. System
administrators are cautioned, however, that increasing the MTU size
(Section 4.4) and disabling RFC 1144 header compression (Section 4.9)
could affect host efficiency, and that changing such parameters
should be done with care.
4.1 Appropriate Window Size (Sender & Receiver)
TCP over 2.5G/3G should support appropriate window sizes based on the
Bandwidth Delay Product (BDP) of the end-to-end path (see Section
2.2). The TCP specification [14] limits the receiver window size to
64 KB. If the end-to-end BDP is expected to be larger than 64 KB,
the window scale option [2] can be used to overcome that limitation.
Many operating systems by default use small TCP receive and send
buffers around 16KB. Therefore, even for a BDP below 64 KB, the
default buffer size setting should be increased at the sender and at
the receiver to allow a large enough window.
4.2 Increased Initial Window (Sender)
TCP controls its transmit rate using the congestion window mechanism.
The traditional initial window value of one segment, coupled with the
delayed ACK mechanism [17] implies unnecessary idle times in the
initial phase of the connection, including the delayed ACK timeout
(typically 200 ms, but potentially as much as 500 ms) [4]. Senders
can avoid this by using a larger initial window of up to four
segments (not to exceed roughly 4 KB) [4]. Experiments with
increased initial windows and related measurements have shown (1)
that it is safe to deploy this mechanism (i.e., it does not lead to
congestion collapse), and (2) that it is especially effective for the
transmission of a few TCP segments' worth of data (which is the
behavior commonly seen in such applications as Internet-enabled
mobile wireless devices). For large data transfers, on the other
hand, the effect of this mechanism is negligible.
TCP over 2.5G/3G SHOULD set the initial CWND (congestion window)
according to Equation 1 in [4]:
min (4*MSS, max (2*MSS, 4380 bytes))
Inamura, et al. Best Current Practice [Page 11]
RFC 3481 TCP over 2.5G/3G February 2003
This increases the permitted initial window from one to between two
and four segments (not to exceed approximately 4 KB).
4.3 Limited Transmit (Sender)
RFC 3042 [10], Limited Transmit, extends Fast Retransmit/Fast
Recovery for TCP connections with small congestion windows that are
not likely to generate the three duplicate acknowledgements required
to trigger Fast Retransmit [1]. If a sender has previously unsent
data queued for transmission, the limited transmit mechanism calls
for sending a new data segment in response to each of the first two
duplicate acknowledgments that arrive at the sender. This mechanism
is effective when the congestion window size is small or if a large
number of segments in a window are lost. This may avoid some
retransmissions due to TCP timeouts. In particular, some studies
[10] have shown that over half of a busy server's retransmissions
were due to RTO expiration (as opposed to Fast Retransmit), and that
roughly 25% of those could have been avoided using Limited Transmit.
Similar to the discussion in Section 4.2, this mechanism is useful
for small amounts of data to be transmitted. TCP over 2.5G/3G
implementations SHOULD implement Limited Transmit.
4.4 IP MTU Larger than Default
The maximum size of an IP datagram supported by a link layer is the
MTU (Maximum Transfer Unit). The link layer may, in turn, fragment
IP datagrams into PDUs. For example, on links with high error rates,
a smaller link PDU size increases the chance of successful
transmission. With layer two ARQ and transparent link layer
fragmentation, the network layer can enjoy a larger MTU even in a
relatively high BER (Bit Error Rate) condition. Without these
features in the link, a smaller MTU is suggested.
TCP over 2.5G/3G should allow freedom for designers to choose MTU
values ranging from small values (such as 576 bytes) to a large value
that is supported by the type of link in use (such as 1500 bytes for
IP packets on Ethernet). Given that the window is counted in units
of segments, a larger MTU allows TCP to increase the congestion
window faster [5]. Hence, designers are generally encouraged to
choose larger values. These may exceed the default IP MTU values of
576 bytes for IPv4 RFC 1191 [6] and 1280 bytes for IPv6 [18]. While
this recommendation is applicable to 3G networks, operation over 2.5G
networks should exercise caution as per the recommendations in RFC
3150 [5].
Inamura, et al. Best Current Practice [Page 12]
RFC 3481 TCP over 2.5G/3G February 2003
4.5 Path MTU Discovery (Sender & Intermediate Routers)
Path MTU discovery allows a sender to determine the maximum end-to-
end transmission unit (without IP fragmentation) for a given routing
path. RFC 1191 [6] and RFC 1981 [8] describe the MTU discovery
procedure for IPv4 and IPv6, respectively. This allows TCP senders
to employ larger segment sizes (without causing IP layer
fragmentation) instead of assuming the small default MTU. TCP over
2.5G/3G implementations should implement Path MTU Discovery. Path
MTU Discovery requires intermediate routers to support the generation
of the necessary ICMP messages. RFC 1435 [7] provides
recommendations that may be relevant for some router implementations.
4.6 Selective Acknowledgments (Sender & Receiver)
The selective acknowledgment option (SACK), RFC 2018 [3], is
effective when multiple TCP segments are lost in a single TCP window
[24]. In particular, if the end-to-end path has a large BDP and a
high packet loss rate, the probability of multiple segment losses in
a single window of data increases. In such cases, SACK provides
robustness beyond TCP-Tahoe and TCP-Reno [21]. TCP over 2.5G/3G
SHOULD support SACK.
In the absence of SACK feature, the TCP should use NewReno RFC 2582
[15].
4.7 Explicit Congestion Notification (Sender, Receiver & Intermediate
Routers)
Explicit Congestion Notification, RFC 3168 [9], allows a TCP receiver
to inform the sender of congestion in the network by setting the
ECN-Echo flag upon receiving an IP packet marked with the CE bit(s).
The TCP sender will then reduce its congestion window. Thus, the use
of ECN is believed to provide performance benefits [32], [43]. RFC
3168 [9] also places requirements on intermediate routers (e.g.,
active queue management and setting of the CE bit(s) in the IP header
to indicate congestion). Therefore, the potential improvement in
performance can only be achieved when ECN capable routers are
deployed along the path. TCP over 2.5G/3G SHOULD support ECN.
4.8 TCP Timestamps Option (Sender & Receiver)
Traditionally, TCPs collect one RTT sample per window of data [14],
[17]. This can lead to an underestimation of the RTT, and spurious
timeouts on paths in which the packet transmission delay dominates
the RTT. This holds despite a conservative retransmit timer such as
the one specified in RFC 2988 [11]. TCP connections with large
windows may benefit from more frequent RTT samples provided with
Inamura, et al. Best Current Practice [Page 13]
RFC 3481 TCP over 2.5G/3G February 2003
timestamps by adapting quicker to changing network conditions [2].
However, there is some empirical evidence that for TCPs with an RFC
2988 timer [11], timestamps provide little or no benefits on backbone
Internet paths [59]. Using the TCP Timestamps option has the
advantage that retransmitted segments can be used for RTT
measurement, which is otherwise forbidden by Karn's algorithm [17],
[11]. Furthermore, the TCP Timestamps option is the basis for
detecting spurious retransmits using the Eifel algorithm [30].
A 2.5/3G link (layer) is dedicated to a single host. It therefore
only experiences a low degree of statistical multiplexing between
different flows. Also, the packet transmission and queuing delays of
a 2.5/3G link often dominate the path's RTT. This already results in
large RTT variations as packets fill the queue while a TCP sender
probes for more bandwidth, or as packets drain from the queue while a
TCP sender reduces its load in response to a packet loss. In
addition, the delay spikes across a 2.5/3G link (see Section 2.4) may
often exceed the end-to-end RTT. The thus resulting large variations
in the path's RTT may often cause spurious timeouts.
When running TCP in such an environment, it is therefore advantageous
to sample the path's RTT more often than only once per RTT. This
allows the TCP sender to track changes in the RTT more closely. In
particular, a TCP sender can react more quickly to sudden increases
of the RTT by sooner updating the RTO to a more conservative value.
The TCP Timestamps option [2] provides this capability, allowing the
TCP sender to sample the RTT from every segment that is acknowledged.
Using timestamps in the mentioned scenario leads to a more
conservative TCP retransmission timer and reduces the risk of
triggering spurious timeouts [45], [52], [54], [60].
There are two problematic issues with using timestamps:
o 12 bytes of overhead are introduced by carrying the TCP Timestamps
option and padding in the TCP header. For a small MTU size, it
can present a considerable overhead. For example, for an MTU of
296 bytes the added overhead is 4%. For an MTU of 1500 bytes, the
added overhead is only 0.8%.
o Current TCP header compression schemes are limited in their
handling of the TCP options field. For RFC 2507 [13], any change
in the options field (caused by timestamps or SACK, for example)
renders the entire field uncompressible (leaving the TCP/IP header
itself compressible, however). Even worse, for RFC 1144 [40] such
a change in the options field effectively disables TCP/IP header
compression altogether. This is the case when a connection uses
the TCP Timestamps option. That option field is used both in the
data and the ACK path, and its value typically changes from one
Inamura, et al. Best Current Practice [Page 14]
RFC 3481 TCP over 2.5G/3G February 2003
packet to the next. The IETF is currently specifying a robust
TCP/IP header compression scheme with better support for TCP
options [29].
The original definition of the timestamps option [2] specifies that
duplicate segments below cumulative ACK do not update the cached
timestamp value at the receiver. This may lead to overestimating of
RTT for retransmitted segments. A possible solution [47] allows the
receiver to use a more recent timestamp from a duplicate segment.
However, this suggestion allows for spoofing attacks against the TCP
receiver. Therefore, careful consideration is needed in
implementing this solution.
Recommendation: TCP SHOULD use the TCP Timestamps option. It allows
for better RTT estimation and reduces the risk of spurious timeouts.
4.9 Disabling RFC 1144 TCP/IP Header Compression (Wireless Host)
It is well known (and has been shown with experimental data) that RFC
1144 [40] TCP header compression does not perform well in the
presence of packet losses [43], [52]. If a wireless link error is
not recovered, it will cause TCP segment loss between the compressor
and decompressor, and then RFC 1144 header compression does not allow
TCP to take advantage of Fast Retransmit Fast Recovery mechanism.
The RFC 1144 header compression algorithm does not transmit the
entire TCP/IP headers, but only the changes in the headers of
consecutive segments. Therefore, loss of a single TCP segment on the
link causes the transmitting and receiving TCP sequence numbers to
fall out of synchronization. Hence, when a TCP segment is lost
after the compressor, the decompressor will generate false TCP
headers. Consequently, the TCP receiver will discard all remaining
packets in the current window because of a checksum error. This
continues until the compressor receives the first retransmission
which is forwarded uncompressed to synchronize the decompressor [40].
As previously recommended in RFC 3150 [5], RFC 1144 header
compression SHOULD NOT be enabled unless the packet loss probability
between the compressor and decompressor is very low. Actually,
enabling the Timestamps Option effectively accomplishes the same
thing (see Section 4.8). Other header compression schemes like RFC
2507 [13] and Robust Header Compression [12] are meant to address
deficiencies in RFC 1144 header compression. At the time of this
writing, the IETF was working on multiple extensions to Robust Header
Compression (negotiating Robust Header Compression over PPP,
compressing TCP options, etc) [16].
Inamura, et al. Best Current Practice [Page 15]
RFC 3481 TCP over 2.5G/3G February 2003
4.10 Summary
Items Comments
----------------------------------------------------------------
Appropriate Window Size (sender & receiver)
based on end-to-end BDP
Window Scale Option (sender & receiver)
[RFC1323] Window size > 64KB
Increased Initial Window (sender)
[RFC3390] CWND = min (4*MSS,
max (2*MSS, 4380 bytes))
Limited Transmit (sender)
[RFC3042]
IP MTU larger than more applicable to 3G
Default
Path MTU Discovery (sender & intermediate routers)
[RFC1191,RFC1981]
Selective Acknowledgment
option (SACK)
[RFC2018] (sender & receiver)
Explicit Congestion
Notification(ECN)
[RFC3168] (sender, receiver &
intermediate routers)
Timestamps Option (sender & receiver)
[RFC1323, R.T.Braden's ID]
Disabling RFC1144
TCP/IP Header Compression
[RFC1144] (wireless host)
5. Open Issues
This section outlines additional mechanisms and parameter settings
that may increase end-to-end performance when running TCP across
2.5G/3G networks. Note, that apart from the discussion of the RTO's
initial value, those mechanisms and parameter settings are not part
of any standards track RFC at the time of this writing. Therefore,
they cannot be recommended for the Internet in general.
Inamura, et al. Best Current Practice [Page 16]
RFC 3481 TCP over 2.5G/3G February 2003
Other mechanisms for increasing TCP performance include enhanced TCP/
IP header compression schemes [29], active queue management RFC 2309
[28], link layer retransmission schemes [23], and caching packets
during transient link outages to retransmit them locally when the
link is restored to operation [23].
Shortcomings of existing TCP/IP header compression schemes (RFC 1144
[40], RFC 2507 [13]) are that they do not compress headers of
handshaking packets (SYNs and FINs), and that they lack proper
handling of TCP option fields (e.g., SACK or timestamps) (see Section
4.8). Although RFC 3095 [12] does not yet address this issue, the
IETF is developing improved TCP/IP header compression schemes,
including better handling of TCP options such as timestamps and
selective acknowledgements. Especially, if many short-lived TCP
connections run across the link, the compression of the handshaking
packets may greatly improve the overall header compression ratio.
Implementing active queue management is attractive for a number of
reasons as outlined in RFC 2309 [28]. One important benefit for
2.5G/ 3G networks, is that it minimizes the amount of potentially
stale data that may be queued in the network ("clicking from page to
page" before the download of the previous page is complete).
Avoiding the transmission of stale data across the 2.5G/3G radio link
saves transmission (battery) power, and increases the ratio of useful
data over total data transmitted. Another important benefit of
active queue management for 2.5G/3G networks, is that it reduces the
risk of a spurious timeout for the first data segment as outlined
below.
Since 2.5G/3G networks are commonly characterized by high delays,
avoiding unecessary round-trip times is particularly attractive.
This is specially beneficial for short-lived, transactional (request/
response-style) TCP sessions that typically result from browsing the
Web from a smart phone. However, existing solutions such as T/TCP
RFC 1644 [27], have not been adopted due to known security concerns
[38].
Spurious timeouts, packet re-ordering, and packet duplication may
reduce TCP's performance. Thus, making TCP more robust against those
events is desirable. Solutions to this problem have been proposed
[30], [35], [41], and standardization work within the IETF is ongoing
at the time of writing. Those solutions include reverting congestion
control state after such an event has been detected, and adapting the
retransmission timer and duplicate acknowledgement threshold. The
deployment of such solutions may be particularly beneficial when
running TCP across wireless networks because wireless access links
may often be subject to handovers and resource preemption, or the
mobile transmitter may traverse through a radio coverage hole. Such
Inamura, et al. Best Current Practice [Page 17]
RFC 3481 TCP over 2.5G/3G February 2003
disrupting events may easily trigger a spurious timeout despite a
conservative retransmission timer. Also, the mobility mechanisms of
some wireless networks may cause packet duplication.
The algorithm for computing TCP's retransmission timer is specified
in RFC 2988 [11]. The standard specifies that the initial setting of
the retransmission timeout value (RTO) should not be less than 3
seconds. This value might be too low when running TCP across 2.5G/3G
networks. In addition to its high latencies, those networks may be
run at bit rates of as low as about 10 kb/s which results in large
packet transmission delays. In this case, the RTT for the first data
segment may easily exceed the initial TCP retransmission timer
setting of 3 seconds. This would then cause a spurious timeout for
that segment. Hence, in such situations it may be advisable to set
TCP's initial RTO to a value larger than 3 seconds. Furthermore, due
to the potentially large packet transmission delays, a TCP sender
might choose to refrain from initializing its RTO from the RTT
measured for the SYN, but instead take the RTT measured for the first
data segment.
Some of the recommendations in RFC 2988 [11] are optional, and are
not followed by all TCP implementations. Specifically, some TCP
stacks allow a minimum RTO less than the recommended value of 1
second (section 2.4 of [11]), and some implementations do not
implement the recommended restart of the RTO timer when an ACK is
received (section 5.3 of [11]). Some experiments [52], [54], have
shown that in the face of bandwidth oscillation, using the
recommended minimum RTO value of 1 sec (along with the also
recommended initial RTO of 3 sec) reduces the number of spurious
retransmissions as compared to using small minimum RTO values of 200
or 400 ms. Furthermore, TCP stacks that restart the retransmission
timer when an ACK is received experience far less spurious
retransmissions than implementations that do not restart the RTO
timer when an ACK is received. Therefore, at the time of this
writing, it seems preferable for TCP implementations used in 3G
wireless data transmission to comply with all recommendations of RFC
2988.
6. Security Considerations
In 2.5G/3G wireless networks, data is transmitted as ciphertext over
the air and as cleartext between the Radio Access Network (RAN) and
the core network. IP security RFC 2401 [37] or TLS RFC 2246 [36] can
be deployed by user devices for end-to-end security.
7. IANA Considerations
This specification requires no IANA actions.
Inamura, et al. Best Current Practice [Page 18]
RFC 3481 TCP over 2.5G/3G February 2003
8. Acknowledgements
The authors would like to acknowledge contributions to the text from
the following individuals:
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)
The authors gratefully acknowledge the valuable advice from the
following individuals:
Gorry Fairhurst (gorry@erg.abdn.ac.uk)
Mark Allman (mallman@grc.nasa.gov)
Aaron Falk (falk@ISI.EDU)
9. Normative References
[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.
Inamura, et al. Best Current Practice [Page 19]
RFC 3481 TCP over 2.5G/3G February 2003
[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.
Inamura, et al. Best Current Practice [Page 20]
RFC 3481 TCP over 2.5G/3G February 2003
10. Informative References
[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>.
Inamura, et al. Best Current Practice [Page 21]
RFC 3481 TCP over 2.5G/3G February 2003
[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.
Inamura, et al. Best Current Practice [Page 22]
RFC 3481 TCP over 2.5G/3G February 2003
[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.
Inamura, et al. Best Current Practice [Page 23]
RFC 3481 TCP over 2.5G/3G February 2003
[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.
Inamura, et al. Best Current Practice [Page 24]
RFC 3481 TCP over 2.5G/3G February 2003
11. Authors' Addresses
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
Inamura, et al. Best Current Practice [Page 25]
RFC 3481 TCP over 2.5G/3G February 2003
12. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Inamura, et al. Best Current Practice [Page 26]