CC BY
121
УДК 693.548
Исследование модификаций протокола TCP в сетях с коммутацией пакетов
Ю.А. Иванов, А.С. Пастухов, А.К. Гуреев
Исследованы модификации протокола в сетях с коммутацией пакетов.
TCP modifications in packet switch networks research.
Координацию процессов передачи информации в распределенной системе, которой является сеть, осуществляют коммуникационные протоколы. Самой распространенной и универсальной сетевой архитектурой является архитектура TCP/IP.
Предметом исследования статьи является транспортный протокол TCP (Transmission Control Protocol). Так как этот протокол постоянно изменяется и дополняется, то можно говорить о модификациях протокола. Проведем сравнение модификаций протокола TCP при изменениях конфигураций сети методом имитационного моделирования. Для моделирования работы модификаций протокола TCP использовался программный комплекс NS (Network Simulator), входящий в состав VINT (Virtual Internetwork Testbed).
Построение и описание модели сети. Модельные эксперименты проводились в нескольких сценариях на двух схемных моделях соединения локальных вычислительных сетей (LAN №1 и №2) через канал с ограниченной пропускной способностью (ПС) (рис. 1). Между LAN существуют один или более TCP потоков. На каждом узле исполняется объект протокола TCP. Каналы характеризуются пропускной способностью r и временем задержки (т). Узлы сервера 51 - S5 объединены в локальную вычислительную сеть, которая подключена к конечному пользователю (клиентскому узлу) R через маршрутизатор G1 для модели №1, или к следующей локальной вычислительной
сети (R1 - R5) через маршрутизаторы G1 и G2, которые связывают локальные сети, передавая трафик по каналу с малой ПС (территориальная сеть - WAN) и большим значением задержки для модели №2.
Наличие двух моделей конфигураций сети обусловлено различными вариантами построения и функционирования сетей. Так, например, модель №1 имитирует клиентский узел, к которому поступает объединенный трафик с узлов сервера локальных вычислительных сетей. Модель №2 имитирует локальные вычислительные сети, связанные каналом с ограниченной пропускной способностью, где каждый узел сервера имеет свой клиентский узел. Немаловажным критерием оценки работы протоколов является сравнение поведения протоколов в различных сетевых конфигурациях.
Каналы связи при моделировании характеризуются следующими параметрами:
пропускная способность каналов связи между компьютерными серверами и маршрутизатором составляет 10 Мбит/с (дуплекс), а время задержки каждого канала 10 мс получается суммированием задержек на передачу, распространение и постановку в очередь;
пропускная способность симплексного канала связи от маршрутизатора к клиенту в прямом и обратном направлениях соответственно 512 кбит/с и 33,6 кбит/с, с задержкой распространения 20 мс.
Параметры моделируемой сети при различных имитациях выбраны таким образом, чтобы
Рис. 1. Моделиисследуемых сетей №1 и №2
соответствовать реальным сетям. Так, например, большинство каналов территориальной сети имеют пропускную способность от 64 кбит/с до 1 Мбит/с с величиной задержки в диапазоне от 10 до 40 мс. Каналы коммутируемых соединений в этой же сети имеют пропускную способность от 28,8 до 56 кбит/с. Пропускная способность локальных сетей в основном равна 10 Мбит/с.
Источники и приемники трафика находятся в разных LAN. Предполагается, что источники потоков всегда имеют информацию для отправки. Приемники трафика TCP отправляют подтверждения в противоположном направлении в виде сегментов, не содержащих данных.
В буфере маршрутизатора G 1 организуется FIFO-очередь сегментов Q, которые отправляются далее к клиенту (модель №1) или к маршрутизатору G2 (модель №2). Очередь имеет конечную длину. Сегмент, поступающий на выходной интерфейс, помещается в очередь, если она может вместить этот сегмент, иначе сегмент теряется. Очередь маршрутизатора G1 обслуживается со скоростью канала, соединяющего маршрутизаторы.
Для имитации узлов Internet-серверов использовались источники с распределением Парето. Параметр MSS (Maximum Segment Size) - максимальный размер сегмента, равен 200 байт во всех имитациях. Интервалы времени передачи и ожидания составляют ron=160 мс и roff=100 мс, соответственно. Коэффициент формы а = 1,65. Коммуникационные транспортные протоколы. Управление потоками в коммуникационных сетях обозначает регулировку скорости отправки данных в сеть с целью достижения максимального использования ресурса сети и минимизации потерь данных. Задачу управления скоростью передачи данных можно условно разбить на два компонента: не допущение переполнения принимающей стороны и переполнения сети. Иными словами, целью системы управления потоком является выравнивание скорости передачи данных со скоростью их приема. К наиболее существенным недостаткам протокола TCP в области управления потоками относится следующее.
1. Механизм коррекции ошибок связан с механизмом управления потоком в TCP. Причиной этого является интерпретация протоколом факта потери сегмента (и, соответственно, факта срабатывания механизма коррекции ошибок) как признака перегрузки сети. Вследствие этого TCP реагирует на любую потерю данных снижением
скорости передачи. Результатом является крайне низкая эффективность применения протокола ТСР для систем, где потери данных происходят не только вследствие перегрузки, а для всех систем, где существует ненулевая вероятность потери данных на физическом -канальном уровнях. Это, в частности, все виды беспроводных сетей: спутниковые, сотовые, оптические.
2. В ТСР применяется постоянное линейное увеличение нагрузки на сеть с целью определения момента начала перегрузки. Вследствие этого сеть постоянно находится либо в состоянии перегрузки, либо в состоянии выхода из нее. Это отрицательно сказывается на соединениях в виде увеличенного среднего ЯТТ, большой дисперсии измеряемых значений ЯТТ, постоянном наличии потерь, с помощью которых сеть сигнализирует о начале перегрузки.
3. В большинстве условий протокол ТСР осуществляет отправку данных очень неравномерно. Фактически все данные в пределах окна отправляются за небольшое время в виде всплеска пакетов. Неравномерный режим отправки пакетов приводит к повышению числа потерь. Поскольку средняя длина очередей в сетевых устройствах близка к максимальной, то вероятность потери сегментов в пределах всплеска повышается.
4. Механизм управления передачей ТСР
зависит от потока подтверждений в обратном направлении, прибытие которых заставляет перемещаться окно и разрешает отправку новых сегментов. Такой режим называют синхронизированным по подтверждениям. Его эффект не заметен для симметричных каналов, однако для каналов, чьи свойства в различных направлениях различны, синхронизация по подтверждениям ведет к ограничению эффективности использования ресурсов. Это относится к асимметричным системам: «спутниковый/наземный каналы» и
«кабельный модем/коммутируемое соединение». Модификации протокола ТСР. Как известно, протокол ТСР ориентирован на соединение, используя для транспортировки 1Р-дейтограммы, которые пересылаются посредством протокольных кадров. Между двумя партнерами может быть прямое соединение, а может располагаться большое число сетевых приборов. Если потоки входящих и выходящих сегментов для заданного сетевого устройства равны, режим стационарен и состояние его буферов не меняется. Но маршрутиза-
торы и переключатели обычно являются многоканальными устройствами. По этой причине, если даже партнеры TCP-соединения рассчитаны на идентичную скорость обмена, возможна ситуация, когда некоторое сетевое устройство, вовлеченное в обмен, окажется перегруженным. Ведь всегда могут возникать и исчезать новые сессии информационного или мультимедийного обмена, использующие частично те же сетевые устройства.
Регулирование трафика в TCP подразумевает существование двух независимых процессов: контроль доставки, управляемый получателем с помощью параметра window, и контроль перегрузки, управляемый отправителем с помощью окон перегрузки cwnd (congestion window) и ssthreth (slow start threshold). Первый процесс отслеживает заполнение входного буфера получателя, второй -регистрирует перегрузку канала, а также связанные с этим потери и понижает уровень трафика. Программа, управляющая пересылкой, никогда не пошлет больше байт, чем это задано cwnd и объявленным получателем значением window. Когда получение очередного блока данных подтверждено, значение cwnd увеличивается. Характер этого увеличения зависит от того, осуществляется медленный старт или реализуется процедура подавления перегрузки. Если cwnd меньше или равно ssthreth, выполняется медленный старт, в противном случае происходит подавление перегрузки.
Помимо окон перегрузки и получателя в TCP используется третий параметр - порог (иногда он называется порогом медленного старта ssthresh). В случае возникновения таймаута значение ssthresh делается равным CWND/2, а само значение CWND приравнивается MSS (максимальный размер сегмента). Далее запускается процедура медленного старта, чтобы выяснить возможности канала. При этом экспоненциальный рост cwnd осуществляется вплоть до значения ssthresh. Когда уровень cwnd достигнут, дальнейший рост происходит линейно с приращением MSS на каждом шагу.
Анализируя работу протокола TCP следует учитывать, что в сети Internet могут встречаться участки с разными протоколами (Ethernet, ATM, SDH, Frame Relay, PPP и т.д.). Эти технологии имеют разные алгоритмы обработки ситуаций перегрузки (или не иметь их вовсе), а отправитель и получатель, как правило, не имеют данных о том, какие протоколы канального уровня реализуют виртуальное соединение на транспортном уровне.
В настоящее время предложено и опробовано несколько разновидностей протокола TCP.
TCP-Tahoe. Алгоритм TCP-Tahoe является наиболее старым и широко распространенным. Если буфер переполнен, какое-то число сегментов будет потеряно. При этом может быть запущено несколько сценариев. Основной вариант - медленный старт, запускается в рамках классического алгоритма TCP-Tahoe при потере сегмента и сопряженным с ним таймаутом (RTO) у отправителя, так как отправитель не получит сигнала подтверждения ACK для потерянного сегмента. Медленный старт предполагает установку окна перегрузки (CWND) равным единице, а порога медленного старта (ssthresh) равным половине значения CWND, при котором произошел таймаут. Сокращение CWND до единицы происходит потому, что отправитель не имеет никакой информации о состоянии сети. Далее после каждого подтверждения CWNDi+1 = CWNDj+1. Эта формула работает до тех пор, пока CWND не станет равным ssthresh, т.е. пороговому значению. После этого рост CWND становится линейным. Смысл этого алгоритма заключается в удержании значения CWND в области максимально возможных значений. По существу эта оптимизация осуществляется с помощью потери пакетов. Если потери пакетов не происходит, значение CWND достигает значения window по умолчанию, задаваемого при конфигурации ТСР-драйвера.
Потерянный пакет и все посланные после него пакеты (вне зависимости от того, подтверждено их получение или нет) пересылаются повторно. При большой вероятности потери это существенно понижает пропускную способность и увеличивает и без того высокую загрузку канала. При потере пакета CWND делается равным единице, так как эффективность канала максимальна при наибольшем, возможном значении CWND.
TCP-Reno. В протоколе TCP-Reno при нормальной ситуации размер окна меняется циклически и увеличивается до тех пор, пока не произойдет потеря сегмента. Протокол TCP-Reno имеет две фазы изменения размера окна: фаза медленного старта и фаза избежания перегрузки. В фазе быстрого восстановления размер окна увеличивается на один пакет, когда получается дублированное подтверждение.
В настоящее время наиболее популярной является модель NewReno, изложенная в документе RFC-3782 (апрель 2004) и использующая алгоритм Fast Retransmit & Fast Recovery (быстрая повторная пересылка и быстрое восстановление). В случае, когда доступна опция выборочного подтвер-
ждения (SACK), отправитель знает, какие пакеты следует переслать повторно на фазе быстрого восстановления (Fast Recovery). В отсутствии опции SACK нет достаточной информации относительно пакетов, которые нужно послать повторно. При получении трех дублированных подтверждений (DUPACK) отправитель считает пакет потерянным и посылает его повторно.
После этого отправитель может получить дополнительные дублированные подтверждения, так как получатель осуществляет подтверждение пакетов, которые находятся в пути, когда отправитель перешел в режим Fast Retransmit. В случае потери нескольких пакетов из одного окна отправитель получает новые данные, когда приходит подтверждение для повторно посланных пакетов. Если потерян один пакет и не было смены порядка пакетов, тогда подтверждение этого пакета будет означать успешную доставку всех предыдущих пакетов до перехода в режим Fast Retransmit. Однако, если потеряно несколько пакетов, тогда подтверждение повторно посланного пакета означает доставку некоторых, но не всех, пакетов, посланных до перехода в режим быстрой повторной пересылки (Fast Retransmit). Такие подтверждения называются частичными. Разработчики назвали алгоритм быстрого восстановления NewReno, так как он значительно отличается от базового алгоритма Reno, описанного в RFC-2581. Предложенный алгоритм дает определенные преимущества по сравнению с каноническим Reno при самых разных сценариях. Однако, при одном сценарии канонический Reno превосходит NewReno - это происходит при изменении порядка следования пакетов. Алгоритм NewReno использует переменную recover (восстановление), исходное значение которой равно исходному номеру пакета. TCP-Vegas. Протокол Vegas представляет собой улучшенную реализацию протокола TCP по сравнению с распространенными реализациями протоколов Tahoe и Reno. Улучшения, предложенные в системе Vegas, затрагивают в основном механизм быстрой ретрансляции. В алгоритме Vegas используется более точный способ определения необходимости быстрой ретрансляции потерянных сегментов. Этот алгоритм использует значения временной метки в заголовке сегментов. Таким образом, протокол Vegas лучше, чем TCP, реагирует на ситуации, в которых происходит потеря более чем одного сегмента в пределах окна, и с которыми не может эффективно бороться стандартный механизм ускоренной ретрансляции. Также в рамках
этого механизма протокол Vegas более точно управляет размером окна в процессе ретрансляции. Для реализации контроля перегрузки алгоритм Vegas сохраняет значение минимального Rtt в переменной Base RTT=min(BaseRTT, RTT). Ожидаемое значение пропускной способности определяется по формуле Expected =размер_окна/ Base RTT. Далее, реальная ПС периодически вычисляется как число байт, переданных с момента отправки определенного сегмента и до прихода его подтверждения. Разность реальной и ожидаемой ПС определяет выбор режима линейного увеличения или уменьшения окна.
Протокол TCP-Vegas контролирует размер окна путем мониторинга отправителем RTT для пакетов, посланных ранее. Если обнаруживается увеличение RTT, система узнает, что сеть приближается к перегрузке и сокращает ширину окна. Если RTT уменьшается, отправитель определит, что сеть преодолела перегрузку, и увеличит размер окна. Следовательно, размер окна в идеальной ситуации будет стремиться к требуемому значению. Эта модификация TCP требует высокого разрешения таймера отправителя.
Поскольку основной алгоритм Vegas полностью взят от протокола TCP, то все основные недостатки, присущие TCP, характерны и для него. Сравнительный анализ модификаций TCP. Использование групповых подтверждений в TCP мотивирует в протоколе TCP-Tahoe сокращение ширины окна до единицы после потери, чтобы избежать всплеска пакетов из-за повторной их передачи. Это в свою очередь приводит к экспоненциальному увеличению размера окна при медленном старте, необходимому для сетей с большим произведением полосы на задержку. С другой стороны, это экспоненциальное увеличение вызывает серьезные флуктуации трафика, которые, если размер буфера меньше чем 1/3 от произведения полосы на задержку, вызывает переполнение буфера и второй медленный старт, понижая ПС. Протокол TCP-Reno пытается избежать этого явления путем сокращения окна вдвое при обнаружении потери. В то время как это при идеальных условиях обеспечивает улучшенную ПС, TCP-Reno в его нынешнем виде слишком уязвим для фазовых эффектов и множественной потери пакетов, чтобы стать заменителем для TCP-Tahoe. Основной проблемой с TCP-Reno является то, что могут быть множественные ограничения на окно, связанные с одним эпизодом перегрузки, и что множественные потери могут приводить к таймауту (который на прак-
тике вызывает значительное снижение пропускной способности, если используются таймеры с низким разрешением). Предложенная версия протокола TCP-Vegas пытается реализовать ряд усовершенствований, таких как более изощренная обработка и оценка RTT. Но для флуктуаций RTT в Internet существует много других причин помимо заполнения буфера. Для того чтобы существенно улучшить существующие версии TCP, необходимо избегать резких сокращений размеров окна как в TCP-Tahoe, так и в TCP-Reno за исключением случая, когда имеет место продолжительная перегрузка. Одним возможным средством обработки изолированных потерь без изменения размера окна является использование некоторой формы селективного подтверждения. В ожидании разработки удовлетворительного нового варианта предлагается использовать протокол TCP-Tahoe, так как этот вариант несравненно устойчивей, чем протокол TCP-Reno.
Анализ влияния размера буфера на параметры сети. Задачей моделирования является анализ изменений основных показателей модификаций протокола TCP в процессе изменения размера буфера в маршрутизаторе. Эксперименты проводились при значениях размера буфера 10, 20, 30, 40, 50 пакетов.
Анализ зависимостей, представленных на рис. 2 показывает, что в обоих имитационных моделях изменение размера буфера оказывает существенное влияние на работу модификации. Исключением является модификация TCP-Vegas, значения скорости передачи которой остаются стабильными на уровне 46080 кбит/с. Модификации TCP-Reno и Newreno идентичны и увеличивают значение скорости на 101,2% - для модели №1 и на 105,2% - для модели №2. Модификация TCP Tahoe показывает наибольшее изменение (на 105,9 % - для модели №1 и на 112% - для модели №2) и меньшую скорость источников.
Анализ зависимостей, представленных на рис. 3, показывает, что увеличение размера буфера сказывается на увеличении времени задержки пакетов практически для всех модификаций, кроме TCP-Vegas, показывающий относительную стабильность в обоих моделях с величиной задержки 0,036 мс. Модификации TCP-Reno и Newreno идентичны и увеличивают значение задержки на 558% - для модели №1 и на 787% - для модели №2. Модификация TCP-Tahoe - на 500% (для модели №1) и на 744% (для модели №2).
Анализ зависимостей рис. 4 подтверждает предыдущие выводы о линейном увеличении времени вариации задержки при увеличении размера буфера. Модификация TCP-Vegas также отличительно стабильна и имеет минимальную вариацию, равную 7 мкс - для модели №1 и 10 мкс -для модели №2. Вариация задержки модификаций Tahoe, Reno и Newreno при размере буфера 10 пакетов идентична и равна 130 мкс для обоих моделей. Модификации TCP Reno и Newreno увеличивают значение вариации задержки на 1129% - для модели №1 и на 1361% - для модели №2. Модификация Tahoe - 1284% и 1924% соответственно.
Анализ зависимостей, представленных на рис. 5, показывает уменьшение значения коэффициента потерь для всех модификаций. Значительное уменьшение потерь испытывают практически одинаково модификации Reno, Newreno (на
0,021% - для модели №1 ина 0,019% - для модели №2) и Tahoe (на 0,02% и 0,019% соответственно). Алгоритм работы TCP-Vegas практически исключает потери.
Анализ зависимостей, полученных при исследовании влияния размера буфера на параметры сети позволяет сделать следующие выводы:
наблюдается превосходство TCP-Vegas по всем исследуемым параметрам. Так, изменение размера буфера практически не влияет на общую скорость передачи, задержку и вариацию задержки пакетов модификаций TCP-Vegas. Число потерь значительно меньше по сравнению с остальными модификациями;
модификации TCP-Reno и Newreno практически идентичны по всем показателям;
TCP-Tahoe показывает наибольшую неустойчивость при изменении размера буфера в обоих имитируемых моделях.
Анализ влияния задержки канала на параметры сети. Задачей моделирования является анализ изменения основных показателей модификаций протокола TCP в процессе изменения задержки канала WAN. Проведем эксперименты при значениях задержки канала 10, 20, 30, 40, 50 мс.
Анализ зависимостей, представленных на рис. 6, означает, что в обоих имитационных моделях одинаково стабильно ведет себя модификация TCP-Vegas на уровне 46080 кбит/с. Модификации TCP-Reno и Newreno изменяют свое значение на 2,5% - для модели №1 и на 3,1% - для модели №2. TCP Tahoe показывает сравнительно меньшую скорость источников и наибольшее изменение на 12% - для модели №1 ина 5% - для модели №2.
/ І
; г'
Рис. 2. Общая скорость передачи Парето источников при изменении размера буфера
Рис. 3. Изменения задержки пакетов при изменении размера буфера
Рис. 4. Вариации задержки пакетов при изменении размера буфера
Рис. 5. Графики зависимости коэффициента потерь от изменения размера буфера
Рис. 6. Г рафики изменения общей скорости передачи Парето источников при изменении задержки канала
Анализ зависимостей, представленных на рис. 7, показывает, что увеличение времени задержки канала сказывается на незначительном уменьшении времени задержки пакетов практически у всех модификаций обоих моделях. Задержка пакетов в буфере модификации TCP-Vegas изменяет свое значение на 7,5% - для модели №1 и на 13,2% - для модели №2, TCP-Reno и Newreno на 26,5% - для модели №1 и на 32% - для модели №2, TCP-Tahoe на 20% - для модели №1 и на 21,5% - для модели №2.
Анализ зависимостей рис. 8, показывает увеличение вариации задержки при увеличении задержки канала у модификаций Reno, Newreno и Tahoe. Модификация TCP-Vegas также отличительно стабильна и имеет минимальную величину вариации и увеличение на 737% - для модели №1 и на 185% - для модели №2, TCP-Reno и Newreno на 227% - для модели №1 и на 166% - для модели №2, TCP Tahoe на 167% - для модели №1 и на 105% - для модели №2.
Анализ зависимостей, представленных на рис. 9, означает уменьшение значения коэффициента потерь при увеличении задержки канала у всех модификаций. Уменьшение потерь на 47% -
для модели №1 и на 50% - для модели №2 испытывают практически одинаково модификации Reno, Newreno и Tahoe. Алгоритм работы TCP-Vegas полностью исключает потери и неизменен при изменении задержки канала.
Анализ зависимостей, полученных при исследовании влияния задержки канала на параметры сети позволяет сделать следующие выводы: стабильная скорость источников Парето при изменении задержки канала позволяет судить об устойчивости модификации TCP-Vegas. Увеличение задержки отрицательно сказывается на работе TCP-Tahoe, вызывая уменьшение скорости источников Парето; алгоритмы работы модификаций Reno и Newreno практически идентичны по всем параметрам. Увеличение задержки канала положительно сказывается на коэффициенте потерь, уменьшая его значение у всех модификаций. Анализ влияния пропускной способности канала на параметры сети. Задачей моделирования является иллюстрация изменения основных показателей модификаций протокола TCP в процессе изменения пропускной способности канала WAN. Исследования проводились при значениях ПС 64, 128, 256, 512, 1024 Кбит/с.
Рис. 7. Г рафики изменения времени задержки пакетов при изменении задержки канала
Рис. 8. Вариации задержки пакетов при изменении задержки канала
Рис. 9. Г рафики изменения коэффициента потерь при изменении задержки канала
Анализ зависимостей, представленных на рис. 10, показывает увеличение общей скорости источников при увеличении пропускной способности канала на 1600% - у модификации TCP-Vegas на 1600% - для модели №1 и №2, у TCP-Reno и Newreno на 1562% - для модели №1 и на 1534% - для модели №2, TCP-Tahoe на 1400% -для модели №1 ина 1375% - для модели №2.
Анализ зависимостей, представленных на рис. 11, показывает, что увеличение ПС канала положительно сказывается на работе модификаций, уменьшая значение задержки модификации TCP-Vegas на 96,5% - для модели №1 и №2; TCP-Reno на 96,4% - для модели №1 и на 96,7% - для модели №2; Newreno на 96,2% - для модели №1 и на 97,8% - для модели №2; TCP-Tahoe на 96% -для модели №1 и №2.
Проанализировав рисунки, можно сделать вывод, что значительное уменьшение вариации задержки пакетов в буфере происходит при увеличении ПС до 256 кбит/с. Уменьшение вариации задержки TCP-Vegas сравнительно минимальны. Изменение TCP-Reno на 98,6% - для модели №1 и на 98,5% - для модели №2; Newreno на 98,3% для модели №1 и на 98,1% - для модели №2; TCP-
Tahoe на 98,9% - для модели №1 и на 99% - для модели №2.
Анализ рис. 12 дает идентичное снижение коэффициента потерь в обоих моделях для всех модификаций. Алгоритм работы TCP-Vegas практически исключает потери.
Анализ рис. 13 показывает уменьшение значения коэффициента потерь для всех модификаций. Уменьшение потерь на 67% - для модели №1 и на 75% - для модели №2 испытывают одинаково модификации Reno и Newreno. Модификация TCP-Tahoe дает уменьшение потерь на 66,8% и 76,5% соответственно. Алгоритм работы TCP-Vegas практически исключает потери.
Анализ зависимостей, полученных при исследовании влияния пропускной способности канала на параметры сети позволяет сделать следующие выводы: увеличение ПС канала вызывает пропорциональное увеличение скорости источников Парето и резкое уменьшение задержки и вариации задержки пакетов у всех исследуемых модификаций; теоретическое снижение коэффициента потерь подтверждается практическими показателями. Наилучшие показатели имеет модификация TCP-Vegas.
Рис. 10. Графики изменения общей скорости передачи Парето источников при изменении пропускной способности канала
Рис. 11. Задержка пакетов при изменении пропускной способности канала
8000 6000 4000 2000 0000 8000 6000 4000 2000 0
0 128000 256000 384000 512000 640000 768000 896000 1024000
Пропускная способность канала, бит/с
Рис. 12. Вариации задержки пакетов при изменении пропускной способности канала
Рис. 13. Графики изменения коэффициента потерь при изменении пропускной способности канала
Анализ влияния пропускной способности обратного канала на параметры сети. Задачей моделирования является иллюстрация изменения основных показателей модификаций протокола TCP в процессе изменения пропускной способности обратного канала WAN. Проведем эксперименты при значениях ПС 28,8, 33,6, 56 кбит/с.
Анализ зависимостей, представленных на рис. 14, показывает, что в модели №1 изменение ПС обратного канала оказывает заметное влияние на TCP-Vegas. Модификации Reno, Newreno и Tahoe имеют наименьшее изменение, на 107,5% и 101% соответственно, и преимущество в значении общей скорости источников, в сравнении с нарастающими показаниями Vegas на 194%. Для модели №2 изменение ПС обратного канала не принципиально и не изменяет общую скорость передачи Парето источников. Наилучшую скорость показывает модификация TCP-Vegas на уровне 46080 кбит/с, Reno и Newreno на уровне 45795 кбит/с, Tahoe на уровне 42541 кбит/с.
Анализ зависимостей, представленных на рис. 15, означает увеличение времени задержки с увеличением ПС обратного канала. Модификация
TCP-Reno изменяет значение на 167% - для модели №1; Newreno на 168% - для модели №1; TCP-Tahoe на 130% - для модели №1. Время задержки при изменении ПС обратного канала у модификации TCP-Vegas равно нулю. В модели №2 наблюдаются стабильные показания задержки пакетов модификации TCP-Vegas на уровне 43,6 мс, Reno и Newreno - на уровне 42,25 и 42,37 мс, Tahoe - на уровне 39 мс, что свидетельствует о непринципиальном изменении ПС обратного канала.
Анализ зависимостей, представленных на рис. 16 показывает, что вариация задержки пакетов для модели № 1 увеличивается при увеличении ПС. Модификация TCP-Reno изменяет значение на 176% - для модели №1; Newreno - на 158% (для модели №1) TCP-Tahoe - на 146% (для модели №1). Время задержки при изменении ПС обратного канала у модификации TCP-Vegas равно нулю. В модели №2 наблюдаются стабильные показания задержки пакетов модификации TCP-Vegas на уровне 24,8 мкс, Reno и Newreno - на уровне 503 мкс и 517 мкс, Tahoe - на уровне 581 мкс, что свидетельствует о непринципиальном изменении ПС обратного канала для модели №2.
обратного канала
Рис. 16. Вариации задержки пакетов при изменении пропускной способности обратного канала для моделей №1 и №2
Анализ зависимостей рис. 17 показывает, что увеличение ПС обратного канала сказывается на увеличении коэффициента потерь на 408% - для модели №1 модификации TCP-Reno; на 365% -для модели №1 модификации TCP-Newreno; на 833% - для модели №1 модификации TCP-Tahoe. Потери при работе модификации TCP-Vegas отсутствуют.
общей скорости Парето при изменении ПС обратного канала.
В модели № 1 увеличение ПС обратного канала увеличивает задержку и вариацию задержки практически одинаково. Потери отсутствуют у модификации TCP-Vegas.
Рис. 17. Графики изменения коэффициента потерь при изменении пропускной способности обратного канала
В модели №2 наблюдаются стабильные показания коэффициента потерь TCP-Vegas на уровне 0%, Reno и Newreno - на уровне 1,87%, Tahoe - на уровне 2,09%, что свидетельствует о непринципиальном изменении ПС обратного канала для модели №2.
Анализ зависимостей, полученных при исследовании влияния пропускной способности обратного канала на параметры сети позволяет сделать следующие выводы: основные параметры всех модификаций стабильны для модели №2, что говорит о непринципиальном изменении ПС обратного канала для данной модели; TCP-Vegas существенно отличается, реагируя изменением
ЛИТЕРАТУРА
1. Шелухин О.И., Тенякшев А.М., ОсинА.В. Фрактальные процессы в телекоммуникациях. Монография./ Подред. О.И. Шелухина. - М.: Радиотехника, 2003.
2. Fall, K. and S. Floyd, «Simulation-based Comparisons of Tahoe, Reno and SACK TCP», Computer Communication Review, July 1996.
3. V. Jacobson, «Modified TCP congestion avoidance algorithm» message to end2end-interest mailing list, April 1990.
4. http://www.isi.edu/nsnam/ns/ns-documentation.html
Поступила 13. 03. 2008 г.
тз
