Потребности в быстрой передаче больших объемов данных, а также и необходимость в сетевых инфраструктурах для поддержки этих потребностей постоянно растут. Но в то же время, основной транспортный протокол сегодняшних сетей, TCP, уже перестает удовлетворять потребностям. Долгий ответ TCP в высокоскоростных сетях приводит к тому, что весьма ощутимая часть пропускной способности такой сети остается неиспользованной. .BIC TCP и CUBIC - это управляющие нагрузкой протоколы, разработанные для решения этой проблемы. Нашей целью было создание протокола, способного увеличивать свою производительность до нескольких десятков гигабит в секунду в высокоскоростных сетях при сохранении пропускной доступности, стабильности и совместимости с TCP.

Главной особенностью BIC является уникальная функция роста окон (window growth function). На Рис. 1 изображен рост функции BIC. Когда приходит информация о потере пакета, BIC уменьшает окно за счет мультипликативного фактора (или фактора роста) (beta). Размер окна непосредственно перед уменьшением устанавливается в качестве максимума, размер окна сразу после уменьшения устанавливается в качестве минимума. Затем, BIC выполняет двоичный поиск используя эти два параметра - "перепрыгивая" к среднему значению между максимумом (Wmax) и минимумом (Wmin). Так как потери пакетов происходят при размере окна равном Wmax, то подходящий размер, при котором в сети пакеты будут проходить без потерь, должен находиться где-то между этими двумя числами.

Однако, прыжок к среднему значению может потребовать слишком много времени внутри одного RTT (время на передачу и подтверждение приема), так что если расстояние между средним значением и текущим минимумом больше фиксированной константы, называемой Smax, BIC изменяет текущий размер окна на Smax (линейное увеличение). Если BIC не получает уведомлений о потерях пакетов при измененном размере окна, то этот размер окна становится новым минимумом. Если происходят потери пакетов, то этот размер окна становится новым максимумом. Этот процесс продолжается пока изменение окна меньше некоторой маленькой константы Smin, при достижении которой размер окна становится текущим максимумом. Поэтому растущая функция после уменьшения окна будет весьма похожа на линейную, переходящую в логарифмическую (на Рис. 1 обозначены как "пошаговый прирост"("additive increase") и "двоичный поиск"("binary search"))

Если окно увеличивается сверх максимума, среднее значение размера окна должно быть больше текущего максимума, а новый максимум должен быть установлен. BIC вводит новую фазу, именуемую "поиском максимума" ("max probing"). Рост функции во время поиска максимума противоположен росту во время двоичного поиска и пошагового прироста. Она растет экспоненциально (т.е. в начале - весьма медленно), а затем - линейно. Поиск максимума использует функцию прироста окна симметрично используемой при двоичном увеличении (пошаговый прирост и двоичный поиск), только в другом порядке: он использует инверсию двоичного поиска (который логарифмичен; противоположностью ему является экспонента), а затем пошаговый прирост. Рис. 1 демонстрирует рост функции при поиске максимума. Во время поиска максимума окно в начале прирастает медленно при поиске ближайшего максимума, а затем после некоторого периода медленного роста, если новый максимум не найдется, т.е. будут наблюдаться потери пакетов, тогда принимается, что новый максимум находится гораздо дальше и происходит более быстрый рост при переходе на пошаговый прирост, где размер окна изменяется на большую фиксированную величину.

Хорошая производительность BIC достигается за счет медленного увеличения (смотри "плато" на рисунке) Wmax и линейный рост во время пошагового прироста и поиска максимума.

* Во-первых, это дает нам совместимость с TCP. В это же время, увеличение окна медленнее, чем у TCP, так что "плато" дает время для конкурирующих TCP-потоков увеличить их окна.
* Во-вторых, это улучшает стабильность протокола и сети. После того, как окно приближается к максимуму, "плато" продолжает удерживать окно в области его максимума длительное время. В результате этого уменьшаются колебания окна. Фактически, изменение окна непосредственно перед максимумом минимально (эта особенность контрастирует с другими протоколами, где изменение является наибольшим около максимума). BIC стремится нагрузить емкость сети более плавно, чем другие протоколы. Это делается с целью снизить удар нагрузки по остальным конкурирующим потокам.
* В-третьих, "плато" увеличивает полезное использование сети. В устойчивом состоянии, сеть используется насколько это возможно при Wmax. Так как BIC полностью загружает сеть на длительный период (даже с маленьким буфером маршрутизатора), то он стремиться достигнуть наиболее полезного использования сети по сравнению с другими протоколами.
* В-четвертых, линейное увеличение при пошаговом приросте и поиске максимума также способствует улучшению пропускной способности протокола. Это заставляет протокол походить на алгоритм AIMD (additive increase/multiplicative-decrease). AIMD полностью достигает ограничений пропускной способности RTT, где коэффициент пропускной способности двух конкурирующих потоков с различным временем RTT ограничен квадратной степенью коэффициента RTT. Помимо этого, также достигается предельная пропускная доступность, разделяемая между конкурирующими BIC-потоками с совпадающимм временем RTT. BIC наследует эти особенности AIMD.

Несмотря на то, что BIC обладает довольно неплохой масштабируемостью, пропускной способностью и стабильностью в высокоскоростных сетях, функция роста BIC может оказаться чересчур агрессивной для TCP, особенно при коротком времени RTT или в низкоскоростной сети. К тому же несколько различных фаз управления окном добавляют множество трудностей анализа протокола. Мы искали новую функцию роста окна, которая бы сохранила достоинства BIC (в первую очередь, стабильность и масштабируемость), но при этом упростила контроль окна и имела бы большую совместимость с TCP.

В новой версии BIC мы добавили новую функцию роста окна - кубическую функцию. Рис. 2 демонстрирует кубическую функцию, чей график похож на кривую окна BIC (см. Рис. 1). Функция растет гораздо медленнее, чем двоичное возрастание (которое по своей сути является логарифмической функцией) в начале (или "плато").

Установим начальное значение Wmax. После уменьшения окна оно растет очень быстро, но по мере приближения к Wmax, окно замедляет свой рост. При достижении Wmax прирост становится нулевым. Затем, окно начинает медленно рости, ускоряя рост по мере удаления от Wmax. На графике наблюдается такое же "плато" как и на кривой окна BIC, но уровень роста ускоряется намного медленнее, чем у BIC. Такой медленный прирост свидетельствует об улучшенной совместимости протокола с TCP. Далее функция максимально упрощается в контроле окна, так как там используется уже только одна функция и по этой причине нет различных фаз.

Давайте рассмотрим эти особенности подробнее.

Следует обратить внимание на два момента: RTT-доступность и внутрипротокольная доступность. Так как AIMD больше не используется, требуются специальные механизмы для поддержания свойств доступности. Наша стратегия в контроле этих свойств заключалась в том, чтобы позволить окну рости на уровне, зависящем от прошедшего времени после последней потери пакета. Эта стратегия также поддерживала SQRT и HTCP. Точнее, окно размером W определялось следующей функцией:

Wmax - это размер окна непосредственно перед последним (предыдущим) уменьшением (окна), T - прошедшее время после последнего уменьшения окна, а "бета" - растущий (мультипликативный) коэффициент уменьшения после потери пакета.

Такая функция обеспечивает внутрипротокольную доступность для соревнующихся потоков одного протокола. Чтобы убедиться в этом, предположим, что два потока соревнуются друг с другом на одном сквозном участке пути. Два потока разделят между собой всю доступную им пропускную способность, так как у них одинаковый растущий (мультипликативный) коэффициент "бета", поэтому поток с бОльшим Wmax сильнее уменьшится, а растущая функция позволит потоку с бОльшим Wmax расти гораздо медленнее, т.е. К больше, соответственно, если Wmax больше.

Функция также обеспечивает хорошее значение RTT доступности в силу того, что уровень роста окна определяется коэффициентом T (прошедшее время). Это гарантирует линейную RTT-доступность за счет того, что любые соревнующиеся потоки с различным RTT будут иметь одинаковый коэффициент T после синхронизации потери пакета (стоит отметить, что TCP и BIC предлагают квадратную величину RTT доступности в переводе на коэффициент пропускной способности).

BIC увеличивает окно аддитивно (пошагово) когда разница окна при RTT становится больше некоторой величины. Напротив, CUBIC увеличивает окно в зависимости от текущего момента; при коротких RTT линейное увеличение RTT меньше, хотя и остается постоянным (в реальном времени).

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

Кубическая функция сама по себе довольна дружелюбна по отношению к TCP. Стоит отметить, что при маленьком размере окна его Wmaxβ также маленькое. Это значит, что К - маленькое, и по этой причине уровень роста кубической функции довольно низкий (т.е. функция растет медленно) - даже медленнее, чем TCP. Таким образом, когда BDP сети маленькое CUBIC довольно дружелюбен к TCP.

Мы эмпирически установили C равным 0.4, Smax равным 160, а "бету" равной 0.2. Исходя из наших анализов, такие значения обеспечивают хорошую совместимость с TCP, доступность, масштабируемость и конвергенционную скорость.

Также нужно отметить, что полная функция роста окна описывается лишь одной функцией: в CUBIC не требуются различные фазы контроля окна (как, например, аддитивное (пошаговое) увеличение, двоичный поиск и поиск максимума в BIC). Это весьма упрощает анализ CUBIC. Мы сознательно пренебрегаем в данном случае формальной аналитической оценкой CUBIC и оставляем это для последующих исследовательских документов.

Следует учитывать, что уровень роста окна CUBIC может быть меньше чем у TCP в сетях с коротким RTT и/или маленьким BDP (bandwidth delay product). Чтобы достичь сопоставимой производительности TCP в этом режиме, позволим окну CUBIC рости по крайне мере со скоростью TCP. Достигнем этого путем добавления режима "TCP".

Большинство высокоскоростных вариантов протокола TCP имеют тот или иной вид "режима TCP", при котором протокол ведет себя также как TCP. HSTCP и STCP переходят в свои режимы TCP когда размер окна меньше некоторой небольшой константы (обычно, это где-то около 30 пакетов). Это значение определяется точкой пересечения функции отклика высокоскоростного протокола и функции TCP. Примечательно, что функция отклика протокола является уровнем отсылки пакетов в период, равный RTT, (или размером окна) когда говорим об уровне потерь пакетов. BIC также перенял это приближение. Тем не менее, такое приближение имеет существенный недостаток. TCP может выдавать достаточно хорошую производительность даже если размер окна становится больше 30. Такое происходит, когда значение RTT довольно невелико, но более чем достаточно, чтобы сделать BDP больше определенного значения. Например, пропускная способность в 200 Мб/с и 10 мс RTT дают BDP около 200, но TCP в таких условиях чуствует себя достаточно комфортно, используя пропускную способность на полную. Если использовать в таких условиях, то наше приближение может сделать BIC (а также и HSTCP и STCP) иногда слишком агрессивными при соревновании с TCP-потоками.

Фактически, наше наблюдение заключается в том, что условия, в которых TCP работает успешно, зависят от продолжительности периода загрузки (но не от размера окна!), т.е. периода между двумя последовательными потерями. Например, если RTT равен 1 мс, то TCP может увеличивать свое окно по 1000 пакетов в секунду (при отложенном подтверждении - по 500), а такая скорость должна быть достаточно быстрой для полного использования емкости в большинстве широкополосных сетей (если там достаточно места в буфере в "узком" соединении). С другой стороны, если RTT равно 200 мс, то TCP может увеличивать окно на 5 пакетов в секунду. Это может оказаться слишком медленным для сетей с большим BDP. Контроль режима TCP при помощи лишь размера окна может оказаться подходящим далеко не для всех ситуаций. С другой стороны, период нагрузки может подсказать, подходит ли сетевое окружение для использования TCP.

CUBIC решает эту проблему гораздо элегантнее. Так как уровень роста окна CUBIC не зависит от RTT, как, например, агрессивность TCP меняет свою агрессивность в зависимости от RTT, то продолжительность реального времени, когда CUBIC растет гораздо меленнее по сравнению с TCP после предыдущего периода, определяется агрессивностью TCP. Когда TCP становится весьма агрессивным, такой период "дружелюбия к TCP" становится дольше.

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

Так как CUBIC уменьшает свое окно на коэффициент β после потери окна, "честный" уровень TCP будет 3((1-β)/(1+β)) в период времени, равный RTT. Это благодаря тому, что средний уровень отылки в AIMD равен

так как α=1 и β=1/2. Чтобы достигнуть такого же среднего уровня отсылки как и у TCP с произвольным значением "беты", нам необходимо "альфа" равный 3((1-β)(1+β)). Так как мы взяли значение 0.2, коэффициент пошагового прироста полчается равным 0.5. С учетом этого, размер окна TCP за время t (после предыдущего периода) будет равно

Если TCP больше ограниченного Wcubic (в уравнении 1), тогда устанавливаем размер окна равным Wtcp. Иначе, ограниченный Wcubic будет равен значению размера окна при текущей нагрузке. Примечательно, что ограниченный Wcubic получается за счет ограничения Wcubic в уравнении 1 в росте, который не должен быть быстрее чем Smax в секунду.

_________________
На звание эксперта не претендую, поэтому за все замечания и поправки буду очень благодарен.

dark_rex