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

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 работает следующим образом.

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

Динамика работы 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 = . Возможно и более точное выражение для расчета 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 будет использоваться совместно с транспортным протоколом, форматы пакетов не специфицируются.

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

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

• номер по порядку. Это число инкрементируется на 1 после передачи очередного пакета. Поле должно быть достаточно велико, чтобы исключить возможность появления двух пакетов с идентичными номерами в пределах записанной истории пришедших пакетов у получателя;
• временную метку, отмечающую время отправки пакета. Обозначим временную метку для пакета с номером i как ts_i. Разрешающая способность для таких меток должна быть на уровне миллисекунд. Метки используются получателем для определения, принадлежит ли потеря одному и тому же событию потери. Также они применяются для оценки значения RTT. Альтернативой меткам, инкрементируемым каждую миллисекунду, могут быть метки, которые инкрементируются каждую четверть RTT. Оценку RTT, полученную по пакету i, обозначим R_i. Оценка RTT используется получателем совместно с временной меткой, для определения, принадлежат ли множественные потери одному и тому же событию.

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

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

• Временная метка последнего полученного пакета. Обозначим ее как t_recvdata. Если последний полученный пакет имеет номер i, тогда t_recvdata = ts_i. Эта временная метка используется отправителем для оценки RTT.
• Время с момента прихода последнего информационного пакета на вход получателя до генерации сообщения обратной связи. Обозначим это время как t_delay.
• Частота, с которой получатель оценивает то, что данные были получены, с момента посылки последнего сообщения обратной связи. Обозначим эту величину X_recv.
• Текущая оценка получателем частоты потерь p.

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

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

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

• Измерение средней длины посылаемых пакетов.
• Действия, выполняемые отправителем при получении пакета обратной связи.
• Действие отправителя, когда истекает время таймаута nofeedback.
• Предотвращение осцилляций (опционно).
• Диспетчеризация передачи для операционных систем, работающих не в режиме реального времени.

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

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

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

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

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

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

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

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

1. вычисляется новое значение RTT ;
2. обновляется оценка RTT.

   Если не получено обратной связи до этого, то R = R_sample.

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

   R = q R + (1q) R_sample;

   Протокол TFRC не чувствителен к точности фильтрующей константы q, но рекомендуется значение по умолчанию q=0.9 ;
3. обновляется время таймаута:

   t_RTO = ;
4. обновляется скорость передачи согласно:

   Если ( p > 0 )

   На основе выражения для пропускной способности TCP вычисляем X_calc.

   X = max(min(X_calc, 2 X_recv), s/t_mbi);

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

   Если ( t_now - tld >= R )

   X = max(min(2 X, 2 X_recv), s/R);

   tld = t_now;

   Заметим, что если p == 0, отправитель находится в состоянии медленного старта, когда он практически удваивает скорость передачи за время RTT. Значение s/R определяет минимальную скорость передачи в период медленного старта, равную одному пакету за RTT. Параметр t_mbi равен 64 секундам и характеризует максимум межпакетной задержки передачи в отсутствии обратной связи. Таким образом, когда p > 0, отправитель посылает как минимум по одному пакету каждые 64 секунды;
5. устанавливается таймер nofeedback на время после секунд.