Исследование возможностей DiffServ в рамках протокола MPLS

Гончаров А.А., Горелов А.И., Семенов Ю.А. (ИТЭФ), Гончар А.А. (ЦНТК), Ильин А.Ю. (ИАЭ),

Для исследования возможностей гарантированного уровня QoS (Diff-Serv) была построена тестовая сеть и написан пакет инструментальных программ, которые позволяли формировать несколько потоков данных с нужными характеристиками и одновременно измерять реальную полосу пропускания, RTT и вероятность потери пакетов.

Виртуальный канал через сеть АТМ имел полосу 2 Мбит/с, что облегчало создание закритических режимов с точки зрения перегрузки. Измерения проводились в основном для VPN ПРАН-ИАЭ.

Для тестовой сети и для канала ПРАН ИММ Екатеринбург были проведены измерения вероятности потери пакетов от длины пакета. Результаты измерений показаны на рис. 2 и 2а.

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

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

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

Отсюда можно сделать вывод, что исследование зависимости вероятности потери от длины пакета можно считать полезным диагностическим средством при исследовании свойств каналов и выявления потерь, сопряженных с искажениями передаваемых кадров.

Эта методика позволяет выявить участки сети или канала, содержащие источники наводок и искажений.

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

bandwidth percent 10 -- использовать 10% от 2 Мбит/c

random-detect dscp-based random-detect exponential-weighting-constant 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.

На рис. 3 показаны результаты эксперимента по пропусканию через тестовую сеть потоков с 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 октетов с учетом размера заголовка).

Рис. 3.1. Потоки пакетов и октетов через интерфейсы маршрутизатора при измерении зависимостей от степени перегрузки RTT и вероятности потери пакетов (ПРАН)
day

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

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

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

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

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

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

Для DSCP=10 (смотри рис. 4) этот скачок происходит позже, менее приоритетные пакеты с DSCP=30 начинают теряться при значении относительной временной шкалы 12. Скачок потерь происходит, когда RTT достигает значения 1800 мсек. Начальное значение RTT для DSCP=30 составляет 300 мсек, в то время как для DSCP=10 эта величина не превышает 10 мсек.

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

На рис. 5 показан результат эксперимента по пропусканию через VPN трех потоков с DSCP=0. Перегрузка наступала быстро, RTT для всех потоков становилось равным 3700 мсек. Спад вероятности потери в правых частях диаграмм связан с прекращением одного из трех потоков.

На основании этих измерений можно сделать вывод, что даже при частичной поддержке Diff-Serv в VPN можно получить приемлемый уровень QoS для высокоприоритетного потока, обеспечив пренебрежимо малую вероятность потери пакетов.

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

На основании этих результатов можно сделать вывод, что современные средства Diff-Serv достаточно эффективны и вполне способны предоставить требуемый уровень QoS для приоритетных потоков. Это справедливо даже для достаточно перегруженных интерфейсов.

Следует заметить, что для конечных пользователей, работающих в локальной сети за переключателями (L2), возникают проблемы из-за того, что это оборудование не поддерживает Diff-Serv. Отсюда напрашивается вывод, что такая поддержка становится актуальной и разработчики такого оборудования должны учесть эту необходимость. Данная проблема более подробно рассмотрена в статье "Новый протокол ТСР", доложенной на конференции МФТИ 25 ноября 2004 года и доступной по адресу: http://book.itep.ru/4/44/new_tcp.htm.





Исследование возможностей Diff-Serv в рамках протокола MPLS Гончаров А.А., Горелов А.И., Семенов Ю.А. (ИТЭФ), Гончар А.А. (ЦНТК), Ильин А.Ю. (ИАЭ), Для исследования возможностей гарантированного уровня QoS (Diff-Serv) была построена тестовая сеть и написан пакет инструментальных программ, которые позволяли формировать несколько потоков данных с нужными характеристиками и одновременно измерять реальную полосу пропускания, RTT и вероятность потери пакетов. Рис. 1. Схема тестовой сети Виртуальный канал через сеть АТМ имел полосу 2 Мбит/с, что облегчало создание закритических режимов с точки зрения перегрузки. Измерения проводились в основном для VPN ПРАН-ИАЭ. Для тестовой сети и для канала ПРАН ИММ Екатеринбург были проведены измерения вероятности потери пакетов от длины пакета. Результаты измерений показаны на рис. 2 и 2а. Рис. 2. Зависимость вероятности потери пакета от длины пакета для маршрута ПРАН – ИММ (Екатеринбург) Рис. 2а. Зависимость вероятности потери пакета от длины пакета для маршрута ПРАН – ИАЭ Сравнение результатов для каналов ПРАН-Екатеринбург и ПРАН-ИАЭ показывает, что в первом случае заметное влияние на потери, вероятно, оказывает повреждение пакетов в пути. Во втором случае вероятность потери более чем в 20 раз меньше и практически не наблюдается зависимости вероятности потери от длины пакета. Отсюда можно сделать вывод, что исследование зависимости вероятности потери от длины пакета можно считать полезным диагностическим средством при исследовании свойств каналов и выявления потерь, сопряженных с искажениями передаваемых кадров. Эта методика позволяет выявить участки сети или канала, содержащие источники наводок и искажений. Параллельно измерялись потоки пакетов для входного и выходного интерфейсов CISCO-7206 в ПРАН (для обоих направлений) (смотри рис. 3). При этом задавались следующие параметры обработки очередей для входного интерфейса сети АТМ (WRED, маршрутизатор CISCO-7206, интерфейс АТМ; маршрутизатор со стороны ИАЭ имел другую конфигурацию): bandwidth percent 10 -- использовать 10% от 2 Мбит/c random-detect dscp-based random-detect exponential-weighting-constant 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. На рис. 3 показаны результаты эксперимента по пропусканию через тестовую сеть потоков с 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 октетов с учетом размера заголовка). Рис. 3.1. Потоки пакетов и октетов через интерфейсы маршрутизатора при измерении зависимостей от степени перегрузки RTT и вероятности потери пакетов (ПРАН) Рис. 3.2. Результаты эксперимента (измерение потерь и RTT) по одновременной транспортировке потоков пакетов с DSCP =0 и 30. Результаты измерения зависимости RTT и вероятности потери пакета от времени в ходе одновременной транспортировки потоков пакетов из ЭВМ в ПРАН в ЭВМ в ИАЭ показаны на рисунке 3.2. В каждом прогоне передавалось 5000 пакетов. Каждая точка на диаграмме получена путем усреднения данных, полученных для 200 пакетов. Пакеты ICMP имели длину 1400 байт и следовали с периодом 10 мс, что создавало трафик более 1,1 Мбит/c. С учетом конфигурационных параметров и наличия двух потоков, это заведомо перегружало интерфейс (разрешенный предел равнялся 2 Мбит/c). Будем исходить из предположения, что в исходный момент времени очередь пакетов в буфере маршрутизатора пуста. RTT в нашем случае определяется временем пребывания исходных пакетов и откликов в очередях сетевых устройств по пути следования. Самым узким местом в нашем случае является интерфейс С7206-АТМ, так как сюда приходит два потока пакетов, суммарная полоса которых превышает зарезервированное значение. По мере роста длины очереди неизбежен рост времени RTT. При достижении нижнего порога начинаются потери пакетов. Когда же будет превышен верхний порог, начинают отбрасываться все приходящие пакеты с низким приоритетом. Если бы отбрасывание пакетов не начиналось до переполнения буфера, можно было бы ожидать линейного роста RTT. При достижении предельного значения практически скачкообразно возрастала бы вероятность потери пакетов. Темп потери пакетов в любом случае равен разности между суммой входных потоков для интерфейса, сконфигурированного для обслуживания DSCP, и разрешенным выходным потоком интерфейса. Плато на диаграмме RTT соответствует максимальному заполнению буфера. Возрастание вероятности потери пакетов в нашем случае происходит достаточно быстро. Для DSCP=10 (смотри рис. 4) этот скачок происходит позже, менее приоритетные пакеты с DSCP=30 начинают теряться при значении относительной временной шкалы 12. Скачок потерь происходит, когда RTT достигает значения 1800 мсек. Начальное значение RTT для DSCP=30 составляет 300 мсек, в то время как для DSCP=10 эта величина не превышает 10 мсек. Рис. 4. Результаты эксперимента по одновременной транспортировке потоков пакетов с DSCP = 10 и 30. На рис. 5 показан результат эксперимента по пропусканию через VPN трех потоков с DSCP=0. Перегрузка наступала быстро, RTT для всех потоков становилось равным 3700 мсек. Спад вероятности потери в правых частях диаграмм связан с прекращением одного из трех потоков. На основании этих измерений можно сделать вывод, что даже при частичной поддержке Diff-Serv в VPN можно получить приемлемый уровень QoS для высокоприоритетного потока, обеспечив пренебрежимо малую вероятность потери пакетов. Рис. 5. Результаты эксперимента по одновременной транспортировке трех потоков пакетов с DSCP=0, 0, 0 На основании этих результатов можно сделать вывод, что современные средства Diff-Serv достаточно эффективны и вполне способны предоставить требуемый уровень QoS для приоритетных потоков. Это справедливо даже для достаточно перегруженных интерфейсов. Следует заметить, что для конечных пользователей, работающих в локальной сети за переключателями (L2), возникают проблемы из-за того, что это оборудование не поддерживает Diff-Serv. Отсюда напрашивается вывод, что такая поддержка становится актуальной и разработчики такого оборудования должны учесть эту необходимость. Данная проблема более подробно рассмотрена в статье "Новый протокол ТСР", доложенной на конференции МФТИ 25 ноября 2004 года и доступной по адресу: http://book.itep.ru/4/44/new_tcp.htm.

Исследование возможностей Diff-Serv в рамках протокола MPLS