Протокол передачи команд и сообщений об ошибках (ICMP). Протоколы DCCP и TFRC

3.1. Протокол управления перегрузкой для дейтаграмм DCCP

Введение

Протокол DCCP (Datagram Congestion Control Protocol) является транспортным протоколом, который использует двунаправленные уникастные соединения с управлением перегрузкой для ненадежной доставки дейтаграмм. Протокол DCCP предназначен для приложений, которые реализуют поточную схему TCP, но имеют приоритет для своевременной доставки данных с сохранением порядка кадров или требуют надежности, или для приложений, которые требуют механизма подавления перегрузки, отличного от TCP. До настоящего времени такие приложения использовали либо TCP, чья надежность и гарантия упорядочения доставки давалась за счет неопределенно большой задержки, либо UDP и независимый механизм управления перегрузкой (или вообще с отсутствием подавления перегрузки). Протокол DCCP будет предоставлять стандартный способ управления перегрузкой и позволит применять механизм ECN.

Протокол DCCP предназначен для приложений, которые не требуют параметров SCTP [RFC-2960], таких, как упорядоченная доставка при нескольких потоках.

Протокол UDP исключает большие задержки, но приложения UDP, которые используют управление перегрузкой, вынуждены вносить задержки сами. Протокол DCCP имеет встроенную систему управления перегрузкой, включая поддержку ECN для ненадежных потоков дейтаграмм и исключая непредсказуемые задержки, характерные для TCP. Протокол DCCP обеспечивает надежное согласование параметров при установлении соединения.

Одной из целей DCCP было максимальное облегчение для UDP приложений перехода на DCCP, когда он будет внедрен. Чтобы облегчить это, DCCP был спроектирован с минимальной избыточностью как с точки зрения размера заголовка пакета, так и с позиции загрузки ЦПУ машин партнеров. В DCCP была включена минимальная функциональность, при сохранении возможности включения новых функций, таких, как FEC (forward error correction), псевдонадежность и множественные потоки, которые могут быть добавлены поверх DCCP, если потребуется.

Возможны разные механизмы управления перегрузкой для разных приложений. Например, игры реального времени могут требовать быстрого использования всей доступной полосы пропускания, в то время как потоковая среда может использовать компромисс между скоростью отклика и стабильной, менее импульсивной передачей. (Резкое изменение потока может вызвать неприемлемые сбои UI, такие, как слышимые паузы или щелчки). Протокол DCCP, таким образом, предлагает приложению выбор одного из нескольких механизмов управления перегрузкой. Одной из альтернатив является TCP-подобное управление перегрузкой, сокращение вдвое окна перегрузки в ответ на потерю пакета. Приложения, применяющие механизм управления перегрузкой, будут быстро реагировать на изменения доступной полосы, но должны выдерживать резкое изменение окна перегрузки, что типично для TCP. Вторую альтернативу представляет механизм управления скоростью передачи, дружественный по отношению TCP (TFRC) [RFC-3448]. Это алгоритм управления перегрузкой, базирующийся на уравнении, минимизирует резкие изменения скорости передачи.

Протокол DCCP позволяет также ненадежному трафику без проблем использовать технику ECN. Ядро UDP API не может позволить приложениям считать UDP пакеты адаптированными к ECN, так как API не может гарантировать, что приложение способно корректно детектировать или реагировать на перегрузку. Ядро DCCP API лишено такого недостатка, так как имеет встроенный механизм управления перегрузкой.

В DCCP было решено не применять менеджер управления перегрузкой [RFC-3124], который допускает несколько одновременных потоков между отправителем и получателем. Менеджер перегрузки может быть использован только приложениями, которые имеют свою собственную обратную связь в случае потери пакетов между конечными точками соединения, но этого нет во многих приложениях, работающих с UDP. Кроме того, сегодняшний вариант менеджера перегрузки, как правило, не поддерживает более одного механизма управления перегрузкой. DCCP должен быть способен использовать механизм управления перегрузкой там, где это требуется приложению.

Предполагается, что протокольные механизмы DCCP, будут адаптированы к любому приложению, требующему уникастных потоков с управлением перегрузки. Механизмы управления перегрузкой, встраиваемые в DCCP, описаны в отдельных ID профайлах управления [CCID 2 PROFILE, CCID 3 PROFILE], они могут, однако вызвать проблемы для некоторых приложений, включая широкополосное интерактивное видео. Эти приложения должны быть способны задействовать DCCP, когда будут стандартизованы подходящие ID профайлы управления перегрузкой.

Протокол DCCP имеет следующие характеристики:

Основные отличия DCCP от TCP

Ниже рассмотрены наиболее существенные отличия DCCP от TCP.

Основные понятия и термины

Каждое DCCP соединение реализуется между двумя партнерами, которые будут называться DCCP A и DCCP B. Данные могут передаваться в обоих направлениях. В рамках протокола рассматриваются субнаборы соединений, называемых полусоединениями (halfconnection - HC). (Смотри рис. 3.12.) Эти полусоединения обеспечивают передачу информационных пакетов в одном направлении плюс соответствующих подтверждений в противоположном направлении. В контексте одного полусоединения HC-отправитель является партнером отправителем данных, в то время как HC-Receiver является партнером, посылающим подтверждения. Каждое полусоединение контролируется механизмом управления перегрузкой, специфицированным однобайтовым идентификатором, или CCID. Партнеры согласуют режим обмена на фазе формирования соединения. CCID для полусоединения описывает, как HCотправитель ограничивает поток информационных пакетов; как он поддерживает необходимые значения параметров, такие, как окна перегрузки; как HC-получатель уведомляет отправителя о перегрузке, посылая подтверждения; и как он поддерживает частоту подтверждений.

Инициация и разрыв соединения

Любое соединение DCCP предполагает формирование DCCP сокетов в пассивном состоянии прослушивания. Активной стороной считается клиент, а роль пассивной стороны выполняет сервер.

Характеристики

DCCP имеет встроенный механизм согласования параметров соединения, такой, как активные CCID для обоих полусоединений (см. рис. 3.12). Опции Change, Prefer и Confirm служат для согласования параметров. Change посылается с целью изменения определенного параметра. Адресат может откликнуться, послав Prefer, где попросит партнера заменить значение параметра, или может изменить значение параметра и послать подтверждение Confirm. Надежность установления параметров обеспечивается повторной передачей, если это потребуется.

Пакеты DCCP

Протокол DCCP использует девять различных типов пакетов: DCCP-Request, DCCP-Response, DCCP-Data, DCCP-Ack, DCCP-DataAck, DCCP-CloseReq, DCCP-Close, DCCP-Reset, и DCCP-Move. Длина пакета DCCP варьируется в пределах от 12 до 1020 байт. Алгоритм формирования и разрыва DCCP соединения подразумевает следующие обмены.

DCCP-Request

Посылается клиентом для инициализации соединения (первый шаг трехходовой процедуры).

DCCP-Response

Посылается сервером в ответ на запрос DCCPRequest (второй этап трехшаговой процедуры инициации соединения).

DCCP-Data

Используется для передачи прикладных данных.

DCCP-Ack

Используется для передачи только подтверждений.

DCCP-DataAck

Используется для передачи прикладных данных в сочетании с подтверждениями.

DCCP-CloseReq

Посылается сервером для предложения клиенту закрыть соединение.

DCCP-Close

Используется клиентом или сервером для закрытия соединения; также для запуска процедуры сброса (DCCPReset).

DCCP-Reset

Используется для закрытия соединения, обычным или необычным образом.

DCCP-Sync, DCCP-SyncAck

Используется для ресинхронизации номеров пакетов после длительного периода потерь.

Процедура взаимодействия партнеров включает в себя следующие обмены.

Форматы пакетов

Базовый заголовок пакета

Все DCCP пакеты имеют базовый заголовок с форматом, показанным на рис. 3.13.

Если X равно нулю, передаются только младшие (LSB) 24 бита порядкового номера, а базовый заголовок имеет длину 12 байт. Ниже поясняется назначение полей базового заголовка.

Порт отправителя и получателя (по 16 бит каждый)

Эти поля идентифицируют соединение, аналогично соответствующим полям TCP и UDP. Порт отправителя характеризует порт, через который послан данный пакет, а порт назначения характеризует процесс, которому должен быть этот пакет доставлен. Когда соединение формируется, клиент должен выбрать порт отправителя случайным образом, чтобы уменьшить вероятность атаки.

Прикладные интерфейсы DCCP должны воспринимать номера портов, так же, как это делается в случае TCP и UDP. Например, машины, которые различают привилегированные и непривилегированные порты для TCP и UDP, должны делать то же самое и для DCCP.

Смещение данных (8 бит)

Смещение от начала заголовка пакета DCCP первого октета прикладных данных (выражается в 32-битных словах). Получатель должен игнорировать пакеты, где значение поля Data Offset (смещение данных) меньше минимального размера заголовка для данного типа или больше размера самого пакета DCCP.

CCVal (4 бита)

Используется HCотправителем CCID. Например, CCID отправителя A-B, который активен в DCCP A, может послать 4 бита данных с каждым пакетом получателю, записав их в поле CCVal. Отправитель должен установить CCVal равным нулю, если только HCотправитель CCID не требует иного, а получатель должен игнорировать поле CCVal, если HCполучатель CCID не специфицирует обратного.

Checksum Coverage (CsCov - покрытие контрольным суммированием): 4 бита.

Поле CsCov определяет части пакета, которые покрываются полем контрольная сумма. Она всегда покрывает заголовок и опции DCCP, но некоторые приложения могут допускать исключения. Это может улучшить работу протокола в условиях каналов с высоким уровнем шума.

Контрольная сумма (16 бит)

Интернет контрольная сумма заголовка пакета DCCP (включая опции), псевдозаголовок сетевого уровня и, в зависимости от CsCov, все, некоторые или никакие поля данных приложений.

Зарезервировано (Res) (3 бита)

Отправитель должен записать в это поле все нули, а получатель должен это поле игнорировать.

Тип (4 бита)

Поле тип специфицирует тип пакета. Определены следующие типы пакетов:

Адресаты должны игнорировать любые пакеты с зарезервированным типом.

Расширенные порядковые номера (X). 1 бит

Если Х=1, в заголовке используются 48-разрядные порядковые номера. Пакеты DCCP-Data, DCCP-DataAck и DCCP-Ack могут иметь значение X, равное 0 или 1. Все пакеты DCCP-Request, DCCP-Response, DCCP-CloseReq, DCCP-Close, DCCP-Reset, DCCP-Sync и DCCP-SyncAck должны иметь Х=1 ; партнеры должны игнорировать любые такие пакеты с Х=0. При высокоскоростных соединениях следует использовать для всех пакетов Х=1.

Порядковый номер. 48 или 24 бита

Идентифицирует пакет в последовательности. Номер по порядку увеличивается на 1 после посылки каждого пакета, включая пакеты DCCP-Ack, которые не несут в себе прикладных данных.

Каждому механизму управления перегрузкой, поддерживаемому DCCP, присвоен идентификатор, или CCID: номер в диапазоне от 0 до 255. Во время установления соединения (и опционно после этого) партнеры согласуют свои механизмы управления перегрузкой. ID управления перегрузкой имеет код 1. Величина CCID/A равна CCID, используемому для полусоедиения $$A \to B$$. DCCP B посылает опцию "Change R(CCID, K)", чтобы DCCP A применял для своих информационных пакетов CCID K.

CCID является характеристикой сервера, при согласовании CCIDопций может использоваться список из нескольких приемлемых CCID, записанных в убывающем порядке по приоритету. Например, опция "Change R(CCID, 2 3 4)" просит получателя применять для своих пакетов CCID 2, хотя CCID 3 и 4 также являются приемлемыми. (Это соответствует байтам "35, 6, 1, 2, 3, 4": Change R опция <35>, длина опции <6>, ID код <1>, CCID (2, 3, 4) ). Аналогично, "Confirm L(CCID, 1, 2 3 4)" говорит получателю, что отправитель использует для своих пакетов CCID 2, но что CCID 3 и 4 могут быть также приемлемыми. В настоящее время стандартизованы следующие значения CCID:

Все определенные в настоящее время типы пакетов, за исключением DCCP-запрос и DCCP-Data, содержат в себе субзаголовок номера подтверждения в четырех или восьми байтах, следующих за базовым заголовком. Когда X=1, он имеет формат, показанный на рис. 3.14.

Клиент инициирует DCCP соединение, посылая пакет запроса. Эти пакеты могут содержать прикладные данные и должны иметь 48-битные порядковые номера ( X=1 ).

Код сервиса: 32 бита

Описывает прикладной уровень сервиса, к которому желает подключиться клиентское приложение. Поле код сервиса предназначено для индикации прикладного протокола, используемого для соединения.

Сервер откликается на корректный DCCP-запрос пакетом DCCP-отклика. Это является второй фазой трехходового диалога. Пакеты DCCP-отклика могут содержать прикладные данные и должны использовать 48-битные порядковые номера ( X=1 ).

Номер подтверждения имеет 48 бит

Содержит GSR (Greatest Sequence Number Received - наибольший полученный порядковый номер). Так как DCCP-отклик посылается только во время установления соединения, он всегда равен порядковому номеру полученного DCCP-запроса.

Код сервиса: 32 бита

Должен равняться коду сервиса, соответствующему DCCP-запросу.

Форматы пакетов DCCP-Data, DCCP-Ack и DCCP-DataAck

Поле данных DCCP соединения пересылается в пакетах DCCP-Data и DCCP-DataAck, в то время как пакеты DCCP-Ack используются для подтверждений, когда не требуется передавать какой-либо информации. Пакеты DCCP-Ack не содержат данных, но имеют номера подтверждений.

Пакеты DCCP-Ack и DCCP-DataAck часто содержат дополнительно опции подтверждения, такие, как Ack вектор, которые требуются для используемого механизма управления перегрузкой.

Опции и характеристики

Все пакеты DCCP могут содержать опции, которые располагаются в конце заголовка, их длина кратна 8 битам. Все опции всегда включаются в контрольное суммирование. Опция может начинаться с любого байта. В настоящее время определены следующие опции: таблица 3.4.

Числовые характеристики

Первый байт данных каждой опции Change, Prefer или Confirm является числовым параметром, определяющим тип согласуемого параметра. Остальные данные представляют собой одно или более значение параметра и интерпретируются в соответствии с особенностями данного параметра (характеристики). В настоящее время определены следующие параметры (таблица 3.5):

Подтверждения

Управление перегрузкой требует, чтобы получатели передавали отправителям данные о потерях пакетов и метках ECN. Получатели DCCP должны сообщать обо всех замеченных перегрузках в соответствии с профайлом CCID.

Сервис Ack Ratio

Ack Ratio предоставляет общий механизм, с помощью которого CCID, определяющий время подтверждения информационных пакетов, может выполнять упрощенное управление перегрузкой. CCID 2, TCP-подобное управление перегрузкой, использует Ack Ratio, чтобы ограничить частоту подтверждений. Некоторые CCID игнорируют Ack Ratio, выполняя управление перегрузкой для подтверждений каким-то другим способом.

Опция медленного получателя

HCП-получатель посылает опцию Slow Receiver (медленный получатель) своему отправителю, чтобы уведомить его о проблемах с обработкой его данных.

Опция отброшенных данных

Опция Data Dropped (отброшенных данных) указывает, что некоторые пакеты, отмеченные как полученные, на самом деле были отброшены, прежде чем были переданы приложению. Механизм управления перегрузкой отправителя может реагировать на потерянные информационные пакеты.

Опция контрольной суммы поля данных

Опция контрольной суммы поля данных содержит в себе 16-битное дополнение по модулю 1 суммы всех 16-битных слов, содержащихся в поле данных DCCP (информации, транспортируемой пакетами DCCP-Request, DCCP-Response, DCCP-Data, DCCP-DataAck или DCCP-Move). В сочетании с длиной контрольной суммы, меньшей 15, это позволяет различить случаи повреждения заголовка и поля данных пакета. Пакеты с поврежденным заголовком должны рассматриваться как отброшенные сетью, в то время как пакеты с поврежденным полем данных могут обрабатываться дифференцированно, например, реакция отправителя на повреждение может быть менее жесткой, чем на перегрузку.

Многодомность и мобильность

Протокол DCCP осуществляет простую поддержку многодомности и мобильности за счет механизма переадресации партнеров. Мобильный партер должен согласовать поддержку мобильности заранее. Когда мобильный партнер получает новый адрес, он посылает пакет DCCP-Move с этого адреса стационарной станции. Стационарная станция изменяет состояние соединения с учетом изменившегося адреса партнера. Поддержка DCCP мобильности призвана решить лишь простейшие проблемы многодомности и мобильности. Например, DCCP не имеет поддержки одновременного перемещения партнеров. Приложениям, где требуется более сложная семантика мобильности или более сильные гарантии безопасности, следует использовать существующие решения, подобные Mobile IP или [SB00].

Мультиплексирование

В противоположность TCP, DCCP не предлагает надежно упорядоченную доставку. Как следствие, в случае DCCP нет осложнений для слоев, размещенных выше DCCP, в частности, для мультиплексирования субпотоков в рамках одного DCCP соединения.

DCCP и RTP

Транспортный протокол реального времени, RTP [RFC-1889], в настоящее время используется (поверх UDP) многими приложениями DCCP. Существует два потенциальных источника избыточности в комбинации RTP-поверх-DCCP: задублированные данные подтверждения и задублированные порядковые номера. Этот источник избыточности добавляет 4 байта на пакет по отношению к RTP поверх UDP. Однако конкретные CCID могут использовать место, занимаемое порядковым номером RTP.

Соображения безопасности

Протокол DCCP не предоставляет криптографических гарантий безопасности. Приложения, требующие серьезной безопасности должны использовать IPsec или какую-то иную схему безопасности. Несмотря ни на что, DCCP имеет возможности противостоять некоторым видам атак. Этому способствует используемая система нумерации пакетов.

Текущий список Интернет-проектов, в том числе по направлению DCCP, доступен по адресу http://www.ietf.org/ietf/1idabstracts.txt.

3.2. Протокол TFRC

Введение

Актуальность проблем транспортировки мультимедийных данных по каналам Интернет с QoS=лучшее_возможное стимулирует разработки модификаций протоколов, управляющих перегрузкой (DCCP, TFRC и т.д.).

Протокол TFRC (TCP Friendly Rate Control - RFC-3448) предоставляет механизм управления перегрузкой для уникастных потоков в Интернет [3.2]. Ниже рассматривается способ управления перегрузкой, который может быть использован, например, в транспортном протоколе RTP [3.7], в приложении с контролем перегрузки в виртуальном канале точка-точка [3.1].

TFRC спроектирован так, чтобы обеспечивать справедливое распределение ресурсов при конкуренции с другими TCP потоками; под "справедливой" подразумевается ситуация, когда поток получает до двух раз большую полосу, чем TCP при тех же условиях. Однако TFRC имеет много меньшие вариации пропускной способности по сравнению с TCP, что делает его более удобным для таких приложений, как телефония или потоковое видео, где важна относительно постоянная скорость передачи.

Эти преимущества достигаются за счет того, что TFRC реагирует медленнее, чем TCP на изменения доступной полосы. Таким образом, TFRC следует использовать, только когда приложение требует почти постоянной пропускной способности, в частности, избегая двойного снижения пропускной способности при потере одного пакета, как это происходит в случае TCP. Для приложений, которым нужно передать как можно больше данных за ограниченное время, следует порекомендовать TCP, или, если надежность не требуется, можно применить схемы управления перегрузкой AdditiveIncrease, MultiplicativeDecrease (AIMD).

TFRC спроектирован для приложений, которые используют пакеты фиксированной длины, и варьируют скорость передачи пакетов в случае возникновения перегрузки. Некоторые аудиоприложения имеют фиксированный период следования пакетов и изменяют размер пакетов при возникновении перегрузки (TFRCPS - PacketSize). Эту версию предполагается разработать позднее.

Протокол TFRC реализует механизм, ориентированный на получателя, с вычислением характеристик перегрузки (т.е., частоты потери пакетов) на стороне получателя, а не отправителя. Это прекрасно подходит для приложений, где отправителем является большой сервер, обслуживающий большое число соединений одновременно, а получатель имеет достаточно памяти и ресурсов ЦПУ для вычислений. Кроме того, механизм, базирующийся на получателе, более удобен для реализации управления перегрузкой при мультикастинге.

Принцип работы

В процессе реализации механизма управления перегрузкой TFRC непосредственно использует выражение для пропускной способности для обеспечения скорости передачи, как функции частоты потери пакетов и RTT. Для того чтобы успешно конкурировать с TCP, TFRC использует уравнение пропускной способности TCP, которое описывает скорость передачи TCP как функцию частоты потери пакетов, RTT и размера сегмента. Определим случай потери как потерю одного или более помеченных пакетов в пределах окна, где термин "помеченный пакет" относится к индикации перегрузки в рамках режима ECN (Explicit Congestion Notification) [3.6]. Механизм управления перегрузкой TFRC работает следующим образом.

Динамика работы TFRC чувствительна к тому, как выполняется и используется измерение.

Уравнение пропускной способности TCP

Любое реалистическое выражение для пропускной способности TCP, как функции частоты потерь и RTT, приемлемо для реализации TFRC. Однако, замечено, что выражение для пропускной способности TCP должно отражать поведение таймаута повторной передачи, так как именно этот эффект доминирует при высокой вероятности потери сегмента.

Выражение для пропускной способности, рекомендуемое для TFRC, является несколько упрощенной версией формулы, используемой для Reno TCP [3.4]. В идеале предпочтительно выражение для пропускной способности, базирующееся на модели SACK TCP, но такого выражения пока не получено. Выражение для пропускной способности имеет вид:

где X - скорость передачи в байтах в сек, s длина пакета в байтах, R = RTT в секундах, p - вероятность потери сегментов (между 0 и 1.0). t_RTO является значением времени таймаута повторной передачи в секундах, b - число пакетов, подтверждаемых одним TCP ACK.

При реализации протокола используется значение t_RTO = $$4 \times R$$. Возможно и более точное выражение для расчета t_RTO, но эксперименты показывают, что предложенное выражение позволяет достичь вполне приемлемых результатов [3.9]. Другой способ - использование выражения t_RTO = max(4R, 1сек), для того, чтобы обеспечить рекомендуемый минимум RTO, равный одной секунде [3.5].

Многие современные реализации TCP соединений используют задержанные подтверждения, посылая подтверждения для пары полученных пакетов, и, таким образом, используют b = 2. Однако в TCP разрешается посылать подтверждения для каждого информационного пакета, что соответствует b = 1. Так как большинство реализаций не используют задержанных подтверждений, рекомендуется работать с b = 1.

Параметры s (размер пакета), p (частота потерь) и R (RTT) должны измеряться или вычисляться программами, реализующими протокол TFRC.

Содержимое пакетов

Рассмотрим сначала содержимое информационных пакетов, посылаемых отправителем, и пакетов обратной связи, отправляемых получателем. Так как TFRC будет использоваться совместно с транспортным протоколом, форматы пакетов не специфицируются.

Информационные пакеты

Каждый информационный пакет, посланный отправителем, содержит следующие данные:

Пакеты обратной связи

Каждый пакет обратной связи, посылаемый получателем, содержит следующую информацию.

Протокол отправителя данных

Отправитель данных посылает поток пакетов данных получателю с контролируемой частотой. Когда получен пакет обратной связи от отправителя, отправитель данных изменяет скорость передачи, используя информацию, содержащуюся в сообщении обратной связи. Если получатель не получил сообщения обратной связи за время 2RTT, он должен понизить скорость передачи в два раза. Это делается с помощью таймера nofeedback.

Протокол отправителя включает в себя следующие шаги.

Измерение длины пакетов

Параметр s (размер пакета) обычно известен приложению. Исключение составляют два случая:

Инициализация отправителя

Для инициализации отправителя значение X делается равным 1 пакету/сек, а время таймера feedback устанавливается > 2 сек. Начальные значения для величин R (RTT) и t_RTO не присваиваются. Начальное значение tld (Time Last Doubled) во время медленного старта делается равным 1.

Поведение отправителя при получении пакета обратной связи

Отправитель знает свое текущее значение скорости передачи пакетов X и поддерживает его в течение RTT (R).

Когда отправителю в момент t_now приходит пакет обратной связи, должны быть осуществлены следующие действия:

Истечение времени таймера nofeedback

Если время таймера nofeedback истекает, отправитель должен выполнить следующие действия:

Предотвращение осцилляций

Для предотвращения осцилляций полезно уменьшить скорость передачи отправителя - это приведет к сокращению длины очереди и, следовательно, RTT. Чтобы достичь этого, отправитель поддерживает оценку долгосрочного значения RTT и модифицирует скорость передачи в зависимости от того, на сколько отличается последнее значение RTT от этой оценки. Долгосрочное значение R_sqmean определяется следующим образом:

если до этого не получено сообщения обратной связи

R_sqmean = sqrt(R_sample);

в противном случае

R_sqmean = q2*R_sqmean + (1q2)*sqrt(R_sample);

Таким образом, R_sqmean представляет собой экспоненциально взвешенное среднее значение квадратного корня из RTT. Константа q2 должна быть установлена аналогично q, рекомендуемое значение равно 0.9.

Базовое значение скорости передачи X отправитель получает из функции пропускной способности. Далее вычисляется модифицированное мгновенное значение частоты X_inst:

X_inst = X * R_sqmean / sqrt(R_sample) ;

Когда sqrt(R_sample) больше, чем R_sqmean, тогда очередь обычно растет, а скорость передачи должна быть понижена.

Диспетчеризация отправки пакетов

Так как TFRC базируется на скорости передачи, а операционные системы обычно не могут диспетчеризовать события достаточно точно, необходимо воспользоваться любой возможностью отправки пакетов, чтобы обеспечить нужную среднюю скорость передачи. Таким образом, обычный цикл отправки обеспечит правильный межпакетный интервал, t_ipi:

t_ipi = s/X_inst ;

Когда отправитель начинает передачу в момент t_0, он вычисляет t_ipi и рассчитывает номинальное время посылки для первого пакета t_1 = t_0 + t_ipi. Когда приложение переходит в состояние простоя, оно проверяет текущее время, t_now и затем запрашивает повторную диспетчеризацию после ( t_ipi - (t_now - t_0) ) секунд. Когда приложение диспетчеризовано, оно снова проверяет текущее время, t_now. Если ( t_now > t_1 - delta ), посылается первый пакет.

Теперь может быть вычислено новое значение t_ipi, которое используется для вычисления номинального времени отправки t_2 пакета 2: t2 = t_1 + t_ipi. Далее процесс повторяется для каждого последующего пакета.

В некоторых случаях, когда номинальное время отправки следующего пакета t_i вычислено, может так случиться, что t_now > t_i - delta. В таком варианте пакет должен быть послан немедленно. Таким образом, если операционная система имеет таймер с низким разрешением, а скорость передачи высока, тогда TFRC может посылать короткие группы пакетов, которые разделены интервалами, соответствующими дискретам разрешения таймера ОС.

Параметр delta служит для того, чтобы придать некоторую гибкость при выборе момента отправки пакета. Если операционная система имеет разрешение таймера t_gran секунд, тогда значение delta вычисляется согласно:

delta = min(t_ipi/2, t_gran/2) ;

t_gran равно 10мсек для многих систем Unix. Если t_gran неизвестно, можно уверенно предполагать значение 10мсек.

Вычисление частоты потери пакетов (p)

Получение точных и стабильных результатов измерений частоты потерь является крайне важным для протокола TFRC. Измерение частоты потерь выполняется получателем, основываясь на детектировании потерь помеченных пакетов. Делается это путем регистрации порядковых номеров полученных пакетов.

Детектирование потерянных помеченных пакетов

TFRC предполагает, что все пакеты имеют порядковые номера, которые инкрементируются на 1 при отправке очередного пакета.

В рамках протокола TFRC предполагается, что, если потерянный пакет посылается повторно, он получает новый порядковый номер, а не номер потерянного пакета. Если транспортный протокол требует повторной передачи с первоначальным порядковым номером, разработчик протокола должен позаботиться о том, чтобы различать задержавшийся и повторно переданный пакеты и детектировать потери в случае повторной передачи.

Получатель поддерживает структуру данных, которая позволяет отслеживать, какие пакеты пришли, а какие нет. Предполагается, что структура данных состоит из списка номеров пакетов, которые пришли, и временных меток, указывающих на время прихода.

Потеря пакета детектируется при получении, по крайней мере, трех пакетов с номерами больше, чем у потерянного. Требование трех пакетов идентично регламентации протокола TCP и делает TFRC более устойчивым в случае перепутывания порядка следования пакетов. В противоположность TCP, если пакет приходит поздно (после прибытия 3 последующих пакетов) в TFRC, опоздавший пакет может заполнить пробел в рекорде приема TFRC и получатель может повторно вычислить частоту потери пакетов.

Для соединений ECN получение помеченного пакета воспринимается как сигнал перегрузки, не дожидаясь прихода последующих пакетов.

Работа с предысторией потерь пакетов

TFRC требует, чтобы система была устойчива в отношении потери нескольких пакетов подряд. Здесь имеется аналогия с TCP, где обычно выполняется сокращение CWND только вдвое за время одного RTT. Таким образом, получатель должен отслеживать историю потери пакетов в рамках рекорда событий, где событием считается потеря одного или более пакетов за RTT. Чтобы выполнить это отслеживание, получатель должен знать, какое значение RTT использовать, - эти данные периодически предоставляет отправитель в виде управляющей информации, присоединенной к пакетам данных. TFRC не чувствителен к тому, как выполнены измерения RTT, но для этих целей рекомендуется применять RTT, измеренное отправителем.

Чтобы определить, является ли потерянный, помеченный пакет началом нового случая потери или его следует отнести к уже зарегистрированному случаю, нужно сравнить порядковый номер и временную метку пакета, доставленного получателю. Для помеченного пакета S_new его время приема T_new может быть записано непосредственно. Для потерянного пакета номинальное "время прибытия" можно получить методом интерполяции. Пусть:

S_loss равно порядковому номеру потерянного пакета;

S_before равно порядковому номеру последнего потерянного пакета, который должен был прибыть до S_loss ;

S_after - порядковый номер первого пакета, который должен прийти после S_loss ;

T_before является временем приема S_before ;

T_after является временем прихода S_after.

Заметим, что T_before может оказаться до или после T_after изза смены порядка прихода пакетов. Для потерянного пакета S_loss можно интерполировать номинальное "время прибытия", зная времена S_before и S_after. Таким образом:

T_loss = T_before + ( (T_after - T_before)* (S_loss - S_before)/(S_after - S_before) ) ;

Заметим, что если последовательность номеров оказалась разорвана между S_before и S_after, то порядковые номера должны быть модифицированы с учетом этого, прежде будут начаты вычисления. Если наибольший возможный порядковый номер равен S_max и S_before > S_after, то замена каждого порядкового номера S на S' = (S + (S_max + 1)/2) mod (S_max + 1) вполне достаточна.

Если потерянный пакет S_old был идентифицирован как начинающий предыдущее событие потери и S_new только что определено как потерянное, то мы интерполируем номинальные времена прибытия S_old и S_new как T_old и T_new соответственно.

Если T_old + R >= T_new, то S_new является частью существующего события потери. В противном случае S_new - первый пакет нового события потери.

Интервал между случаями потери пакетов

Если интервал потерь A начинается с порядкового номера пакета S_A, а следующий интервал потерь B начинается с порядкового номера пакета S_B, то число пакетов в интервале потерь A равно ( S_B - S_A ).

Среднее время между потерями

Чтобы вычислить частоту потерь p, нужно сначала определить средний период потерь. Это делается с помощью фильтра, который взвешивает n последних интервалов событий потери таким образом, что измеренная частота событий потерь меняется плавно.

Веса для w_0 - w_(n1) вычисляются следующим образом:

если ( i < n/2 )

w_i = 1;

в противном случае

w_i = 1 - (i - (n/2 - 1))/(n/2 + 1);

таким образом, если n=8, величины от w_0 до w_7 равны:

1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2

Величина n для числа интервалов потери, используемая при вычислениях частоты потерь, определяет скорость реакции TFRC на изменения уровня перегрузки. Как это стандартизовано в настоящее время, TFRC не должен применяться для величин n значительно больше 8, для трафика, который может конкурировать в Интернет с TCP.

При вычислении среднего интервала потерь мы должны решить, следует ли включать самое последнее событие потерь. Мы это делаем только в случае, когда оно достаточно велико, чтобы увеличить средний интервал потерь.

Таким образом, если самыми последними интервалами потерь являются I_0 до I_n, где I_0 - интервал с момента самого последнего случая потерь, то мы вычисляем средний интервал потери I_mean как:

I_tot0 = 0;
      I_tot1 = 0;
      W_tot = 0;
      for (i = 0 to n1) { I_tot0 = I_tot0 + (I_i * w_i);  W_tot = W_tot + w_i;  }
      for (i = 1 to n) { I_tot1 = I_tot1 + (I_i * w_(i1)); }
      I_tot = max(I_tot0, I_tot1);
      I_mean = I_tot/W_tot;

Частота потери пакетов p равна:

p = 1 / I_mean;

Учет предыстории

Как описано выше в разделе "Вычисление частоты потери пакетов", самому последнему интервалу потерь при оценке усредненного интервала потерь приписывается доля 1/(0.75 $$\times$$ n). В этом разделе рассмотрен опционный механизм обесценивания предыдущих событий (history discounting), подробнее обсуждаемый в [3.3] и [3.9]. Этот механизм позволяет TFRCполучателю настроить веса, акцентируя внимания на весах событий потерь, произошедших относительно недавно. В этой версии самые последние интервалы потерь имеют более чем вдвое больший вес при вычислении усредненной длительности интервала потерь.

Чтобы ввести в действие этот механизм, определяем фактор обесценивания (дискаунт фактор) DF_i для каждого интервала потерь L_i, ( i > 0 ), где каждый фактор обесценивания является числом с плавающей запятой. Массив этих факторов содержит в себе историю обесценивания для каждого из интервалов потерь. В начале все значения DF_i массива приравниваются 1:

for (i = 1 to n) { DF_i = 1; }

Усредненный интервал потерь вычисляется с использованием n предшествующих интервалов потерь I_1, ..., I_n, и интервала I_0, который относится к пакетам, полученным после последнего события потери. Вычисление усредненного интервала потерь с помощью факторов обесценивания является простой модификацией процедуры, описанной в разделе "Вычисление частоты потери пакетов":

I_tot0 = I_0 * w_0

I_tot1 = 0;

W_tot0 = w_0

W_tot1 = 0;

for (i = 1 to n1) {

I_tot0 = I_tot0 + (I_i $$\times$$ w_i $$\times$$ DF_i $$\times$$ DF);

W_tot0 = W_tot0 + w_i $$\times$$ DF_i $$\times$$ DF; }

for (i = 1 to n) { I_tot1 = I_tot1 + (I_i $$\times$$ w_(i1) $$\times$$ DF_i); W_tot1 = W_tot1 + w_(i1) $$\times$$ DF_i; }

p = min(W_tot0/I_tot0, W_tot1/I_tot1);

Общий фактор обесценивания DF обновляется при получении каждого пакета. Сначала получатель вычисляет взвешенное среднее I_mean интервалов потерь I_1, ..., I_n:

I_tot = 0;

W_tot = 0;

for (i = 1 to n) { W_tot = W_tot + w_(i1) $$\times$$ DF_i; I_tot = I_tot + (I_i $$\times$$ w_(i1) $$\times$$ DF_i); }

I_mean = I_tot / W_tot;

Это взвешенное среднее I_mean сравнивается с I_0, - числом пакетов, полученных с момента последнего события потерь. Если I_0 больше чем вдвое I_mean, тогда новый интервал потерь значительно больше предыдущих и общий фактор обесценивания DF обновляется, чтобы понизить относительный вес старых интервалов:

if (I_0 > 2 $$\times$$ I_mean) {

DF = 2 $$\times$$ I_mean/I_0;

if (DF < THRESHOLD)

DF = THRESHOLD;

} else

DF = 1;

Ненулевое значение THRESHOLD гарантирует, что более старые интервалы потери, относящиеся к предшествующему периоду высокой перегрузки, не будут обесценены вовсе. Рекомендуется установить THRESHOLD равным 0.5. Заметим, что с приходом каждого нового пакета, I_0 будет увеличиваться, а фактор обесценивания DF - обновляться.

Когда происходит новое событие потери, текущий интервал I_0 сдвигается на место I_1, интервал потери I_i занимает место I_(i+1), а интервал потерь I_n забывается. Предшествующий дискаунтфактор DF должен быть введен в дискаунт массив. Так как DF_i несет в себе дискаунтфактор, ассоциированный с интервалом потерь I_i, массив DF_i должен быть также сдвинут. Это делается следующим образом:

for (i = 1 to n) { DF_i = DF $$\times$$ DF_i; }

for (i = n-1 to 0 step - 1) { DF_(i+1) = DF_i; }

I_0 = 1;

DF_0 = 1;

DF = 1;

Протокол получателя данных

Получатель периодически посылает сообщения обратной связи отправителю. Пакеты обратной связи должны посылаться, по крайней мере, один раз за RTT, если только отправитель не передает меньше одного пакета за RTT, в этом случае сообщения обратной связи должны посылаться после каждого получения информационного пакета. Пакет обратной связи следует также посылать всякий раз, когда детектируется новое событие потери, не дожидаясь конца RTT, и всякий раз, когда фиксируется нарушение порядка следования пакетов.

Если отправитель работает с высокой частотой (посылает много пакетов за RTT), существуют некоторые преимущества посылки сообщений обратной связи периодически, чаще одного раза за RTT, что позволяет быстрее реагировать на изменения результатов измерения RTT и обеспечить большую устойчивость к потере пакетов обратной связи. Однако, нет никакого смысла посылать много пакетов обратной связи за время RTT.

Поведение получателя при получении информационного пакета

Когда приходит информационный пакет, получатель выполняет следующие действия.

Если p <= p_prev, не нужно предпринимать никаких действий. Однако при оптимизации может проверяться, происходит ли при получении пакета заполнение пробела в истории поступления, при котором два события потери сливаются в одно. Если произошло именно это, получатель может также послать сообщение обратной связи немедленно. Влияние такой оптимизации в нормальной ситуации является незначительным.

Истечение времени таймера обратной связи

Когда время таймера обратной связи истекает, необходимые действия зависят от того, был ли получен информационный пакет со времени отправки последнего сообщения обратной связи.

Пусть максимальный порядковый номер пакета для получателя равен S_m, а значение RTT, измеренное с учетом S_m, равно R_m. Если были получены информационные пакеты с момента посылки предыдущего сообщения обратной связи, получатель выполняет следующие действия.

Если с момента посылки сообщения обратной связи не получено никаких информационных пакетов, тo пакет обратной связи не посылается, а таймер обратной связи перезапускается на время R_m секунд.

Инициализация получателя

Получатель инициализируется первым пакетом, который к нему приходит. Пусть порядковый номер пакета равен i.

Когда первый пакет получен:

Инициализация истории потерь после первого потерянного сегмента

Пакеты вплоть до первой потери не могут быть задействованы для вычисления скорости передачи, так как темп передачи в это время меняется слишком быстро. TFRC предполагает, что правильное значение скорости передачи данных после первой потери равно половине скорости передачи, при которой произошла потеря. TFRC аппроксимирует эту величину с помощью X_recv, частотой приема за последний период RTT. После первой потери TFRC получатель вычисляет интервал потери, который был бы необходим, чтобы обеспечить скорость передачи данных X_recv, и использует этот искусственный интервал потери для запуска механизма предыстории потерь.

В протоколе TFRC это делается путем нахождения некоторого значения p, для которого выражение пропускной способности из раздела "Уравнение пропускной способности TCP" дает величину пропускной способности в пределах 5% от X_recv, заданный текущий размер пакета s и RTT R. Первый интервал потерь устанавливается тогда равным 1/p.

Варианты протокола, базирующиеся на отправителе

Вполне возможно реализовать вариант TFRC, базирующийся на модели отправителя, где получатель использует надежную доставку для посылки отправителю данных о потерях пакетов, а отправитель вычисляет частоту потерь и приемлемую скорость посылки пакетов. Однако эта модель здесь не рассматривается.

Главным преимуществом модели TFRC, базирующейся на отправителе, является то, что отправитель в этом случае не должен доверять расчетам потерь, выполненным получателем. Однако в условиях требований надежной доставки данных о потерях от получателя отправителю модель TFRC, базирующаяся на модели отправителя, предъявляет более жесткие ограничения к транспортному протоколу.

Напротив, модель TFRC, базирующаяся на получателе, устойчива к потере пакетов обратной связи и, следовательно, не требует надежной доставки пакетов обратной связи. Эта модель также лучше годится для таких приложений, как потоковое мультимедиа для WEBсерверов, где обычно желательно перенести часть нагрузки с сервера на клиента.

Реализации

В данном разделе специфицируется реализации механизма управления перегрузкой TFRC, для приложений и транспортных протоколов.

Для t_RTO = 4 $$\times$$ R и b = 1 выражение пропускной способности в разделе "Уравнение пропускной способности TCP" может быть преобразовано к виду:

$$X=\frac{s}{R \times f(p)}$$

Для $$f(p) = sqrt(2 \times p/3) + (12 \times sqrt(3 \times p/8) \times p \times (1+32 \times p^2))$$.

Для вычисления функции f(p) могут использоваться lookup-таблицы.

Заметим, что опционный механизм подавления осцилляций для отправителя, описанный в разделе "Предотвращение осцилляций", использует вычисление квадратных корней.

Вычисление среднего значения интервала потерь в разделе "Интервал между случаями потери пакетов" включает в себя умножения на веса w_0 - w_(n-1), которые для n=8 равны:

1.0, 1.0, 1.0, 1.0, 0.8, 0.6, 0.4, 0.2.

С минимальной потерей гладкости можно использовать веса, которые являются степенью 2 или суммами степеней 2, напр.,

1.0, 1.0, 1.0, 1.0, 0.75, 0.5, 0.25, 0.25.

Опционный механизм "исторического дискаунтинга" используется для расчета усредненной частоты потерь. Механизм дискаунтинга включается, только когда приходится сталкиваться с достаточно протяженными периодами без потери пакетов. Для обеспечения более высокой эффективности работы дискаунтфакторы DF_i могут делаться равными целым степеням 2.