4.4.3.5 Протокол TFRC

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

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

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

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

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

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

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

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

При реализации протокола используется значение t_RTO = 4*R. Возможно и более точное выражение для расчета t_RTO, но эксперименты показывают, что предложенное выражение позволяет достичь вполне приемлемых результатов [9]. Другой возможностью является использование выражения t_RTO = max(4R, 1сек), для того чтобы обеспечить рекомендуемый минимум RTO, равный одной секунде [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 + (1-q)×R_sample;

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

3) обновляется время таймаута:

t_RTO = 4×R;

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 на время после max(4×R, 2×s/X) секунд.

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

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

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



Если (X_calc > 2×X_recv)




X_recv = max(X_recv/2, s/(2×t_mbi));




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




X_recv = X_calc/4;




Выражение s/(2×t_mbi) ограничивает частоту одним пакетом каждые 64 секунды в случае постоянного отсутствия обратной связи.



2. значение X должно быть повторно вычислено, как это описано в пункте (4) выше.

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




X = max(X/2, s/t_mbi)



3. перезапускается таймер nofeedback на время max(4×R, 2×s/X) секунд.

Заметим, что когда отправитель прерывает передачу, получатель прекратит отправку сообщений обратной связи. Это вызовет запуск таймера nofeedback и уменьшение X_recv. Если отправитель позднее начинает передачу снова, X_recv ограничит скорость передачи и будет реализовываться обычный медленный старт, пока скорость передачи не достигнет X_calc.

Если отправитель был пассивен с момента тайм-аута nofeedback, а X_recv меньше четырех пакетов за RTT, тогда X_recv не должно сокращаться вдвое в ответ на истечение времени тайм-аута. Это гарантирует, что разрешенная скорость передачи никогда не будет сокращена ниже двух пакетов за RTT после периода пассивности.

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

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

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

R_sqmean = sqrt(R_sample);

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

R_sqmean = q2*R_sqmean + (1-q2)*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 при отправке очередного пакета.

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

Потеря пакета детектируется при получении, по крайней мере, трех пакетов с номерами больше, чем у потерянного. Требование трех пакетов идентично регламентации протокола 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_(n-1) вычисляются следующим образом:

если (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 n-1) { 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_(i-1)); }
I_tot = max(I_tot0, I_tot1);
I_mean = I_tot/W_tot;

Частота потери пакетов p равна: p = 1 / I_mean;

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

Как описано выше в разделе “Вычисление частоты потери пакетов”, самому последнему интервалу потерь при оценке усредненного интервала потерь приписывается доля 1/(0.75?n). В этом разделе рассмотрен опционный механизм обесценивания предыдущих событий (history discounting), подробнее обсуждаемый в [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 n-1) {
    I_tot0 = I_tot0 + (I_i × w_i × DF_i × DF);
    W_tot0 = W_tot0 + w_i × DF_i × DF; }
for (i = 1 to n) { I_tot1 = I_tot1 + (I_i × w_(i-1) ? DF_i); W_tot1 = W_tot1 + w_(i-1) × 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_(i-1) × DF_i; I_tot = I_tot + (I_i × w_(i-1) ? DF_i); }
I_mean = I_tot / W_tot;

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

if (I_0 > 2 × I_mean) {
DF = 2 × 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 × 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.

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

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

1. Добавление пакета в историю доставки пакетов (packet history).
2. Пусть предыдущее значение p равно p_prev. Вычисляется новое значение p.
3. Если p > p_prev, происходит истечение времени таймера обратной связи и выполняются действия, описанные в разделе "Протокол отправителя данных".

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

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

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

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

1. Вычисляется средняя частота событий потери.
2. Вычисляется частота поступления пакетов X_recv, на основе полученных пакетов за время предыдущих R_m секунд.
3. Формируется и отправляется пакет обратной связи, содержащий информацию, которая описана в разделе "Содержимое пакетов".
4. Перезапускается таймер обратной связи на время R_m секунд.

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

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

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

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

• установим p=0;
• установим X_recv = 0;
• подготовим и пошлем пакет обратной связи;
• установим таймер feedback на время R_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×R и b = 1 выражение пропускной способности в разделе "Уравнение пропускной способности TCP" может быть преобразовано к виду:

Для f(p) = sqrt(2×p/3) + (12×sqrt(3×p/8) × p × (1+32×p²)).

Для вычисления функции 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.

Ссылки