Lab 241

Данный проект выполняется в рамках программы РАН «Математические и алгоритмические проблемы информационных систем нового поколения». В рамках проекта рассматривалась возможность построения виртуальных сетей на основе протокола MPLS с гарантированным качеством обслуживания (Diff-Serv - QoS). Для решения задачи анализировались различные модели доставки пакетов в протоколах ICMP, UDP, TCP и MPLS.

Актуальность данного проекта подтверждается потоком публикаций RFC по проблематике MPLS и Diff-Serv (смотри позиции [3-23] c августа 2002 по октябрь 2004 года). Это и не удивительно, так как интеграция Интернет и мультимедийных приложений становится все более злободневной. В 2003 году появилась обобщенная версия протокола MPLS (смотри [9], [10], и [11] - GMPLS – RFC-3771-74), где понятие метки расширено и стало охватывать длины волн, диапазоны длин волн, идентификаторы волокон и каналов. Данная тенденция определяется широким внедрением l-коммутации и других оптоволоконных технологий. Широкое внедрение GMPLS увеличит перспективы применимости техники Diff-Serv.

Архитектура протокола MPLS [RFC3031] была определена для переадресации пакетов на основе меток. В этой архитектуре предполагается, что маршрутизаторы LSR способны (a) распознавать границы пакетов или ячеек, и (b) могут обрабатывать заголовки пакетов (для LSR, способных распознавать границы пакетов) или заголовки ячеек (для LSR, способных распознавать границы ячеек).

Исходная архитектура теперь распространена на LSR, которые не могут распознавать ни границы пакетов, ни границы ячеек, и, следовательно, не могут переадресовать данные на основе информации, содержащейся в заголовках пакетов или ячеек. Такие LSR в частности включают в себя приборы, где решение о переадресации принимается на основе временного домена, длины волны или номера физического порта.

При предоставлении дифференцированных услуг Diff-Serv (Differentiated Service) все IP-пакеты, проходящие через канал и требующие того же уровня Diff-Serv, образуют ансамбль BA (Behavior Aggregate). Во входном узле области Diff-Serv, пакеты классифицируются и помечаются с помощью кода DSCP (Diff-Serv Code Point), который соответствует ансамблю BA. В каждом промежуточном узле, DSCP используется для определения пошагового поведения PHB (Per Hop Behavior), которое задает последовательность обработки и, в некоторых случаях, вероятность отбрасывания пакетов. Схема, описанная в RFC-3270, не препятствует использованию битов поля EXP для поддержки явного уведомления о перегрузке ECN (Explicit Congestion Notification) совместно с Diff-Serv в рамках MPLS. Появилось расширение протокола RSVP (RSVP-TE) для LSP-туннелей, что обогащает арсенал инструментов управления QoS.

Во всех остальных отношениях новые модификации протокола MPLS не отличаются от базовой. По этой причине результаты, полученные для традиционного протокола MPLS могут быть автоматически распространены на GMPLS.

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

Для решения поставленной задачи была установлена и сконфигурирована ЭВМ в ИАЭ (см. рис. 2), сконфигурированы маршрутизаторы для обеспечения пропускания исследовательского трафика между ПРАН и ИАЭ. Проводилось изучение влияния параметров алгоритма организации очередей (WRED) на достижимое качество обслуживания. Хотя номинально оборудование АТМ (LC-ATM) способно обеспечивать определенный уровень качества обслуживания в рамках протокола MPLS, на данном этапе такая возможность не реализовывалась. Были разработаны скрипты для укладки и извлечения результатов измерений из базы данных. Написаны и отлажены модули программ для анализа корреляций параметров, определяющих качество обслуживания. Исследована возможность формирования комплексного параметра, характеризующего качество обслуживания.

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

Маршрутизаторы сконфигурированы для обеспечения поддержки QoS (DSCP) в рамках протокола MPLS. Особенностью работы тестовой сети являлось то, что виртуальный канал (VPN) между C-7206 (ПРАН) и С-6506 (ИАЭ) имел полосу пропускания около 2Мбит/с. Такой режим работы приводит к тому, что при работе с пакетами ICMP достигается высокая (50% и более) вероятность потери пакетов (чего нет при работе с протоколом ТСР). Одной из задач исследования было определение структуры буферизации в виртуальном канале. Для этого измерения проводились для пакетов разной длины (64, 128, 256, 512, 1024 и 1450 байт).

Исследовательский сервер проекта размещен в здании президиума РАН по адресу http://saturn.rasnet.ru. Доступ к нему ограничен списком участников проекта. Базовая WEB-страница сервера показана на рис. 1.

Виртуальный канал проходил от тестовой ЭВМ в ПРАН через маршрутизатор CISCO-7206, интерфейс АТМ, далее через сеть АТМ в маршрутизатор CISCO-7206 в Институте Атомной Энергии и переключатель в другую тестовую машину. Два базовых узла (ПРАН и ИАЭ им. Курчатова соединялись через VPC АТМ в режиме UBR. Смотри рис.2.

Целью данного проекта являлась разработка методики оптимальной оценки QoS и опробование ее на практике. Надо было выяснить, какие реальные параметры качества обслуживания достижимы при определенных конфигурационных характеристиках сетевых устройств, как влияет QoS наличие приборов, не поддерживающих Diff-Serv, например, переключателей L2. Рассматривалась возможность адаптации конфигураций маршрутизаторов, поддерживающих Diff-Serv к конкретным условиям. Были усовершенствованы инструментальные программы, написанные на предыдущем этапе, некоторые программы были целиком переписаны, так как требовалось совместить функции контроля сразу нескольких параметров.

Выбранная схема позволяла осуществлять удаленный доступ к тестовым ЭВМ, допуская запуск программ на любой из машин. Поскольку разрабатываемое программное обеспечение предполагается использовать как инструментальное для оценки качества обслуживания в реальных каналах, эти программы должны создавать минимальную загрузку в виртуальных каналах. Программы были написаны так, чтобы данные, полученные для каждого из кадров, использовались для оценки RTT, его дисперсии, вероятности потери пакетов, а также для оценки реальной полосы пропускания. Виртуальный канал через сеть АТМ имел полосу 2 Мбит/с, что облегчало создание закритических режимов с точки зрения перегрузки.

Программы позволяют запускать один или более параллельных потоков пакетов заданной длины. Длительность потоков также конфигурируется. Программа мастер посылает запрос ЭВМ клиента. Последняя запускает дочерний процесс, воспринимающий кадры от программы мастера. Подсчитывает полученные пакеты и записывает их идентификаторы. По завершении сессии программа ликвидирует дочерний процесс и посылает программе мастеру результат приема, включая длительность работы дочернего процесса.

Кроме того, маршрутизаторы сконфигурированы для обеспечения поддержки QoS (DSCP) в рамках протокола MPLS. Особенностью работы тестовой сети являлось то, что виртуальный канал (VPN) между C-7206 (ПРАН) и С-6506 (ИАЭ) имел полосу пропускания около 2Мбит/с. Такой режим работы приводит к тому, что при работе с пакетами ICMP достигается высокая (50% и более) вероятность потери пакетов (чего нет при работе с протоколом ТСР). Одной из задач исследования было определение структуры буферизации в виртуальном канале. Для этого измерения проводились для пакетов разной длины (64, 128, 256, 512, 1024 и 1450 байт). Измерения зависимости вероятности потери пакетов проводились как для канала ПРАН - ИММ РАН (Екатеринбург), так и для сети, показанной на рис. 2. Для обеспечения корректной интерпретации получаемых результатов была написана программа анализа структуры трафика с привлечением утилиты NetFlow.

Эта программа гарантировала то, что все перечисленные параметры измеряются в одних и тех же условиях. При этом предусматривается одновременное пропускание между конечными точками трех потоков данных с разными значениями флагов DSCP. В начале цикла работы программа посылает запрос установления соединения, после формирования виртуальной связи запускается новый процесс (процедура fork) и начинается прием сегментов и отправка подтверждений получения. Скорость обмена измеряется как со стороны клиента, так и со стороны сервера (вычисления проводит каждый из процессов). Значение RTT вычисляется для каждого из сегментов. Одновременно производится оценка дисперсии RTT. Такая схема измерений минимизирует служебную составляющую измерительного процесса.

Используя программы, формирующие 2 и более потоков данных с разными значениями флага DSCP измерены зависимости RTT его дисперсии и вероятности потери, а также эффективного значения пропускной способности виртуального канала. Измерения показали, что данная методика пригодна для интегральной оценки объема буферов удаленных сетевых устройств.

Результаты измерений показали, что даже при ограниченных возможностях конфигурирования сетевой среды в области VPN можно получить для приоритетных потоков (DSCP=10) приемлемое качество обслуживания, причем это достижимо в условиях существенной перегрузки каналов. Можно предполагать, что сервис-провайдер, которому доступно конфигурирование всей VPN, может достичь еще большего многообразия уровней услуг.

Программы анализа и модификации модели реализации протокола ТСР позволили измерить эволюцию CWND со временем и сформировать инструментальную среду для экспериментального изучения различных моделей работы протокола ТСР.

На основе проведенных исследований Diff-Serv сформулированы требования для принципиально новой модели ТСР и концепции построения сетей, где требуемый уровень QoS может быть гарантирован на рабочем месте любого пользователя (уровень L2).

На рис. 3 показан результат работы программы, способной не только выявлять активные IP-адреса в заданной области, но также измерять и отображать информационные потоки, сопряженные с этими адресами. Программа использовалась для анализа распределения трафика и влияния его компонент на конкретные результаты измерений.

Рис. 3. Составляющие трафика в тестовом канале для различных IP-адресов

Написана и отлажена программы для исследования эволюции CWND с целью сопоставления различных моделей протокола ТСР. Программа представляет собой модуль, который взаимодействует с демоном inetd. Программа предназначена для опробования различных моделей реализации протокола ТСР, в том числе и совершенно новых версий (в частности разработанной в рамках проекта). Примеры работы программы представлены на рис. 4. На рис. 4 показана эволюция CWND со временем, значение CWND измеряется в сегментах (а не в байтах).

Измерения проводились в среде ОС LINUX. Выяснилось, что там реализовывалась модель RENO с алгоритмом медленного старта, где минимальное значение CWND равно двум. Значение window = 45, что определяется плато на диаграммах. Темп роста CWND на линейном участке является конфигурируемым параметром.

Экспоненциальная часть достаточно коротка (по отношению к линейной области), что говорит о малой вероятности потери пакетов и низком уровне перегрузки, что действительно имеет место в сети, где осуществлялись измерения.

Задачей программы было не только выявление модели реализации протокола ТСР, но и вариации модели, а в перспективе и радикальное изменение модели реализации протокола ТСР с целью повышение эффективности использования канала (смотри раздел “Новый протокол ТСР”).

Подготовлены программы для анализа причин потерь пакетов в удаленных сетях с использованием пакетов переменной длины (разделение случаев повреждений пакетов в пути и случаев переполнения буферов в промежуточных сетевых устройствах). Задачей этих программ было исследование причин потерь пакетов. Если буферы сетевых устройств ориентированы на запись определенного числа пакетов (а в современных приборах так оно и есть), то зависимости вероятности потерь от длительности пакета не должно быть. Вероятность же потерь из-за повреждения пакетов при транспортировке пропорциональна длине пакета, и можно ожидать экспоненциальной зависимости числа потерянных пакетов от их длины.

Программа опробована в тестовой сети и для маршрута ПРАН - ИММ (Екатеринбург) и для тестовой сети, показанной на рис. 2. Создан динамический комплекс визуализации результатов исследований, полученных с помощью написанной программы. На WEB-странице отображаются обновляющиеся каждые 20 минут суточные и недельные зависимости потерь пакетов 6-ти разных длин (64, 128, 256, 512, 1024, 1450 байт, смотри рис. 5), а также график, на котором одновременно отображаются результаты измерений потерь пакетов разной длины за ближайшие 3 часа. При обработке получаемых результатов учитываются данные о входных и выходных потоках в канале, которые также постоянно обновляются и отображаются в виде суточных и недельных зависимостей на WEB-странице.

Конфигурация маршрутизаторов тестовой сети (в ПРАН и в ИАЭ) адаптирована для обеспечения Diff-Serv (QoS). Обработка очередей там осуществляется с привлечением алгоритма WRED. Исследована возможность адаптации виртуального канала ATM для решения задач обеспечения требуемого уровня QoS. Написана программа, которая формирует одновременно несколько потоков данных с различными значениями флагов DSCP. Число потоков, длина пакетов и их период являются конфигурируемыми параметрами. Программа предназначена для синхронного измерения пропускной способности, вероятностей потери пакетов, времени обработки кадров в очередях маршрутизатора (и его дисперсии) и некоторых других характеристик. Программа опробована при разных значениях параметров WRED и разном распределении ресурсов АТМ-канала.

При отправке кадров (например, ICMP) формируется таблица идентификаторов и временных меток пакетов. При получении откликов проверяется наличие идентификатора пакета в таблице, если он там присутствует, вычисляется значение RTT, одновременно копятся данные по числу потерянных кадров в тестовой серии. Разделение потоков программой производится по PID процесса, помещаемого в случае ICMP в поле идентификатор.

Для исследования зависимости RTT и вероятности потери пакетов от DSCP использована программа, способная формировать несколько потоков пакетов для любых протоколов (UDP, TCP и ICMP). Каждый из потоков может иметь разные флаги DSCP. Регистрация доставки может контролироваться по откликам получателя (т.е. отправителем) или непосредственно получателем (ЭВМ в ИАЭ). Программа устроена так, что она может посылать пакеты с заданным периодом, не ожидая отклика от получателя, что существенно увеличивает скорость накопления данных и позволяет варьировать загрузку канала в широких пределах. Точность измерения RTT составляла 1 микросекунду. При измерении зависимости потерь от длины пакета для каждой точки посылалось 4000 пакетов.

Рис. 5. Зависимость вероятности потери пакета от его длины

На рис. 6 и 7 показаны результаты измерения зависимости вероятности потери пакета от длины пакета для маршрута ПРАН – ИММ (Екатеринбург) в разное время суток. Измерения проводились при 6 значениях длительности пакетов (64, 128, 256, 512, 1024 и 1450 байт). В этой серии измерений для каждой длины посылалось по 100 пакетов. Полиномиальная аппроксимация зависимости осуществлялась с использованием метода наименьших квадратов.

Эта аппроксимация указывает на то, что потери происходят из-за искажений пакетов, либо по пути имеются буферы, где пакеты выкладываются побайтно (объем задан не числом сегментов, а числом байт). В любом случае предлагаемый метод показал, что с его помощью можно исследовать свойства каналов и определять их рабочие характеристики.

Рис. 6. Зависимость вероятности потери пакета от длины пакета для маршрута ПРАН – ИММ (Екатеринбург)

Рис. 7. Зависимость вероятности потери пакета от длины пакета для маршрута ПРАН – ИАЭ

Сравнение результатов для каналов ПРАН-Екатеринбург и ПРАН-ИАЭ показывает, что в первом случае заметное влияние на потери, вероятно, оказывает повреждение пакетов в пути. Во втором случае вероятность потери более чем в 20 раз меньше и практически не наблюдается зависимости вероятности потери от длины пакета. Эти данные показывают, что исследование зависимости вероятности потери от длины пакета можно считать полезным диагностическим средством при исследовании свойств каналов и выявления потерь, сопряженных с искажениями передаваемых кадров.

Здесь следует помнить о характере обменов в сетях АТМ. Наши длинные пакеты инкапсулируются в последовательности ячеек по 53 байта каждая. В интерфейсе С-6506 производится обратная процедура сборки. Интерфейсы реализует эту процедуру через уровни адаптации AAL1-AAL5. Но коммутаторы АТМ могут быть перегружены и это может наложить отпечаток на наши измерения. Пропускная способность виртуального канала измерялась двумя разными программами. Программы давали идентичные результаты, которые варьировались от 1,8 до 2,3 Мбит/c.

Параллельно измерялись потоки пакетов для входного и выходного интерфейсов CISCO-7206 в ПРАН (для обоих направлений) (смотри рис. 8). При этом задавались следующие параметры обработки очередей для входного интерфейса сети АТМ (WRED, маршрутизатор CISCO-7206, интерфейс АТМ; маршрутизатор со стороны ИАЭ имел другую конфигурацию):

bandwidth percent 10 -- использовать 10% от 2 Мбит/c
random-detect dscp-based random-detect exponential-weighting-constant 7
Экспоненциальный параметр WRED = 7
Для DSCP = 10.
random-detect dscp 10 300 400 1000
Нижний порог отбрасывания = 300 пакетов; верхний порог - 400 пакетов,
разрешается терять 1 пакет на 1000. (Mark denominator = 1000)
Для DSCP = 20.
random-detect dscp 20 50 300 500
Нижний порог отбрасывания = 50 пакетов; верхний порог - 300 пакетов,
разрешается терять 1 пакет на 500.
Для DSCP = 30.
random-detect dscp 30 10 40 10
Нижний порог отбрасывания = 10 пакетов; верхний порог - 40 пакетов,
разрешается терять 1 пакет на 10.

Mark denominator определяет долю отбрасываемых пакетов при размере очереди, соответствующем верхнему порогу (Tmax), см. рис. 8. Смотри также www.cisco.com, откуда заимствован приведенный ниже рисунок.

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

Средний размер очереди в рамках алгоритма вычисляется как:

average_queue_size = (old_average * (1-1/2ⁿ)) + (current_queue_size * 1/2 ⁿ),

где n – экспоненциальный весовой фактор (конфигурируется пользователем, см. выше). В нашем случае n = 7.

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

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

При изменении длины очереди выше минимального порога, вероятность отбрасывания пакетов растет линейно (см. рис. 7). Минимальный порог (Т_min) следует выбирать достаточно высоким, чтобы оптимизировать использование канала. При низком значении минимального порога пакеты могут отбрасываться необоснованно. Разность максимальным и минимальным порогами должна быть достаточно велика, чтобы избежать синхронизации ТСР агентов. При малой разности между порогами многие пакеты могут быть отброшены немедленно, вызывая потерю пакетов несколькими ТСР ЭВМ одновременно.

В нашем случае мы имеем два независимых потока пакетов J_in. и один исходящий поток J_out. Фактически, с точки зрения размера очереди можно считать, что входной поток равен 2 J_in. В единицу времени размер очереди увеличивается (если нет отбрасывания пакетов) на 2•J_in - J_out. Пока длина очереди не достигла T_min, отбрасывания пакетов не будет. Если установлено ограничение, например, bandwidth percent 10 (q – quote), темп роста очереди возрастает и зависимость роста очереди приобретает вид:

Значение Т_min будет достигнуто в момент t_min = Тmin /(2•J_in - J_out) после начала эксперимента. С этого времени включается механизм отбрасывания пакетов. Вероятность отбрасывания пропорциональна длине очереди.

где а – постоянный коэффициент. RTT ~ b•Q(t), где b также константа.

После достижения Т_min рост очереди замедляется из-за отбрасывания пакетов. Вероятность отбрасывания пакетов вплоть до Т_max при этом изменяется согласно:

Составляющая роста очереди 2J_inP_L(t) определяет число отбрасываемых пакетов из числа пришедших в единицу времени (2Jin). Из выражения [1] определяем зависимость P_L(t) от времени в интервале между Т_min и Т_max:

Когда длина очереди превысит Т_max отбрасываются все приходящие пакеты зависимость Q от времени будет иметь вид:

Понятно, что практически сразу длина очереди станет меньше (Q(t) < Т_max). При этом поведение алгоритма WRED будет зависеть от значения n, определяющего характер усреднения Q. В среднем длина очереди будет колебаться вблизи значения Q(t) ~ Т_max. Амплитуда этих колебаний целиком и полностью определяется значением экспоненциального фактора n (характером усреднения длины очереди). При этом значение RTT практически не будет меняться, потери пакетов также выйдут на стационарный уровень.

На рис. 9 показаны результаты эксперимента по пропусканию через тестовую сеть потоков с DSCP=0 и 30. В верхней части рисунка отображены суточные вариации входящего и исходящего потока пакетов для входного и выходного интерфейсов маршрутизатора С-7206 (см. рис. 1), а также интегрального потока октетов. Данные измерения проводились 10 ноября 2004 в 15:49:44. Считывания (MRTG-SNMP) осуществлялись раз в 5 минут, пересылка же 5000 тестовых пакетов длиной 1400 байт занимала около 1 минуты. Из диаграмм видно, что помимо измерительного потока кадров имеет место варьирующийся в течении суток поток порядка 50 пакетов в секунду (поток в направлении АТМ в несколько раз больше, чем в обратном направлении), что не могло оказать существенного влияния на результаты измерений, тем более, что “не наши” пакеты не могут иметь DSCP неравного нулю. Поток октетов соответствует потоку пакетов с длиной порядка 1500 байт. Интегрально дополнительный трафик не превышал 10% от имеющейся полосы пропускания (смотри также параметр конфигурации WRED bandwidth percent 10). Поскольку выходной поток не может быть никогда заблокирован, 100% потери пакетов на входе интерфейса при любом приоритете потока невозможны. На четвертой диаграмме показана октетная загрузка интерфейса при периодической посылке серий пакетов большой длины (более 1450 октетов с учетом размера заголовка).

С целью обеспечения большей гибкости в ICMP-пакеты не помещается при отправке временная метка, для этого формируется в оперативной памяти ЭВМ специальная таблица, куда помимо идентификаторов посланных пакетов заносится временная метка и число микросекунд от начала последней секунды. В таблицу заносится также флаг отправки, равный нулю. При получении отклика этот флаг меняется на 1.

После получения отклика RTT вычисляется с точностью до микросекунды, результат определения RTT заносится в отдельную таблицу с указанием ID пакета. Все посланные пакеты группируются по 200 и для каждой группы независимо вычисляется средние значения RTT и число потерянных пакетов.

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

Рис. 9. Результаты эксперимента (измерение потерь и RTT) по одновременной транспортировке потоков пакетов с DSCP =0 и 30.

Результаты измерения зависимости RTT и вероятности потери пакета от времени в ходе одновременной транспортировки потоков пакетов из ЭВМ в ПРАН в ЭВМ в ИАЭ показаны на нижних четырех диаграммах рисунка 8. В таком эксперименте передается 5000 пакетов. Каждая точка на диаграмме получена путем усреднения данных, полученных для 200 пакетов. Пакеты ICMP имели длину 1400 байт и следовали с периодом 10 мс, что создавало трафик более 1,1 Мбит/c. С учетом конфигурационных параметров и наличия двух потоков, это заведомо перегружало интерфейс (разрешенный предел равнялся 2 Мбит/c).

Будем исходить из предположения, что в исходный момент времени очередь пакетов в буфере маршрутизатора пуста. RTT в нашем случае определяется временем пребывания исходных пакетов и откликов в очередях сетевых устройств по пути следования. Самым узким местом в нашем случае является интерфейс С-7206-АТМ, так как сюда приходит два потока пакетов, суммарная полоса которых превышает зарезервированное значение.

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

Темп потери пакетов в любом случае равен разности между суммой входных потоков для интерфейса, сконфигурированного для обслуживания DSCP, и разрешенным выходным потоком интерфейса.

Плато на диаграмме RTT соответствует максимальному заполнению буфера. Возрастание вероятности потери пакетов в нашем случае происходит достаточно быстро. Для DSCP=30 потерь практически не наблюдается (потеря 1 пакета из 200 не в счет). DSCP=0 означает отсутствие метки приоритета – наинизший приоритет.

Для DSCP=10 этот скачок происходит позже, менее приоритетные пакеты с DSCP=20 начинают теряться при значении относительной временной шкалы 13. К этому времени в маршрутизатор приходит 2600 пакетов для каждого из потоков (всего 5200 пакетов). За это же время может быть передано в сеть АТМ 4642 пакета (расчет производится в предположении передачи IP-пакетов). Таким образом, чтобы избежать потерь до этого времени нужен буфер, рассчитанный на 558 пакетов. Для обоих значений DSCP скачок потерь происходит, когда RTT достигает значения 1800 мсек. Начальное значение RTT для DSCP=20 составляет 300 мсек, в то время как для DSCP=10 эта величина не превышает 10 мсек. Предельное значение RTT для DSCP=10 составляет 1850 мсек, а для DSCP=20 – 2100 мсек. Поток с DSCP=10 успевает передать на 600 пакетов больше, чем в случае DSCP=20, прежде чем начинаются большие потери пакетов.

На рис. 9 представлены результаты эксперимента по одновременной передаче потоков с DSCP=10 и 20. Длительность каждого из таких экспериментов составляла 50-60 сек. Однопотоковые данные здесь не приводятся, так как потери при этом были порядка 0,1%, а RTT < 10 мсек.

Рис. 10. Результаты эксперимента (измерение потерь и RTT) по одновременной транспортировке потоков пакетов с DSCP =10 и 20.

Рис. 11. Результаты эксперимента (измерение потерь и RTT) по одновременной транспортировке потоков пакетов с DSCP =10 и 30.

Рис. 12. Результаты эксперимента (измерение потерь и RTT) по одновременной транспортировке потоков пакетов с DSCP =0 и 20.

Рис. 13. Результаты эксперимента (измерение потерь и RTT) по одновременной транспортировке потоков пакетов с DSCP =20 и 30.

Рис. 14. Результаты эксперимента (измерение потерь и RTT) по одновременной транспортировке потоков пакетов с DSCP =20 и 30.

Рис. 15. Результаты эксперимента по одновременной транспортировке трех потоков пакетов с DSCP =0, 0, 0.

Рис. 16. Эволюция RTT и его дисперсии по мере роста длины очереди для DSCP=10 и 0 (голубым цветом отображена эволюция дисперсии RTT).

Рис. 17. Эволюция RTT и его дисперсии по мере роста длины очереди для DSCP=20 и 0.

Рис. 18. Эволюция RTT и его дисперсии по мере роста длины очереди для DSCP=10 и 30 (голубым цветом отображена эволюция дисперсии RTT).

Рис. 19. Эволюция RTT и его дисперсии по мере роста длины очереди для DSCP=20 и 30 (голубым цветом отображена эволюция дисперсии RTT).

Рис. 20. Зависимость загрузки входного и выходного интерфейсов маршрутизатора от времени во время эксперимента (в пакетах в сек). На нижних диаграммах показана зависимость входного/выходного потоков в октетах в сек.

Рис. 21. Зависимости RTT и вероятности потерь в условиях четырех идентичных потоков данных для DSCP= 0, 10, 20 и 30. n=5. Дата измерений 30 ноября 2004 17:39:44

Параллельно с RTT вычислялось значение его дисперсии. Ниже на рисунках 15, 16, 17 и 18 представлены результаты измерения эволюции RTT и дисперсии RTT в процессе роста длины очереди для значений DSCP=10 и 0, 20 и 0 и 10 и 30, соответственно. Измерения проводились 29 ноября 2004 года. Условия загрузки интерфейсов отображены на рис. 19. Эти данные подтверждают факт, что высокоприоритетный поток не только имеет меньшие потери и RTT, но и меньшее значение дисперсии по сравнению с низкоприоритетным потоком.

Из диаграмм видно, что дисперсия RTT более чувствительна к уровню приоритета (значению DSCP), даже при равенстве RTT дисперсии для разных DSCP сильно различаются. По мере роста очереди растет и значение дисперсии RTT.

Для задач мультимедиа наиважнейшими параметрами являются вероятность потери пакета и дисперсия RTT. Из полученных данных видно, что для приоритетных потоков эти параметры лежат в допустимых пределах.

Для задач управления в реальном масштабе времени важным параметром, кроме того, является значение RTT. По этому параметру даже приоритетные потоки в условиях высоких загрузок не отвечают требованиям, так как из-за высокой загрузки очередей RTT достигает значений 2-3 сек.

На рис. 20 и 21 показаны результаты эксперимента по пропусканию 4 потоков с разными значениями DSCP (30, 20, 10 и 0) одновременно. Рис. 21 отличается от 20 тем, что выбран другой экспоненциальный фактор усреднения длины очереди n (для рис. 20 n= 7, а для 21 - n = 5).

Перед началом последнего эксперимента была поменяна конфигурация маршрутизатора С-7206. Основные параметры конфигурации представлены в таблице ниже (активными являются очереди af11, af22, af33 и default):

Т_min и Т_max – нижний и верхний пороги отбрасывания пакетов (см. стр. 24). L – доля отбрасываемых пакетов.

Из диаграмм видно, что, несмотря на серьезную перегрузку (более чем в два раза против реальной возможности канала), поток с DSCP=10 передается достаточно успешно (потери пакетов практически отсутствуют). Смотри рис. 21 (n=5).

Для DSCP=10 в режиме перегрузки потери составляют менее 0,5%, для DSCP=20 - достигают 27%, для DSCP=30 – 45%, а для DSCP=0 – 95%.

Сравнение этих данных с результатами, представленными на рис 20 достаточно поучительно. Первое, что бросается в глаза – это средняя вероятность потерь для DSCP=20 составляет около 14% , на поток с DSCP=10 (высший приоритет) параметр n не оказывает практического влияния. Заметно увеличились потери для потока с DSCP=30, достигнув 60%. Таким образом, увеличилось отличие параметров обслуживание для DSCP 20 и 30. Провал на диаграмме RTT для DSCP=30 (рис. 20) связан с полной потерей пакетов.

Основные исполнители

Гончаров А.А., Горелов А.И., Гуденко С., Семенов Ю.А.

Проект "Модели реализации гарантированного качества сервиса для ресурсоемких приложений в Интернет"

Основные исполнители

Ссылки