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

Следует также учитывать, что сетевой узел является общей точкой, через которую проходит множество соединений TCP, т.е. соединения TCP конкурируют (concurrent TCP connections) между собой за право использования ресурсов. В главе 2 рассмотрены принципы, которые должны соблюдаться при прохождении через транзитный узел конкурирующих соединений, а также принцип «справедливого распределения ресурсов» (fair share или fairness).

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

Интуитивно можно предположить, что необходимо постепенно увеличивать скорость передачи данных до тех пор, пока подтверждения о доставке сегментов данных не перестанут приходить от приемника через заданный промежуток времени, который, в свою очередь, должен зависеть от RTT. Действительно, после установления соединения TCP значение размера окна перегрузки cwnd устанавливается в единицу и далее, с получением каждого пакета подтверждения АСК (acknowledgement) о доставке сегментов данных от источника, размер окна перегрузки cwnd увеличивается на значение MSS. Таким об разом, протокол оценивает пропускную способность канала. Такая стратегия называется «аддитивное увеличение» (Additive Increase).

Соединение TCP продолжает увеличение значения размера окна перегрузки cwnd до тех пор, пока не произойдет потеря пакета, и, соответственно, сегмента TCP. Под потерей пакета в данном случае подразумевается либо истечение таймера получения подтверждения АСК (т.е. пакет был потерян или доставлен с высокой задержкой, возможен также вариант потери пакета подтверждения АСК), либо получение трех одинаковых пакетов подтверждения АСК. Как только потеря сегмента определена соединением TCP, значение размера окна перегрузки cwnd сразу же резко уменьшается до «безопасного», реальное значение которого зависит от конкретной реализации. Такая стратегия называется «мультипликативное снижение» (Multiplicative Decrease). Далее соединение TCP продолжает посылать данные и опять, с получением каждого пакета подтверждения АСК о доставке сегментов данных от источника, начинает увеличивать размер окна перегрузки cwnd.

На рис. 1.20 приведена динамика изменения размера окна перегрузки в процессе функционирования протокола TCP, на примере которой достаточно легко можно понять каким образом функционирует алгоритм AIMD.

Рис. 1.20. Влияние алгоритма AIMD на размер окна перегрузки протокола TCP

Алгоритмы «медленный старт» и «предотвращение перегрузки» После, установления соединения TCP значение размера «начальный размер окна» IW устанавливается равным значению размера сегмента максимального размера, который может быть передан, т.е. MSS.

Таким образом, начальная скорость передачи данных (или пропускная способность соединения TCP) равна примерно MSS/RTT (байт/с). В связи с тем, что полоса пропускания, доступная для рассматриваемого соединения TCP, может существенно пренышать его начальную скорость передачи, необходимо в соответствии со стратегией AIMD повышать значение размера окна перегрузки. Таким образом, соединение выясняет состояние маршрута до приемника. Конечно, можно увеличивать его размер на одно значение MSS каждый промежуток RTT, т.е. линейно, но при этом пройдет достаточно много времени, прежде чем скорость передачи соединения TCP станет адекватной (сравнимой) доступной полосе пропускания. Именно поэтому, в случае, когда значение окна перегрузки равно значению одного MSS, увеличение размера окна осуществляется экпоненциально - каждый промежуток RTT размер окна удваивается:

cwnd ~ 2 * cwnd.

Передатчик продолжает экспоненциально увеличивать размер окна либо до момента потери сегмента, либо до достижения заранее определенного порогового значения ssthresh (см. ниже). Описанный алгоритм называется «медленный старт».

Далее необходимо ввести параметр «порог алгоритма медленного старта» (slow start threshold, далее - ssthresh). Значение этого параметра определяет конец и начало фаз функционирования алгоритмов «медленный старт» и «предотвращение перегрузки», соответственно. Значение ssthresh изначально устанавливается достаточно большим, например, в [Stevens03] рекомендовано значение 65 Кбайт, т.е. изначально этот параметр практически не имеет влияния на скорость передачи. В процессе функционирования соединения TCP значение ssthresh может и должно изменяться. При обнаружении потери в протоколе TCP Reno во время нахождения в фазе «медленный старт» предусмотрено снижение значения параметра ssthresh - новое значение равно половине значения размера окна cwnd, при котором случилась обнаруженная потеря, а, в свою очередь, размер окна перегрузки должен принимать значение, равное единице, т.е.:

cwr.d - 1 * MSS ssthresh - cwnd / 2.

После того как значение размера окна перегрузки достигнет значения параметра «порог алгоритма медленный старт», т.е. cwnd = ssthresh, наступает фаза «предотвращение перегрузки» и увеличение размера окна происходит в соответствии с одноименным алго ритмом. В протоколе TCP Reno алгоритм «предотвращение перегрузки» подразумевает изменение размера окна перегрузки и соответствии со следующим выражением [Stevens03]:

cwnd - max { 1 * MSS, cwr.ö + ( MSS * XSS 1 / cwr.d } , где функция maxi } определяет целое значение кратное 1 байту. Управление размером окна на базе этой формулы приводит к более агрессивному поведению источника нагрузки, т.е. приращение размера окна за один промежуток RTT может превышать MSS. Отметим, что здесь и далее под агрессивным поведением источника будем понимать ситуацию, когда источник постоянно существенно повышает количество данных, передаваемых в сеть за некоторый промежуток времени.

Фаза «предотвращение перегрузки» заканчивается как только происходит истечение таймера TCP (происходит потеря). В этом случае значения параметров cwnd и ssthresh должны быть изменены в соответствии со следующими правилами:

cwnd - 1 * MSS ssthresh = max { Datalr.Flignt / 2, MSS * MSS }.

Таким образом, после осуществления повторной передачи потерянного сегмента, передатчик TCP переходит в фазу «медленный старт», которая продолжается до тех пор, пока размер окна перегрузки не достигнет нового значения параметра ssthresh. На рис. 1.21 представлен пример функции изменения размера окна перегрузки в обеих фазах и при истечении таймера. Изначально предполагается, что

cwnd = 1*MSS, ssthresh = 8*MSS.

Алгоритмы «быстрая повторная передача» и «быстрое восстановление» Изменение обработки события «поступление подтверждения» для некоторого сегмента в протоколе TCP: передатчик должен определить, является ли полученное подтверждение «первым» (first-time АСК) безошибочной доставки определенного сегмента или «повторным» (duplicate АСК). Если подтверждение первое, то передатчик определяет, что все данные, вплоть до байта, указанного в сегменте подтверждения, были приняты корректно и обновляет значения параметров TCP Reno (здесь необходимо напомнить, что как было указано в п. 1.3.2.3.2 «Посылка и нумерация сегментов подтверждения АСК», сегмент подтверждения протокола TCP содержит номер байта, который он готов принять следующим).

Если подтверждение является повторным, т.е. ресивер информирует передатчик о поступлении вне очереди безошибочного сегмента (см. табл. 1.4), и количество идентичных сегментов подтверждения равно четырем (в передатчик поступил третий повторный сегмент подтверждения), то для обработки ситуации передачтиком применятся алгоритм «быстрой повторной передачи» (fast retransmit). На рис. 1.22 представлен метакод этого алгоритма (подразумевается, что

этот код должен заменить код соответствующего события на рис. 1.15). Значения параметров cwnd и ssthresh должны быть изменены в соответствии со следующими правилами:

ssthresh - cwnd / 2 cwnd -■ ssthresh.

Далее необходимо обсудить, почему поведение протокола TCP Reno отличается при истечении таймера и при получении трех повторных подтверждений, в частности, почему при истечении таймера размер окна перегрузки снижается до размера одного MSS, а при получении трех повторных подтверждений - только наполовину? Более ранняя версия протокола TCP - TCP Tahoe при обнаружении потери пакета любого характера, будь то истечение таймера или поступление повторного подтверждения, безусловно снижала размер окна перегрузки до размера одного MSS, и, таким образом, переводило передатчик TCP в фазу «медленный старт».

В TCP Reno при получении трех повторных подтверждений изменение параметров cwnd и ssthresh производится таким образом, что передатчик избегает перехода в фазу «медленный старт», а остается в фазе «предотвращение перегрузки». Налицо отличие поведения двух реализаций протокола TCP. Такое поведение более поздней реализации объясняется следующим образом. Поступление в передатчик трех повторных подтверждений говорит, в первую очередь, не о том, что на маршруте до ресивера обнаружена перегрузка, в результате которой был потерян сегмент, а о том, что в результате передачи был потерян сегмент, но три последующих были доставлены безошибочно!

Таким образом, очевидно отличие используемых подходов для анализа сложившейся ситуации: при тайм-ауте предполагается, что сегмент потерян и способность сети по передаче информации под вопросом, а при получении трех повторных подтверждений предполагается, что сеть способна передавать данные, хотя один из сегментов (и его копии) был потерян. Алгоритм, обеспечивающий переход передатчика из фазы «предотвращение перегрузки» при поступлении трех повторных подтверждений опять в эту же фазу с новыми параметрами, минуя «медленный старт», называется «быстрое восстановление» (fast recovery).

Рассмотрим пример, иллюстрация к которому приведена на рис. 1.23. Пусть существует два различных соединения TCP с разными реализациями протокола - TCP Tahoe и TCP Reno. Проанализируем различие в поведении этих протоколов в случае поступления в передатчик трех повторных подтверждений. Пусть начальные условия одинаковы: cwnd 1*MSS, ssthresh = 8*MSS и увеличение размера окна в фазе «медленный старт» осуществляется экспоненциально, а в фазе «предотвращение перегрузки» - линейно. Предположим, что в момент, когда размер окна перегрузки cwnd = 12*MSS, в передатчик поступило третье повторное подтверждение - это событие должно быть обработано в соответствии с реализацией. Оба протокола вычисляют новые значения параметров cwnd и ssthresh. Для TCP Tahoe они принимают следующие значения:

ssthresh " cwnd / 2 - ( 12 * KSS ) / 2 - 6 * KSS cwnd ~ 1 * MSS, и, таким образом, осуществляется переход передатчика TCP Tahoe в фазу «медленный старт». В свою очередь, для TCP Reno параметры принимают следующие значения:

ssthresh " cwnd / 2 - ( 12 * MSS ) / 2 ~ 6 * MSS cwnd - ssthresh - 6 * MSS, и, таким образом, передатчик TCP Reno, как показано на рис. 1.23, остается в фазе «предотвращение перегрузки», но с новыми параметрами. Существует достаточное количество модификаций описанного в Jacobson88] алгоритма «быстрое восстановление», с которыми заинтересованный читатель сможет ознакомиться в работах [Stevens03, RJFC2581J.

Рис. 1.23. Динамика изменения размера окна перегрузки для протоколов TCP Tahoe и TCP Reno

3 Зак. 863

Рассмотрев, каким образом ведет себя соединение TCP, легко придти к выводу, что трафик, генерируемый TCP, в силу специфики рализа-ции функций протокола по управлению скоростью передачи данных, имеет ярко выраженный пачечный характер. В связи с тем, что протокол TCP используется многими популярными среди приложений протоколами, например, такими как HTTP и FTP, интересной задачей является оценка средней пропускной способности соединения TCP. Отметим, что приведенная ниже методика справедлива для достаточно долгосрочных соединений TCP. Оценка пропускной способности краткосрочных соединений TCP является достаточно сложной задачей.

Как было показано выше, пропускная способность соединения зависит от значения размера окна cwnd. Если передатчик посылает сегменты (количество которых определено в cwnd) один за другим, то после посылки последнего сегмента источник должен ожидать время RTT для получения пакета подтверждения АСК для посланных сегментов, после чего может опять начать посылать сегменты, количество которых опять же определено в cwnd. Пренебрежем фазой «медленный старт», в которой может находиться передатчик после истечения таймера, т.к., как правило, эта фаза длится достаточно малое время. Таким образом, если TCP-соединение передает cwnd сегментов размера MSS байт каждые RTT секунд, то пропускная способность соединения (в байт/с) равна:

throughput = ( cwnd * MSS ) / RTT.

Далее, пусть размер окна перегрузки увеличивается на MSS в каждые RTT секунд вплоть до момента потери сегмента. Обозначим через CWND значение размера окна перегрузки при обнаружении потери. Предполагая, что в течение соединения значения RTT и CWND значительно не изменяются, справедливо предположить, что пропускная способность соединения TCP за время его существования изменяется в следующих пределах:

throughput 6 [ (CWND * MSS) /2 * RTT; (CWND * MSSJ/RTT].

Учитывая факт, что увеличение окна перегрузки в фазе «предотвращение перегрузки» подчиняется линейному закону, средняя пропускная способность соединения TCP может быть выражена следующим образом:

average_throughput - ( 0.75 * CWND * MSS ) / RTT [байт/с].

Подобный подход для подсчета средней пропускной способности является достаточно грубой аппроксимацией. Существует ряд мето дов, позволяющих гораздо точнее оценить пропускную способность соединения TCP [Mahdavi97, PadhyeOO], но вычислительно они гораздо более сложны.

⇐Алгоритм управления перегрузкой | Управление трафиком и качество обслужевания в сети | Другие реализации протокола tcp⇒