Экспериментальное исследование метода обработки трафика в очереди linux-маршрутизатора на основе нечеткой логики

ЭКСПЕРИМЕНТАЛЬНОЕ ИССЛЕДОВАНИЕ МЕТОДА ОБРАБОТКИ ТРАФИКА В ОЧЕРЕДИ LINUX-МАРШРУТИЗАТОРА НА ОСНОВЕ НЕЧЕТКОЙ ЛОГИКИ

Масленников Андрей Геннадьевич,

соискатель, кафедра "Сети связи и системы коммутации", МТУСИ, Москва, Россия, amasl2048@gmail.com

Ключевые слова: активное управление очередями, предотвращение перегрузок, нечёткая логика, FLC, Linux-маршрутизатор, TCP/IP.

Рассматривается применение нечёткого регулятора для обработки трафика в очереди Linux-маршрутизатора. Регулятор на основе нечёткой логики FLC (Fuzzy Logic Controller) широко применяется в системах управления для контроля за сложными процессами с нелинейной динамикой и хорошо подходит для задач обработки трафика в очередях маршрутизаторов при перегрузках в сети. С помощью регулятора FLC возможно предупреждать возникновение перегрузок и автоматически выбирать оптимальное значение для вероятности сброса или маркировки пакетов в маршрутизаторе, чтобы регулировать интенсивность поступающей нагрузки при большом количестве TCP-сессий и ограниченной скорости в канале передачи данных. Способность регулятора FLC удерживать длину очереди около заданного значения позволит прогнозировать задержку пакетов в очереди и уменьшит джиттер.

Совместное применение метода FLC с технологией явного уведомления о перегрузки ECN способно сократить потери пакетов для TCP-соединений до минимума за счёт использования маркировки пакетов вместо их сброса. Использование открытой платформы на базе операционной системы Linux, даёт возможность реализовать собственный метод обработки трафика в маршрутизаторе, а также воспользоваться уже реализованными в Linux технологиями контроля и управления IP-трафиком. Нечёткий регулятор загружается в маршрутизатор в виде разработанного программного модуля для ядра Linux. Для оценки параметров качества обслуживания трафика, таких как задержка пакетов при передаче, джиттер, процент потерянных пакетов и коэффициент использования канала, при использовании метода FLC, проведены тестовые испытания маршрутизатора, как в виртуальном окружении, так и на аппаратной платформе. Одновременно через канал с ограниченной скоростью передавалось до 100 TCP-сессий плюс трафик UDP c постоянной скоростью. Несмотря на перегрузку разработанный метод FLC продемонстрировал способность удерживать длину очереди около заданного значения и не допускать переполнений и опустошений очереди в момент перегрузки. Результаты испытаний показывают преимущество разработанного метода FLC перед традиционными методами Tail Drop и RED в режиме перегрузки в сети.

Для цитирования:

Масленников А.Г. Экспериментальное исследование метода обработки трафика в очереди linux-маршрутизатора на основе нечеткой логики // T-Comm: Телекоммуникации и транспорт. - 2016. - Том 10. - №1. - С. 19-24.

For citation:

Maslennikov A.G. Experimental research of traffic control application in linux-router queue discipline based on fuzzy logic. T-Comm. 2016. Vol. 10. No.1, pр. 19-24. (in Russian).

r I >

I. Введение

Для экспериментальной проверки разработанного метода управления очередями на основе нечёткой логики [1-3] было выбрано ядро операционной системы Linux, так как оно свободно доступно в исходных кодах на языке программирования С на сайте проекта [4] и может быть скомпилировано для большого числа аппаратных архитектур. В ядре Linux уже присутствует поддержка множества сетевых технологий, таких как стек протоколов TCP/IP, технологии дифференцированного обслуживания DiffServ [5], включая различные методы управления трафиком и очередями, например метод управления очередями и предотвращения перегрузок RED, а также возможно добавление новых методов. В качестве транспортного протокола по умолчанию используется реализация TCP Cubic. Есть, также, поддержка метода уведомления о перегрузке ECN (RFC-3 168), но она по умолчанию отключена. Таким образом, большинство сетевых технологий уже присутствует и нам необходимо только внедрить свой метод управления в виде модуля ядра.

другой IP-адрес, то пакет пересылается на соответствующий выходной сетевой интерфейс (пересылка пакетов должна быть активирована в ядре). Исходящий трафик перед передачей в сеть может классифицироваться в блоке «Egress Classifier», и в зависимости от присвоенного класса отправляться в отдельную очередь со своей дисциплиной обслуживания.

Linux -маршрути татор

Рис. 2. Управление трафиком в Linux-маршрутизаторе

Для конфигурации разработанного модуля использовалась модифицированная утилита tc. В качестве основного метода контроля трафика применялся иерархический метод «Корзины с жетонами» {Hierarhial Tocken Bucket -НТВ). Входящий трафик разделялся на два класса: класс 1:10 для трафика управления и класс 1:5 для тестового трафика. Для класса тестового трафика установлено ограничение на максимальную скорость передачи данных 50 Мбит/с и далее этот трафик обрабатывается дисциплиной обслуживания FLC с максимальной длиной очереди 500 кбайт и заданной длиной 250 кбайт. Схема классификации трафика приведена на рис. 3.

Рис. I. Структура Linux-маршрутизатора

Непосредственно с аппаратным обеспечением маршрутизатора взаимодействует ядро Linux, и если полученный на сетевом интерфейсе IP-пакет адресован локальному IP-адресу, то ядро передаёт пакет в пользовательское окружение в обслуживающее приложение. Схема прохождения пакетов от сетевого интерфейса маршрутизатора через ядро Linux показана на рис. I.

Для управления трафиком в ядре используется приложение tc {Traffic Control) [6], работающее в пользовательском окружении, С помощью пользовательского приложения tc возможно создавать иерархические очереди, назначать дисциплины обслуживания, проводить классификацию трафика и применять политики обслуживания в зависимости от класса трафика. Для обработки пакетов, поступающих на вход сетевого интерфейса, в ядре организована входная дисциплина обслуживания, обозначенная «Ingress Qdics» на рис. 2, Далее в зависимости от того, если IP-пакет адресован локальному приложению, то пакет поступает в IP-стек для распаковки данных для пользовательского приложения. Если получателем пакета является

ollst: I: l b

о—

class I:

class 1:5

rate 50Mbit ceil 50Mbit

-0 qdisc flc

queue max 500Kbyte queue rcf 250 Kbytes

class 1:10

г

Рис. 3. Схема классификации исходящего трафика

Параметры утилиты tc для создания описанной выше конфигурации приведены в листинге I.

Листинг I. Создание дисциплин обслуживания с помощью утилиты tc

1. tc qdisc add dev ethO root netem deiay !0ms

2. tc qdisc replace dev ethO root handle I: htb default

10

3. tc class add dev ethO parent I: classid hi htb rate 100Mbit

4. tc class add dev ethO parent 1:1 classid 1:10 htb rate 50Mbit ceil 100Mbit prio I

5. tc class add dev ethO parent 1:1 classid 1:5 htb rate 50Mbit ceil 50Mbit prio 2

6. tc qdisc add dev ethO parent 1:5 handle 5: flc limit 500K qref 250000 descale 12500 sampling 6 p_rate0 50000 qjim 500000 ecn

7. tc filter add dev ethO parent 1:0 prio I protocol ip handle 5 fw flowid 1:5

В строке l задаётся задержка 10 мс. Строка 2 устанавливает основной метод управления НТВ с классом по умолчанию 10, а строка 3 - максимальную общую скорости 100 Мбит/с. Строка 4 устанавливает параметры для класса 1:10 с гарантированной скоростью 50 Мбит/с и максимальной скоростью 100 Мбит/с для трафика управления. Строка 5 устанавливает параметры для класса 1:5 с гарантированной скоростью 50 Мбит/с и максимальной скоростью тоже 50 Мбит/с для тестового трафика. Далее в строке 6 указывается, что трафик класса 1:5 нужно обрабатывать методом [1с с соответствующими параметрами. Значения функции управления для дисциплины обслуживания с нечётким регулятором FLC рассчитывались предварительно на основе заданных параметров, и передавались в модуль ядра в виде таблицы целых чисел, для избежания вычислений с плавающей точкой внутри ядра Linux. В последней строке 7 задаётся правило для фильтра, который будет назначать в класс 1:5 специально промаркированные пакеты тестового трафика. Предварительная маркировка пакетов мы выполнялась с помощью пользовательского приложения iptobles, являющегося стандартным приложением Linux.

С помощью цепочки фильтров iptables возможна обработка пакетов на каждом из этапов прохождения трафика в Linux. Схема цепочки фильтров iptables приведена на рис. 4.

(предварительна* маршрутизация к

(выколкая маршрутизация 1

iptables -A OUTPUT -t mangle -р tcp -dport 5001 -j MARK -set-mark 5

Таким образом, пользовательскому TCP-трафику, имеющему TCP-порт назначения 5001 в цепочке «OUTPUT», будет присвоена маркировка с индексом 5, и далее пакеты, маркированные этим индексом будут классифицированы в соответствующий класс обслуживания 1:5, который обрабатывается в очереди с дисциплиной обслуживания FLC.

2. Испытания метода FLC для обработки трафика на виртуальной машине

Для эксперимента по обработке трафика В очереди маршрутизатора была запущена операционная система OpenWRT Linux [7] в виртуальном окружении Oracle VM VirtualBox [8]. Дисциплина обслуживания выделенной очереди для тестового трафика fie была сконфигурирована для проведения измерения длины очереди и интенсивности трафика каждые 6 мс и изменения, с помощью нечёткого регулятора, вероятности сброса/маркировки пакетов на величину не более 8 10 s за один интервал измерения. Поддержка явного уведомления о перегрузки ECN была включена для TCP передатчиков. Схема эксперимента приведена на рис. 5.

ПК 1

50 Мбнт/с

Генератор трафика TCP

Приемник» TCP Рис. 5. Схема эксперимента

Рис. 4. Схема прохождения пакетом цепочки фильтров в Linux-маршрутизаторе

Входящие пакеты обрабатываются в блоке «Prerouting», далее в зависимости от решения о маршрутизации пакет поступает в пользовательское окружение через блок «Input» или проходит через блок «Forward» к исходящему порту. Если пакет отправляется из пользовательского окружения, то он проходит через блок «Output». Перед отправкой в сеть все пакеты могут обрабатываться в блоке фильтров «Postrouting».

Пример предварительной маркировки тестового трафика для его классификации с помощью утилиты iptables во время эксперимента, приведён в листинге 2.

Листинг 2. Маркировка трафика для классификации

В качестве генератора TCP и UDP трафика использовалась утилита iperf [9]. С помощью этой утилиты создавалось 100 потоков TCP с размером TCP сегмента 964 байта. В начальный момент времени все 100 TCP передатчиков устанавливали соединение и начинали отправку пакетов. Через 100 секунд после начала, 50 передатчиков прекращали передачу и пакеты передавали только оставшиеся 50 TCP передатчиков. После 100 секундного прерывания возобновлялась передача всех 100 передатчиков. Таким образом имитировалась скачкообразное изменение интенсивности трафика. Общее время эксперимента составило 300 секунд. Дополнительно К TCP трафику передавался также UDP трафик со скоростью 128 кбит/с и с размером дейтаграммы 980 байт. Изменение длины очереди маршрутизатора за время эксперимента приведено на рис. 6.

Рис, 6 показывает, что разработанный метод управления очередью FLC может удерживать длину очереди около заданного значения 250 Кбайт, несмотря на скачкообразное изменение интенсивности трафика и перегрузку.

500000

.зооооо

S 200000

îooooo

1.4

1.2

^ 1.0 g'

-

O.B

я 0.6

Q.

С 0.4

0.2

0.0

FLC

Tail Drop Метод

RED

150 200 250 Время, с

Рис. 6. Изменение длины очереди в Lin их-маршрутизаторе при использовании метода FLC

На рисунке также видно, что все 100 TCP соединения не устанавливаются одновременно, и что требуется около 25 секунд для того чтобы начать передачу. Через 300 секунд эксперимента передача данных не заканчивается резко, и требуется ещё около 100 секунд, чтобы завершить все соединения. За время эксперимента через 100 TCP соединений было передано 2 Гбайт данных (или 2 млн пакетов) доступная полоса пропускания канала была полностью утилизирована. Сброс пакетов TCP из очереди из-за переполнения был незначительный (около сотни пакетов), благодаря применению маркировки пакетов и уведомлению о перегрузке с помощью технологии ECN. Сброс пакетов UDP составил 3% и джиттер 3 мс. Больший процент потери пакетов UDP по сравнению с TCP, объясняется тем, что применяемый метод FLC использовал маркировку пакетов TCP вместо их сброса, а пакеты UDP, не имеющие механизма маркировки сбрасывались.

Подобный сценарий тестирования был применён также для метода RED и Tail Drop, для того чтобы выполнить сравнение параметров качества при использовании различных методов управления. Эксперимент с каждым методом был повторён 5 раз для каждого метода, для оценки доверительных интервалов измеренных характеристик. Для метода RED использовался минимальный порог длины очереди 125 Кбайт, максимальный порог 375 Кбайт и максимальная длина очереди 500 Кбайт. То есть, в соответствии с рекомендациями максимальный порог в 3 раза выше минимального, а средняя длина очереди соответствовала 250 Кбайт и равнялась заданной длине очереди для метода FLC. Вероятность сброса для метода RED была установлена 0,02, Поддержка ECN также включена. Для метода Tail Drop размер очереди равнялся 500 Кбайт, технология ECN методом Tail Drop не поддерживается. Средние значения потерь пакетов с доверительными интервалами для 5 экспериментов тремя методами: FLC, Tail Drop и RED приведены на рис. 7.

Рис, 7. Средние значения потерь пакетов

Благодаря применению ECN потери при использовании методов FLC и RED значительно ниже, чем для метода Tail Drop. Метод Tail Drop допускает значительные потери из-за переполнения очереди.

Средние величины значения джиттера с доверительными интервалами по уровню 95% для трафика UDP приведены на рис. 8.

12-

FLC

Tail Drop Метод

RED

Рис, 8, Средние значен/я джиттера для UDP-потока

Наименьшее значение джиттера с меньшим доверительным интервалом было зафиксировано для метода FLC. Таким образом метод FLC показал лучшую способность по стабилизации длины очереди среди испытанных методов. Метод RED показал большую величину джиттера потому, что контролирует только усреднённую длину очереди в пределах установленных порогов и допускает колебания мгновенного значения длины очереди. Метод Tail Drop показал нестабильное поведение длины очереди.

3. Испытания метода FLC для обработки

трафика в очереди маршрутизатора

Для внедрения метода обработки трафика в очередях на основе нечёткого регулятора, код разработанного программного модуля ядра был подготовлен для аппаратного маршрутизатора WL-500gP. Технические характеристики маршрутизатора приведены в табл. I.

Таблица I

Технические характеристики маршрутизатора

Характеристика Значение

Архитектура MIPS

С и сте м а-на- кр истал л е Broadcom ВСМ5354

Частота процессора 240 МГц

Оперативная память 32 Мбайт

Маршрутизатор был подключён между двум тестовыми компьютерами, выполняющими роль генератора и приёмника трафика, причём один из компьютеров был подключён по беспроводному каналу WLAN по стандарту IEEE 802.11g. Скорость в канале передачи данных была ограничена до 15 Мбит/с. Схема подключения маршрутизатора приведена на рис. 9.

LinuxMap ш рут» латор

ПК 1 Ethernet

100 Мбит/с 1

WLAN 802 11g

15 Мбит/с

ПК 2

Генератор траф»ка

Исходящая очередь

Рис, 9, Схена подключения маршрутизатора

Среднее значение двусторонней задержки RTT составило 2,5 мс. Через маршрутизатор передавался трафик со скачкообразно меняющейся интенсивностью. На всех устройствах была включена поддержка проколола ECN. Количество TCP-соединений резко изменялось с 50 потоков до 25 и обратно до 25 соединений через интервалы по 100 секунд. Одновременно с TCP трафиком передавался тестовый поток UDP с постоянной скоростью I28 кбит/с. Размер пакетов для обоих типов трафика - I000 байт. Максимальный размер выходной очереди маршрутизатора был установлен 500 кбайт, а заданное значение Qrrf для метода FLC равнялось 250 кбайт. Среднее значение длины очереди за время эксперимента составило 308 Кбайт при среднеквадратичном отклонении 55 кбайт. Общие потери пакетов - 0,027%. Значение джиттера для протокола UDP составило 20 мс.

Маршрутизатор показал устойчивую работу в режиме перегрузки при 100% использовании канала передачи

данных. Метод управления FLC совместно с использованием протокола ECN продемонстрировал способность удерживать длину очереди около заданного значения и не допускать переполнения буфера и потерь пакетов из-за переполнения.

Выводы

Разработанный метод FLC для обработки трафика в очередях и реализованный на базе Linux-маршрутизатора показал способность удерживать длину очереди около заданного значения при работе 8 режиме перегрузки в лабораторной сети.

При использовании метода FLC в маршрутизаторе улучшаются такие параметры качества обслуживания, как процент потерянных пакетов и величина джиттера по сравнению с традиционными методами Tail Drop и RED.

Литература

1. Деарт В.Ю., Масленников А.Г. Применение нечёткого регулятора для стабилизации длины очереди маршрутизатора II Тезисы докладов Всероссийской конференции с международным участием. — «Информационно-телекоммуникационные технологии и математическое моделирование высокотехнологичных систем» (ИТТММ-2012}. - М.: РУДН, 2012. - С. 83-8S.

2. Deort V., Maslennikov Fuzzy logic queue discipline processing over bottleneck link II Proc, of I Ith Conference of Open Innovations Association Finnish-Russian University of Cooperation in Telecommunications (FRUCT-I I). - St.-Petersburg State University of Aerospace Instrumentation (SUAI), 2012. -P. 40-46,

3. Деарт В.Ю., Масленников А.Г. Исследование влияния параметров канала передачи данных на процедуры управления очередью Н T-Comm - Телекоммуникации и Транспорт. - 2012. - No 7. - С. 77-81,

4. The Linux Kernel Archives. - URL: https://www.kernel.org (дата обращения: 22.1 1.2015).

5. Aimesberger W., Salim J.H., Kuz net so v A. II Differentiated Services on Linux - EPFL, 1999 - URL: http://infoscience.epfl.ch/record/l95 (дата обращения: 22.11.2015).

6. Hubert 8. Linux Advanced Routing & Traffic Control HOWTO. - URL: http://lartc.org/howto/ (дата обращения: 22.1 1.20 IS).

7. OpenWRT Linux. - URL: https://openwrt.org (дата обращения: 22.11.2015).

8. Oracle VM VirtualBox. - URL: https://www.virtualbox.org/ (дата обращения: 22.1 1.2015).

9. NLANR/DAST, Iperf. - URL: http://iperf.sourceforge.net/ (дата обращения: 22.1 I.20IS).

COMMUNICATIONS

EXPERIMENTAL RESEARCH OF TRAFFIC CONTROL APPLICATION IN LINUX-ROUTER QUEUE DISCIPLINE BASED ON FUZZY LOGIC

Maslennikov Andrey Gennad'evich,

external PhD student, faculty "Communication networks and switching systems", Moscow Technical University of Communications and Informatics, Moscow, Russia,

amasl2048@gmail.com

Abstract

In the article is investigated fuzzy logic controller (FLC) application for queue discipline in Linux-router. Fuzzy logic controller is widely used for control complicated processes with non-linear dynamics and well fit to traffic processing tasks in routers' queue in network overload mode. Due to FLC it is possible to prevent overload beginning and automatically select proper value of drop or marking probability for packets in a router, in order to control incoming traffic intensity with a big quantity of TCP-sessions and limited data transmission channel rate. The possibility of FLC to hold queue length on reference level will allow to planning of packets delay in a queue and decrease jitter. Joint usage of FLC method with explicit congestion notification (ECN) technique allows to decrease packets loss to minimal values due to marking of packets instead of packets drop. Open system application based on Linux operating system gives possibility to implement own queue discipline in a router and take advantage of existing in Linux IP traffic control technologies. FLC is loading to a router as a developed software module for Linux kernel. Up to 100 simultaneously TCP-sessions plus UDP traffic with constant bit rate are transmitted over bottleneck link. The developed FLC method showed ability to hold queue length near reference level and prevent queue overloading or underloading despite of link overload.

Keywords: active queue management, congestion avoidance, fuzzy logic, FLC, Linux-router, TCP/IP.

References

1. Almesberger, W., Salim, J.H., Kuznetsov, A. 1999, 'Differentiated Services on Linux', EPFL,viewed 22 November 2015, http://infos-cience.epfl.ch/record/195.

2. Deart, V.U., Maslennikov, A.G. 2012, 'An application of fuzzy logic controller for queue length stabilization in router', Theses of Russian conference with international participation, "Info-communication techniques and mathematical modeling of high-technological systems" (IITTMM-2012), RUDN, pp. 83-85.

3. Deart, V.U., Maslennikov, A.G. 2012, 'Investigation of data transmission channel parameters influence to queue management processing', T-Comm, no. 7, pp. 77-81.

4. Deart, V., Maslennikov, A. 2012, 'Fuzzy logic queue discipline processing over bottleneck link', Proc. of 11th Conference of Open Innovations Association Finnish-Russian University of Cooperation in Telecommunications (FRUCT-11), St.-Petersburg, State University of Aerospace Instrumentation (SUAI), pp. 40-46.

5. Iperf, NLANR/DAST, viewed 22 November 2015, http://iperf.sourceforge.net.

6. Hubert, B., 'Linux Advanced Routing & Traffic Control HOWTO', viewed 22 November 2015, http://lartc.org/howto.

7. The Linux Kernel Archives, viewed 22 November 2015, https://www.kernel.org.

8. OpenWRT Linux, viewed 22 November 2015, https://openwrt.org.

9. Oracle VM VirtualBox, viewed 22 November 2015, https://www.virtualbox.org.