Модель CUBIC TCP

Размещено на http://www.allbest.ru/

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

Кафедра информационных технологий автоматизированных систем

Контрольная работа

по дисциплине «Компьютерные коммуникационные системы»

на тему: «Модель CUBIC TCP»

Выполнили студент Габдрашитов И.Н.

Научный руководитель Доцент Масич Г.Ф.

Пермь-2013

Содержание

Введение

СUBIC

Заключение

Список литературы

ВВЕДЕНИЕ

По мере развития Интернета, чтобы включить большое количество высокоскоростных и протяженных сетевых каналов, возникла потребность увеличения производительности TCP. Эти сети характеризуется произведением полосы пропускания на задержку, которые представляют собой общее количество пакетов, необходимых для сохранения пропускной способности в полной мере, другими словами, размер окна перегрузки . В стандартном TCP, как TCP-Reno, TCPNewReno и TCP-SACK, окно TCP увеличивается в течение времени прохождения сигнала в прямом и обратном направлениях(RTT). Это делает скорость передачи данных из TCP * во всех основных операционных системах, включая Windows и Linux , крайне низкой, по меньшей мере, если длина потоков намного короче, чем время роста окон TCP до достижения полного размера BDP контура. Например, если ширина полосы сетевого канала 10 Гбит и мс 100 мс с пакеты из 1250 байт, BDP канал составляет около 100 000 пакетов. Для роста окна TCP от половины BDP, предположим 50 000, она занимает около 50 000 RTTs что составляет 5000 секунд (1,4 часа). Если поток завершается до того времени, он испытывает серьезную нехватку используемого канала.

To counter this under-utilization problem of TCP, many “high-speed” TCP variants are proposed (e.g., FAST [24], HSTCP [15], STCP [25], HTCP [28], SQRT [19], Westwood [14], and BIC-TCP [30]). Recognizing this problem with TCP, the Linux community responded quickly to implement a majority of these protocols in Linux and ship them as part of its operating system. After a series of thirdparty testing and performance validation [11, 21], in 2004, from version 2.6.8, it selected BIC-TCP as the default TCP algorithm and the other TCP variants as optional.

Чтобы противостоять этой проблеме TCP, предлагаются многие "высокоскоростные" TCP варианты (например, FAST [24], HSTCP [15], STCP [25], HTCP [28], SQRT [19], Westwood [14], а BIC-TCP [30]). Признавая эту проблему с TCP, сообщество Linux решило быстро реализовать большинство из этих протоколов в Linux и отправлять их в рамках своей операционной системы. После ряда сторонних тестирований и проверки производительности [11, 21], в 2004 году, начиная с версии 2.6.8, был выбран BIC-TCP в качестве алгоритма по умолчанию TCP и другие варианты TCP в качестве дополнительных.

СUBIC

высокоскоростной сеть задержка протокол

CUBIC представляет собой реализацию протокола TCP с оптимизацией алгоритма управления перегрузкой для быстродействующих сетей с большими задержками (LFN: длинные широкополосные сети).

Версия CUBIC является менее агрессивной и более системной, чем BIC TCP, в которой значение ширины окна является кубичной функцией времени после последнего события перегрузки, с точкой перегиба, привязанной к окну, а не к событию как раньше.

CUBIC TCP был реализован для ядра Linux версии 2.6.19 и выше (2006 год).

Так как в Интернет существует много скоростных протяженных сегментов, для протокола постоянно возникают проблемы. Такие сети характеризуются большим произведением полосы на задержку BDP (bandwidth and delay product). В таких сетях для полного использования полосы большое число пакетов должно быть в пути, т.е. размер окна перегрузки должен быть большим. В стандартном TCP, например, TCP-Reno, TCP-NewReno и TCP-SACK, окно увеличивается один раз за RTT. Это делает передачу данных в рамках протокола TCP, используемого в большинстве операционных систем, включая Windows и Linux, достаточно вялой, не использующей всю имеющуюся полосу пропускания. Это особенно характерно для коротких сессий, где окно не успевает даже приблизиться к оптимальному значению. Например, если полоса фрагмента сети равна 10 Гбит/c, а RTT = 100 мсек, при длине пакетов 1250 байт, BDP сегмента будет составлять примерно 100,000 пакетов. Для TCP, чтобы довести окно со значения 50,000 до 100000 потребуется около 50,000 RTT, что составляет 5000 секунд (1.4 часа). Если сессия завершится раньше, полоса канала будет существенным образом недоиспользована.

Модель BIC-TCP обеспечивает хорошую масштабируемость для скоростных сетей, эквивалентность для конкурирующих потоков и стабильность с низким уровнем осцилляций размера окна. Однако функция роста окна BIC-TCP может быть слишком агрессивной для TCP, в особенности при малых значениях RTT или для низкоскоростных сетей. Более того, несколько фаз (двоичный поисковый рост, поиск max, S_max и S_min) управления окном добавляет излишнюю сложность в реализацию протокола и анализ его рабочих характеристик. Предложенная модель CUBIC TCP лишена многих недостатков BIC TCP.

В модели CUBIC используется кубичная функция роста окна, которая по форме очень близка к соответствующей функции BIC-TCP. В CUBIC при реализации функции роста окна используется время, прошедшее с момента последнего события перегрузки. В то время как большинство моделей реализации стандартного TCP используют выпуклые функции роста после потери пакета, CUBIC использует как выпуклые, так и вогнутые профили кубической функции роста окна . На рис. 10 показана эволюция окна в BIC (a) и CUBIC (b).

Рис. 10. Функция роста окна для BIC-TCP и CUBIC

После уменьшения размера окна при потере пакета, записывается значение окна W_max, которое оно имело в момент потери, и уменьшается размер окна в b раз, где b равно постоянной уменьшения окна TCP. После этого система переходит из режима быстрого восстановления в режим исключения перегрузки, начинается увеличение окна с использованием вогнутого профиля кубической функции. Кубическая функция параметризована так, чтобы ее плато приходилось на W_max, так что вогнутый рост продолжается до тех пор пока ширина окна не станет равным W_max. После этого, кубическая функция становится выпуклой. Такой способ подстройки ширины окна (вогнутый, а затем выпуклый) улучшает протокол и сетевую стабильность, сохраняя высокий уровень использования полосы канала [12]. Это происходит потому, что размер окна остается почти постоянным, образуя плато в области W_max, где уровень использования сети считается высоким и стабильным.

Рост окна в модели CUBIC осуществляется в соответствии с выражением:

W(t) = C(t-K)³ + W_max (1)

где C параметр CUBIC, t - время с момента последнего уменьшения ширины окна, а K равно периоду времени, который необходим для увеличения W до W_max, его значение вычисляется с привлечением выражения:

(2)

При получении подтверждения ACK на фазе исключения перегрузки, CUBIC вычисляет скорость роста ширины окна за время последующего RTT-периода, используя выражение (I). Программа устанавливает значение W(t + RTT) в качестве вероятной величины окна перегрузки. Предположим, что ширина окна равна cwnd. В зависимости от его значения, CUBIC реализует три разных режима. Если cwnd меньше чем размер окна, который был бы достигнут в стандартном TCP, спустя время t после последнего случая потери, тогда CUBIC оказывается в TCP-режиме (как определить этот размер окна в зависимости от t будет описано ниже). В противном случае, если cwnd меньше W_max, тогда CUBIC находится в вогнутой области, и если cwnd больше W_max, CUBIC находится в выпуклой области функции роста. Алгоритм 1 представлен в псевдопрограммном виде для варианта Linux.

a и множитель b образуют следующую функцию:

(3)

С помощью аналогичного анализа получается среднее значение ширины окна TCP с a = 1 и b = 0.5 равное . Таким образом, для равенства (3), которое является аналогичным со случаем TCP, a должна быть равна . Если TCP увеличивает свое окно на каждый период RTT, мы можем получить размер окна TCP, выраженное через t:

(4)

Если cwnd меньше W_tcp(t), тогда протокол находится в режиме TCP, cwnd делается равным W_tcp(t) при каждом получени b подтверждения ACK. Сubic TCP friendliness() в алгоритме 1 описывает это поведение. Рис. 11 позволяет сравнить характеристики стандартной модели ТСР с HSTCP и CUBIC.

Рис. 11. Функции отклика для стандартов TCP, HSTCP и CUBIC в сетях с RTT 10 мсек (a) и 100 мсек (b) соответственно.

На рис. 12 показано, как могут конкурировать друг с другом два потока CUBIC при RTT=246 мсек.

Рис. 12. Two CUBIC flows with 246ms RTT

ЗАКЛЮЧЕНИЕ

Мы предлагаем новый вариант TCP, называется CUBIC, для быстрой и протяженной сети. CUBIC это расширенная версия BIC-TCP. Это упрощает BIC-TCP управление окном и улучшает ее TCP-лояльность и RTT-справедливости. CUBIC, использующий кубическую функцию увеличения сроков времени, прошедшего с последнего события потери. В целях обеспечения справедливости по отношению к стандартному порту TCP, CUBIC также ведет себя как стандартный порт TCP, когда кубическая функция роста окна происходит медленнее, чем стандартный порт TCP. Кроме того, в режиме реального времени протокол поддерживает скорость роста окна в зависимости от RTT, который удерживает протокол TCP дружественным при коротких и длинных каналах RTT. Мы показывают детали Linux CUBIC алгоритм и его реализацию. Исходя из масштабного тестирования, мы пришли к выводу, что CUBIC имеет недостатки BICTCP и достигает довольно хорошей внутри протокольной справедливости, RTT справедливости и TCP-лояльности.

Список литературы

[1] Git logs for CUBIC updates. http://git.kernel.org/?p=linux/kernel/git/davem/net 2.6.git;a=history;f=net/ipv4/tcp cubic.c; h=eb5b9854c8c7330791ada69b8c9e8695f7a73f3d;hb=HEAD.

[2] Iperf. http://sourceforge.net/projects/iperf .

[3] Linux CUBIC source navigation. http://lxr.linux.no/linux/net/ipv4/tcp cubic.c.

[4] TCP Testing Wiki. http://netsrv.csc.ncsu.edu/wiki/index.php/TCP Testing.

[5] Testing setup for Linux and FreeBSD. http://netsrv.csc.ncsu.edu/wiki/index.php/ Testing Setup of kernel 2.6.23.9.

Размещено на Allbest.ru