Qos что это такое в роутере

Зачем нам нужен QoS?

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

Как настроить QoS?

К примеру, у меня есть несколько устройств, которые подключены к моей Wi-Fi сети.

Я бы хотел:

• Использовать FTP-сервер на максимальной скорости
• Использовать телефон для выхода в интернет на средней скорости

Шаг 1.

Откройте веб-браузер и наберите в адресной строке http://tplinkwifi.net или http://192.168.0.1 и зайдите в веб-интерфейс роутера, используя логин и пароль, установленные ранее. По умолчанию установлен логин и пароль “admin”.

Шаг 2.

Откройте Расширенные настройки (Advanced)> Приоритезация данных (QoS)

Отметьте Включить приоритезацию данных (Enable QoS)

Заметка: QoS и NAT Boost не могут работать одновременно, для начала вам следует отключить NAT Boost. Пожалуйста, выполните шаг а и б для отключения NAT Boost.

а. Нажмите NAT Boost.

б. Снимите галочку с пункта Enable NAT Boost и нажмите Сохранить (Save), затем нажмите OK в всплывающем окне.

Шаг 3

Установите максимальную скорость отдачи и загрузки, предоставляемую вашим интернет-провайдером. 1 Мбит соответствует 1024 Кбит.

Нажмите Дополнительные настройки (Advanced)  и перетащите отметку для выбора уровня приоритета полосы пропускания. Затем, нажмите Сохранить (Save).

Замечание: Для каждого приоритета нельзя установить значение более 100%. Высокий приоритет (High priority) больше, чем средний приоритет (Middle priority), и средний приоритет больше, чем низкий приоритет (Low priority).

Шаг 4

Добавьте правила QoS (правила приоритезации трафика).

1) Установите правило с высоким приоритетом для FTP-сервера.

а. Нажмите Добавить (Add) в секции Высокий приоритет (High Priority).

б. Выберите По приложению (By Application) и затем выберите ftp из списка и нажмите OK.

Совет: если вашего приложения не окажется в списке, нажмите Приложение по выбору (Custom Application) и добавьте приложение вручную.

• Имя (Name): Введите имя вашего приложения.

• Протокол (Protocol): Выберите протокол вашего приложения, если не уверены, выберите ВСЕ (ALL).

• Порт (Port): Введите порт назначения для приложения, обычно у каждого приложения есть свой фиксированный порт, пожалуйста, проверьте правильность ввода порта. В нашем примере, порт назначения для ftp 21.

2) Установите правило среднего приоритета для телефона.

a. Нажмите Добавить (Add) в секции Средний приоритет (Middle Priority).

b. Выберите По устройству (By Device) и затем нажмите Просмотр существующих устройств (View Existing Devices).

c. Выберите соответствующее устройство из списка.

d. Нажмите OK.

Затем, список правил QoS появится в таблице.

Совет: Если вы хотите удалить правило QoS, нажмите иконку  для удаления правила из списка.

Шаг 5.

Готово! Теперь QoS настроен для приоритезации интернет-трафика. 

Узнайте больше о каждой функции и конфигурации, перейдите в Загрузки, чтобы загрузить руководство по вашему устройству.

Вы здесь, потому что у вас возникла проблема с передачей голоса по IP (VoIP) или вызовами для видеоконференции? Или, может быть, у вас общие проблемы со скоростью вашего интернета? Вы не одиноки!

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

Всё дело в QoS.

QoS – что это такое

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

Как это работает? QoS берёт существующее широкополосное соединение и резервирует определенный объём запрашиваемой полосы пропускания для цели в режиме реального времени относительно остальной части сети.

Например, если вы установите приоритет VoIP, ваши интернет-вызовы получат всю необходимую полосу пропускания раньше, чем любые другие приложения. Или, если вы отдаёте приоритет своему Xbox (или конкретной игре), тогда игровая консоль получит главные фишки в вашем интернет-соединении перед любыми другими устройствами.

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

Скачивание файлов никогда не требует расстановки приоритетов. Напротив, это главная причина, по которой вам нужен QoS. Если оставить всё как есть, загрузка файла потребует всей полосы пропускания, независимо от скорости подключения к Интернету, пока она не будет завершена.

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

При правильной настройке – это непростая задача – QoS может порадовать всех, даже если у вас скромное подключение к Интернету.

QoS против скорости Интернета

Важно отметить, что QoS – это не повышение скорости вашего Интернета! Речь идёт о том, чтобы дать вам именно то, что вам (вашему устройству) нужно, но не больше.

Следовательно, когда вы включаете QoS, вы, как правило, получаете более медленные результаты тестирования скорости – и в этом суть, потому что тестирование скорости – это не то, как мы обычно используем Интернет.

Кроме того, если вы неправильно сконфигурируете QoS и установите его скорость загрузки значительно ниже, чем фактическая скорость вашего доступа, тогда установленная скорость QoS будет потолком.

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

Что вам нужно для использования QoS

Чтобы воспользоваться преимуществами QoS, как правило, необходимы две вещи.

• Маршрутизатор, поддерживающий эту функцию. Большинство, если не все, домашние маршрутизаторы Wi-Fi имеют QoS, но способ их реализации варьируется от одного поставщика к другому. Когда дело касается этой особенности, существует множество степеней и нюансов. По моему опыту, маршрутизаторы Asus хорошо поддерживают эту функцию и допускают простую настройку. Неплохие реализации у Linksys, Netgear и TP-Link.
• Во-вторых, вам необходимо знать фактическую скорость и качество вашего интернет-соединения. Это довольно легко узнать – я написал длинную статью о тестировании скорости, если вам нужно знать точные числа и их значение. Но, в целом, вы можете сделать быстрый тест скорости прямо сейчас, чтобы узнать свои приблизительные цифры.

Сделали? Надеюсь, у вас хорошие цифры.

Лучше знать свою точную скорость вашего доступа при настройке QoS. Но, вы можете указать немного более низкую скорость для вашего QoS. Так, если у вас скорость загрузки 500 Мбит/с, вы можете указать 450 Мбит/с.

Никогда не стоит использовать большее число (например, 550 Мбит/с). В этом случае QoS может вообще не дать значимого результата. Это может даже ухудшить ситуацию.

Правило таково: настройте QoS на использование максимально близкой к точной ширине полосы пропускания, но никогда не превышайте её.

Давайте установим правильные ожидания относительно того, что вы можете получить от своего Интернета с поддержкой QoS.

Правильные ожидания от использования QoS

Чтобы QoS было эффективным, ваш Интернет должен быть, по крайней мере, достаточно быстрым, а ещё лучше – более быстрым, чем требуется приоритетной стороне. Так, скажем, если вашему приложению требуется скорость загрузки 25 Мбит/с, а ограничение на соединение – 20 Мбит/с, в этом случае никакое QoS не поможет.

Я не зря выбрал 25 Мбит/с. Это скорость загрузки, необходимая для потоковой передачи контента 4K на одно устройство. Поэтому, если вы страдаете от буферизации и времени ожидания при потоковой передаче через скромное интернет-соединение, не обвиняйте сразу в этом свой Wi-Fi – это разные вещи.

Кроме того, QoS не может улучшить качество вашего интернет-соединения. Например, если ваша связь имеет высокую задержку (пинг), что ужасно для связи в реальном времени, QoS не улучшит это. Всё, что он может сделать, – это предоставить конкретному приложению, услуге или клиенту в вашей сети наилучшие возможности из того, что у вас есть.

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

Требования к связи для VoIP и видеоконференцсвязи

Как правило, соединение со скоростью загрузки 50 Мбит/с / передачи 15 Мбит/с или быстрее достаточно практически для любого онлайн-приложения. Одного экземпляра приложения.

Если у вас несколько приложений, имейте в виду, что каждое из них требует одинаковой полосы пропускания. Например, большинству приложений для видеоконференций требуется не менее 2 Мбит/с на экран.

На самом деле, вероятно, оно будет использовать больше, если вы делаете это в Full HD или 4K. Поэтому для уверенности выделите каждому экрану 25 Мбит/с.

Каналы загрузки/передачи различаются. Но если вы хотите, чтобы люди на другом конце провода видели вас в HD, вам также понадобится 25 Мбит/с для передачи. К сожалению, большинство кабельных сетей не могут обеспечить этого, поскольку они ограничиваются скоростью около 15 Мбит/с. Скорее всего, вы сможете транслировать себя только в низком разрешении.

Требования к задержке при голосовой/видеосвязи через Интернет относительно невысоки. В частности, для правильной работы VoIP ваше соединение должно иметь менее 150 мс (миллисекунд) и 30 мс в значениях Ping и Jitter, соответственно. (В идеале эти числа должны составлять 15 мс и 10 мс, соответственно.)

Важно отметить, что вы должны оставаться относительно в одном месте (или в одной комнате) во время голосового или видеозвонка – ещё лучше, запустите соединение Wi-Fi в этом же месте. Если у вас есть привычка перемещаться по своему (большому) дому, ни один маршрутизатор или система не смогут заставить это работать. Так что QoS тоже не поможет.

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

Как настроить QoS вашего роутера

Способ работы с QoS зависит от маршрутизатора. Как правило, маршрутизаторы от одного производителя используют один и тот же интерфейс или мобильное приложение, поэтому пользователи могут настраивать свои параметры одинаковым образом.

Веб-интерфейс всегда является лучшим способом управления маршрутизатором, поскольку он даёт детализированный доступ ко всем функциям и настройкам. И QoS – одна из таких дополнительных функций. Но некоторые поставщики, например, Linksys, позволяют настраивать эту функцию через мобильное приложение.

Я всегда предпочитаю веб-интерфейс, и вот общие шаги по настройке QoS:

1. Войдите в интерфейс вашего роутера

   Для этого перейдите в своём браузере (Chrome, Firefox или Edge) на IP-адрес маршрутизатора по умолчанию (или удобный URL).

   Если вы не знаете свой, проверьте стандартные IP-адреса в таблице ниже. И войдите в систему с учетной записью администратора вашего роутера.

   Производитель	URL	IP	Username	Пароль
   Asus	router.asus.com	192.168.1.1 192.168.50.1	admin	admin
   D-Link	dlinkrouter.local	192.168.0.1 192.168.1.1	n/a	admin
   Netgear	routerlogin.com	192.168.1.1	admin	password
   Linksys	myrouter.local	192.168.0.1 192.168.1.1	n/a	admin
   TP-Link	tplinkwifi.net	192.168.0.1	admin	admin
   Большинство кабельных модемов	N/A	192.168.100.1	n/a	admin password default

2. Настройте функцию QoS маршрутизатора (для VoIP)

   Эта функция почти всегда находится в расширенной области интерфейса. Обычно в названии есть «QoS» или «Приоритизация».

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

   

   Опять же, определенно не вводите цифры, превышающие вашу фактическую скорость загрузки и выгрузки. Некоторые маршрутизаторы могут вычислить эти числа самостоятельно.

   Теперь убедитесь, что вы расставили приоритеты для QoS в соответствии с вашими потребностями. Выберите VoIP и видеозвонки как свои главные приоритеты.

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

   Обратите внимание: если вы решите установить приоритет определенного устройства, рекомендуется зарезервировать IP-адрес этого устройства в маршрутизаторе, чтобы он не изменился.

3. Дополнительно: отключить SIP ALG (или SIP Passthrough)

   Этот параметр применяется, когда вам нужно, чтобы ваш маршрутизатор хорошо работал для передачи голоса по IP, и даже в этом случае только в определенных ситуациях. Так что это то, что нужно попробовать, когда у вас есть проблемы с вызовами Wi-Fi, например, задержки.

   SIP ALG расшифровывается как Application Layer Gateway, параметр доступен в большинстве домашних маршрутизаторов и включен по умолчанию. Первоначально этот параметр предназначен для улучшения прохождения пакетов VoIP через межсетевой экран маршрутизатора. На самом деле, это редко срабатывает так, как ожидалось, и часто вызывает проблемы.

   Вам может потребоваться выключить (или отключить) SIP ALG (также известный как SIP Passthrough или SIP), чтобы улучшить работу с VoIP. Расположение настройки SIP может быть разным, но обычно вы можете найти его в области WAN (Интернет) или межсетевого экрана интерфейса маршрутизатора.

4. Примените изменения

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

   Теперь сила QoS на вашей стороне.

Оптимизация QoS для голосовой и видеосвязи (на примере Asus)

Если у вас есть маршрутизатор Asus, выполните следующие действия по настройке QoS для голосовой и видеоконференцсвязи. Хотя они не такие, как в маршрутизаторах другого производителя, они дадут вам несколько идей.

1. Войдите в веб-интерфейс вашего роутера

   На подключенном компьютере укажите в браузере router.asus.com, и вы откроете интерфейс. Введите свое имя пользователя и пароль и нажмите Войти.

2. Обновите роутер до последней прошивки

   • Нажмите на пункт меню «Администрирование».
   • Перейдите на вкладку Обновление микропрограммы.
   • Нажмите кнопку Проверить для получения новой версии прошивки. Кроме того, вы также можете загрузить прошивку прямо с сайта производителя. В этом случае используйте кнопку Загрузить, чтобы вручную загрузить прошивку в маршрутизатор.
   • Выполните оставшуюся часть процесса, чтобы обновить прошивку маршрутизатора до последней версии.

   Примечание. Не выключайте маршрутизатор во время процесса обновления, который займёт не более 5 минут. После этого рекомендуется вручную перезапустить маршрутизатор.

3. Включите функции Adaptive QoS

   • Щелкните пункт меню Adaptive QoS, а затем вкладку QoS.
   • Активируйте параметр Включить QoS.
   • Нажмите кнопку «Видеоконференцсвязь».

     

     Примечание. В некоторых моделях маршрутизаторов связь в режиме реального времени входит в категорию «Работа из дома».
   • Необязательно: нажмите «Настроить» и перетащите блоки других категорий в соответствии с вашими потребностями – вы можете навести указатель мыши на каждый блок, чтобы увидеть, какой тип приложений / услуг включает в себя эта категория. Затем нажмите Сохранить.
   • Щёлкните Применить.

   Маршрутизатору потребуется несколько секунд, чтобы применить изменения.

4. Отключите сквозную передачу SIP (при необходимости)

   • Щелкните меню Интернет (в разделе «Дополнительные настройки»), а затем перейдите на вкладку NAT Passthrough.
   • Измените значение SIP Passthrough на Отключить

     

   • Нажмите Применить и дождитесь, пока маршрутизатор применит изменения.
   • Перезапустите маршрутизатор вручную и убедитесь, что всё в порядке.

   И это всё! Теперь ваш роутер Asus должен работать лучше для вашего приложения для онлайн-коммуникаций.

---

Интернет-трафик чем-то похож на денежный поток для домашнего хозяйства (или бизнеса) – всё дело в том, чтобы управлять своими доходами и расходами и оставаться в рамках бюджета. И здесь в игру вступает QoS.

Опять же, эта функция предназначена для предоставления устройству необходимой полосы пропускания (и не более), когда она ему нужна. Это не делает ваш Интернет быстрее!

Вместе с тем, при правильной настройке QoS вы удивитесь, насколько мало пропускной способности Интернета вам действительно нужно. И, наоборот, в плохо настроенной сети даже гигабитный широкополосный доступ не всегда достаточно быстр для каждого устройства в сети.

Приоритизация трафика — идея не новая. Уровень важности пакетов в сети Ethernet уже могли задавать в 1981 году. Но однозначного мнения об эффективности приложений, оптимизирующих трафик, нет до сих пор. Одни уверены, что могут поднять скорость соединения на 10–20%. Другие утверждают, что толку от таких программ ноль, и они только впустую нагружают процессор. Пробуем разобраться, где правда.

Что такое приоритизация трафика

Если активное соединение одно, то и приоритизировать нечего — весь канал целиком отдается под это соединение и скорость его зависит только от пропускной способности канала. Но если соединений несколько, то они начинают мешать друг другу. Идея приоритизации состоит в том, чтобы пакеты, помеченные как «важные», пропускать в первую очередь, а менее важные — придерживать, пока линия не освободится. Например, если у вас идет скачивание файла, и одновременно вы играете в онлайн-игру, разумно будет выдать высший приоритет игровому соединению. Может, скачивание файлов при этом пойдет медленнее, зато у вас не будет лагов во время игры.

В стандарте Ethernet прописана поддержка механизма приоритизации, называемого QoS («Quality of Service» — «Качество обслуживания»). 

QoS и его поддержка на «последней миле»

QoS — сложный механизм, содержащий целую пачку технологий. Поддержка QoS подразумевает:

• правильную маркировку пакетов данных;
• формирование очередей отправки данных через один интерфейс;
• сброс «лишнего» трафика.

Настройка QoS на сетевых устройствах — отдельная непростая тема. Обычному пользователю это, чаще всего, не нужно. 

Однако следует понимать, что поддержка QoS должна быть на каждом узле между отправителем и получателем данных в сети. С узлами вне вашего дома вы ничего не можете поделать, но поддержка QoS вашими устройствами от вас зависит. Если, к примеру, ваш роутер во всей цепочке узлов единственный не поддерживает QoS, весь эффект этой технологии пойдет насмарку. 

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

А еще желательно потратить некоторое время, разобраться в вопросе и правильно настроить параметры QoS в операционной системе компьютеров, подключенных к сети.

Если же на роутере нет поддержки QoS (или нет желания возиться с настройками), можно воспользоваться программами приоритизации трафика. Например, Netlimiter, Killer Intelligence center или cFosSpeed.

Работа программы приоритизации трафика cFosSpeed

Что делает cFosSpeed
Программа перехватывает сетевой трафик всех приложений и выставляет им приоритет в соответствии с заданными правилами. В cFosSpeed можно назначать приоритет, основываясь на виде приложения или используемом протоколе. Когда новое приложение выходит в сеть, cFosSpeed ищет это приложение и используемый им протокол в своих списках. Если правило для приложения (или протокола) найдено, его сетевым пакетам назначается соответствующий приоритет. В список приложений можно добавить свое — надо лишь нажать на кнопку «Добавить программу» и cFosSpeed предложит выбрать среди запущенных программ ту, сетевому трафику которой следует назначить особый приоритет.

Что же cFosSpeed делает для программ с высоким приоритетом? Пусть, например, у трафика MMORPG теперь наилучший приоритет — как это ускорит передачу данных с сервера, находящегося черт-те где? Правильно — никак. 

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

cFosSpeed использует несколько способов приоритизации:

• Он маркирует пакеты в соответствии со своими правилами. Приложения могут самостоятельно ставить приоритет своим пакетам, и это никак не регулируется. Какая-нибудь малополезная утилита запросто может каждые пять минут «лезть» на свой сервер за обновлениями, выставляя своим пакетам наивысший приоритет и тормозя остальной трафик. cFosSpeed эту самодеятельность отменяет.
• Он устанавливает очередность отправки пакетов различных приложений.
• Он «притормаживает» входящий TCP-трафик приложений с низким приоритетом. За счет этого канал освобождается для входящего трафика более приоритетных приложений.    
  

  Каждый ТСР пакет с данными должен получить пакет-подтверждение (АСК-пакет) от получателя, только после этого будет отправлен следующий пакет.

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

• Он взаимодействует с другими копиями cFosSpeed на остальных компьютерах локальной сети. Это позволяет распространить правила на всю подсеть. Если, к примеру, на одном компьютере запущена программа с высоким приоритетом, то исходящий трафик с остальных компьютеров будет приторможен, чтобы с первого компьютера данные уходили без задержек. Это частично заменяет поддержку QoS на роутере.

Кроме того, cFosSpeed настраивает параметры сети для достижения наилучшего результата. В зависимости от требований приоритетного приложения это может быть либо «Максимальный пинг», либо «Максимальное использование канала».

Приоритизацию «Максимальный пинг» следует использовать там, где нужен максимально быстрый отклик сервера. Чаще всего такая необходимость возникает в онлайн-играх. При выборе этой цели cFosSpeed минимизирует окно приема ТСР-пакетов. Пакеты становятся маленькими, передаются быстро. Но возрастает количество служебной информации (заголовки пакетов, АСК-пакеты), поэтому пропускная способность канала падает.

«Максимальное использование канала», наоборот, увеличивает окно приема. Пакеты возрастают в объеме, количество служебной информации снижается, скорость вырастает. Но при потерях пакетов могут возникать продолжительные задержки. Эту политику следует использовать на линиях с малым количеством помех при необходимости получения максимальной скорости — например, при видеоконференциях или просмотре роликов в высоком качестве.

Чтобы cFosSpeed смог оценить качество и скорость вашего канала, при первом запуске следует произвести его калибровку: пункт меню «Приоритизация трафика — Калибровка линии».

Тестирование cFosSpeed

Эффект программ приоритизации трафика проявляется только при наличии нескольких соединений, полностью загружающих канал. Загружать компьютер будем одновременным просмотром 4х видео в высоком разрешении с Youtube, загрузкой большого файла в uTorrent и игрой World of Tanks. Одновременно запущен пинг игрового сервера WorldOfTanks.

Канал нагружен почти полностью, в основном, торрентом. 11 Мб/с.

Видео играет рывками. Средний пинг игрового сервера вроде бы неплохой — 29 мс. Но частые лаги и потери пакетов сильно портят картину.

А теперь включаем cFosSpeed. Он сразу определяет uTorrent и назначает ему минимальный приоритет.

Эффект заметен сразу — скорость загрузки файла падает вдвое.

На пинге игрового сервера это складывается вполне предсказуемым образом. Средний пинг снижается с 29 до 22 мс, а самое главное — периодические «тормоза» становятся намного меньше (в пределах 30 мс) и полностью исчезают потери пакетов.

Правда, видео продолжает периодически подтормаживать. А нельзя ли сделать так, чтобы и пинг был хороший, и видео играло? 

В окне текущих подключений cFosSpeed позволяет задавать приоритет каждому активному приложению. Сменим приоритет Chrome (в нем открыты окна с Youtube) с default на high, а приоритет пинга сервера — с high на higher.

И — все работает: видео играет без рывков, пинг приемлемый. Чтобы убедиться, что это не случайность, повторяем эксперимент с включением/выключением приоритизации трафика еще пару раз.

Без приоритизации трафика: 

C приоритизацией: 

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

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

Плюсы и минусы программ приоритизации трафика

Минусы

• Программы создают дополнительную нагрузку на процессор, во многом дублируя встроенные в ОС механизмы. К примеру, в Windows приоритизацию трафика можно сделать с помощью установки групповых политик QoS.

  
• При использовании канала одним приложением программы приоритизации трафика скорее вредны, так как ускорить передачу данных не в состоянии, но при этом создают дополнительную нагрузку.
• Программы также бесполезны, если канал не загружен полностью.
• Многие программы будут неэффективны на системах, защищенных антивирусами. Например, Doctor Web для выявления сетевых атак пропускает весь трафик через свой драйвер. Соответственно, cFosSpeed вместо реальных получателей сетевых пакетов видит один только этот драйвер (dwnetfilter.exe).

  

Плюсы

• Настройка программ приоритизации трафика намного проще, чем настройка политик QoS в том же Windows, например. Программы приоритизации используют интуитивно-понятный интерфейс и снабжены исчерпывающей справкой. А настройка QoS требует знания стандартов. Поди догадайся, что наивысший приоритет задается установкой DSCP в 46.
• При одновременной работе нескольких приложений с полной загрузкой канала программы приоритизации действительно обеспечивают наивысшую скорость соединения приоритетным приложениям.
• Программы приоритизации способны увеличить скорость даже отдельного соединения — но не за счет приоритизации, а за счет правильной настройки параметров сетевого соединения под канал. Это можно сделать и средствами системы, но надо знать, где и что настраивать. Через программу проще. cFosSpeed, к примеру, может делать это автоматически — с помощью пункта меню «Калибровка линии».

  

Вывод

Программы приоритизации трафика неспособны совершить чудо и превратить канал шириной в 10 Мб/с в 20 Мб/с. На хорошо настроенной системе при использовании одного соединения эффекта от таких программ не будет. 

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

Для управления информационными пакетами, передаваемыми по сети, разработана технология Quality of Service. Расскажем о ней подробнее.

Что такое QoS

Quality of Service (с англ. «качество обслуживания») — это набор технологий, которые запускают высокоприоритетные приложения и трафик при лимитированной пропускной способности. Это означает, что более важный трафик будет обработан быстрее, а задержки по сети будут минимальны.

Измерения, касающиеся QoS, включают:

• Пропускную способность;
• Задержку;
• Дрожание (отклонение в задержке);
• Частоту ошибок.

Благодаря технологии QoS можно научить маршрутизатор разделять пропускную способность и тогда ни потоковое видео, ни звонок в Skype не будут заикаться.

Как работает

Механизмы QoS для упорядочивания пакетов и выделения полосы пропускания:

• управление очередями;
• управление полосой пропускания.

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

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

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

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

• формирование трафика;
• ограничение скорости;
• увеличение полезной полосы пропускания;
• алгоритм планирования;
• другие методы для обеспечения пропускной способности.

В зависимости от поставщика QoS перечисленными средствами можно управлять и объединять в блоки.

Когда используется

Каждый день корпоративные сети перегружаются натиском трафика. Часть этого трафика имеет решающее значение для успеха бизнес-операций. Особенно это может быть важно для IP-телефонии. Поэтому, когда возникает переполнение очереди на сетевых устройствах, QoS необходим, чтобы увеличить скорость обработки данных и убрать переполнение буфера памяти на сетевых устройствах.

Большинство организаций используют протокол передачи файлов (FTP) и приложения для видеоконференций, такие как Zoom или GoToMeeting. Хотя оба показателя важны для производительности сотрудников, пакеты FTP не так чувствительны к задержкам, как пакеты передачи голоса по Интернет-протоколу (VoIP). В случае задержки FTP-пакеты все равно будут доставлены без изменений. Но задержанный VoIP-пакет приведет к разобщенным видеозвонкам и сорванным деловым встречам.

Сервисные модели

Существуют три модели для реализации QoS:

• Best-Effort (Негарантированная доставка);
• IntServ (Интегрированное обслуживание);
• DiffServ (Дифференцированные услуги).

Best-Effort — это модель сервиса по умолчанию, которая применяется к различным сетевым приложениям, таким как протокол передачи файлов (FTP) и электронная почта. Приложение может отправлять любое количество пакетов в любое время без уведомления сети. Затем сеть пытается передать пакеты. Модель Best-Effort подходит для услуг, которые предъявляют минимальные требования к задержке и скорости потери пакетов.

В модели IntServ приложение использует протокол сигнализации для уведомления сети о параметрах трафика и применения уровня QoS перед отправкой пакетов. Сеть резервирует ресурсы для приложения на основе параметров трафика. После того, как приложение получает подтверждение о зарезервированных ресурсах, оно начинает отправлять пакеты в пределах указанного диапазона.

DiffServ — часто используемая модель QoS, классифицирует пакеты в сети и выполняет установленные действия для каждого класса. Когда происходит перегрузка сети, пакеты классов обрабатываются на основе приоритетов, что приводит к неодинаковой частоте потери пакетов, неоднородным задержкам и дрожанию. Пакеты одного и того же класса объединяются и отправляются одним блоком.

В отличие от IntServ, модель DiffServ не требует протокола сигнализации. В этой модели приложение не запрашивает сетевые ресурсы перед отправкой пакетов. Вместо этого приложение устанавливает параметры QoS в пакетах, через которые сеть может узнать требования QoS приложения. Сеть предоставляет дифференцированные услуги на основе параметров QoS каждого потока данных.

Классификация и маркировка

Классификация и маркировка трафика – основа дифференцированных услуг.

Критерии для классификации данных:

• IP-адрес источника или назначения;
• входящий интерфейс;
• значение класса CoS в заголовке;
• значение типа услуги ToS в заголовке IP (приоритет IP или DSCP);
• значение MPLS EXP в заголовке MPLS.

На этапе классификации маршрутизатор распознает трафик, который будет сопоставлен с каждым из классов.

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

• на уровне 2 в заголовке Ethernet;
• на уровне 2.5 в заголовке MPLS;
• на уровне 3 в заголовке IP;
• в верхних слоях.

Благодаря этим изменениям трафик быстро распознается в любой точке сети.

Параметры, которые могут быть установлены или изменены:

• значение CoS исходящего пакета;
• значение DSCP в байте типа ToS;
• значение поля MPLS EXP в верхней метке на интерфейсе ввода или вывода;
• экспериментальное поле EXP многопротокольной коммутации по MPLS на введенных записях меток;
• значение приоритета в заголовке пакета;
• идентификатор группы QoS (ID);
• биты ToS в заголовке IP-пакета.

Например, чтобы разместить голосовой и информационный трафик в отдельных очередях, используют классификацию. Метод маркировки помогает QoS изменять биты в заголовке пакета и указывать приоритет, понятный для других инструментов. Инструменты маркировки для голосовых пакетов используют для гарантии, что программа распознает их в сетевом потоке.

Настройка сервиса на роутере

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

Каждая платформа будет запрашивать скорость загрузки и выгрузки. Не стоит полагаться на заявленную провайдером скорость. Узнать доступную полосу пропускания для загрузки и выгрузки можно на speedtest.net. Полученные результаты преобразуют из Мбита в Кбит.

Алгоритм включения QoS на роутере:

1. Открыть панель администрирования.
2. В адресную строку браузера ввести IP-адрес маршрутизатора.
3. Войти под персональным именем и паролем (указано в руководстве к маршрутизатору).
4. После входа выбрать вкладку «NAT», затем «QoS».
5. Нажать «Включить», оставив порт установленным на WAN, а Packet Scheduler и Queueing Discipline в состоянии по умолчанию.
6. Заполнить значения восходящую и нисходящую линии связи (вводные данные составляют 80-95% значения, полученного в ходе теста скорости).

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

QoS в IP-телефонии

Настройка QoS в IP-телефонии важна для бизнеса, ведь качество связи влияет на количество звонков и, соответственно, конверсию.

Чтобы не допустить помехи связи и задержки звука, можно настроить приоритезацию для данных IP-телефонии. Перед настройкой обратите внимание на характеристики роутера и максимальный размер очереди обработки пакетов. Если канал узкий, то буфер устройства будет переполняться, а новые пакеты удаляться и приоритизация трафика в таком случае бесполезна. Необходимо проложить дополнительные маршруты.

Настроить приоритезацию в IP-телефонии можно двумя способами:

1. В веб-интерфейсе роутера:
• По протоколу SIP/RTP (используется для передачи звука).
• По портам
• По типу трафика
2. В приложении для звонков:
   Необходимо открыть сетевые настройки (Ethernet, IP, ATM, MPLS и др.) и промаркировать трафик. Так роутер поймет, какие данные пропускать быстрее.

Единственный минус — не все роутеры понимают приоритет по заголовку, настройка будет зависеть от устройства и сервиса.

Заключение

Технология QoS помогает поддерживать производительность сети, гарантировать бесперебойную передачу трафика, а также регулярно оценивать состояние IT-инфраструктуры компании. QoS в IP-телефонии влияет на количество и качество звонков, а значит на конверсию.

СДСМ-15. Про QoS. Теперь с возможностью Pull Request’ов.

И вот мы дошли до темы QoS.

Знаете почему только сейчас и почему это будет закрывающая статья всего курса СДСМ? Потому что QoS необычайно сложен. Сложнее всего, что было прежде в цикле.

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

QoS настолько опутан аурой шаманизма и недоступности, что все молодые (и не только) инженеры стараются тщательно игнорировать его существование, считая, что достаточно закидать проблемы деньгами, и бесконечно расширяя линки. Правда пока они не осознают, что при таком подходе их неизбежно ждёт провал. Или бизнес начнёт задавать неудобные вопросы, или возникнет масса проблем, почти не связанных с шириной канала, зато прямо зависящих от эффективности его использования. Ага, VoIP активно машет ручкой из-за кулис, а мультикастовый трафик ехидно поглаживает вас по спинке.

Поэтому давайте просто осознаем, что QoS это обязательно, познать его придётся так или иначе, и почему-бы не начать сейчас, в спокойной обстановке.

---

Содержание

1. Чем определяется QoS?

• Потери
• Задержки
• Джиттер

2. Три модели обеспечения QoS

• Best Effort
• Integrated Services
• Differentiated Services

3. Механизмы DiffServ

4. Классификация и маркировка

• Behavior Aggregate
• Multi-Field
• Interface-Based

5. Очереди

6. Предотвращение перегрузок (Congestion Avoidance)

• Tail Drop и Head Drop
• RED
• WRED

7. Управление перегрузками (Congestion Management)

• First In, First Out
• Priority Queuing
• Fair Queuing
• Round Robin

8. Ограничение скорости

• Shaping
• Policing
• Механизмы Leaky Bucket и Token Bucket

9. Аппаратная реализация QoS

---

До того как читатель нырнёт в эту нору, я заложу в него три установки:

• Не все проблемы можно решить расширением полосы.
• QoS не расширяет полосу.
• QoS про управление ограниченными ресурсами.

1. Чем определяется QoS?

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

Из этого короткого предложения можно вывести все метрики качества сети:

• Потери
• Задержки
• Джиттер

Эти три характеристики определяют качество сети независимо от её природы: пакетная, канальная, IP, MPLS, радио, голуби.

Потери

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

Что делать в случае потерь решает приложение. Оно может проигнорировать их, как в случае с телефонным разговором, где запоздавший пакет уже не нужен, или перезапросить его отправку — так делает TCP, чтобы гарантировать точную доставку исходных данных.

Как управлять потерями, если они неизбежны, в главе Управление перегрузками.

Как использовать потери во благо в главе Предотвращение перегрузок.

Задержки

Это время, которое необходимо данным, чтобы добраться от источника до получателя.

Совокупная задержка складывается из следующих компонентов.

• Задержка сериализации (Serialization Delay) — время, за которое узел разложит пакет в биты и поместит в линк к следующему узлу. Она определяется скоростью интерфейса. Так, например, передача пакета размером 1500 байтов через интерфейс 100Мб/с займёт 0,0001 с, а на 56 кб/с — 0,2 с.
• Задержка передачи сигнала в среде (Propagation Delay) — результат печально известного ограничения скорости распространения электромагнитных волн. Физика не позволяет добраться из Нью-Йорка до Томска по поверхности планеты быстрее чем за 30 мс (фактически порядка 70 мс).
• Задержки, вносимые QoS — это томление пакетов в очередях (Queuing Delay) и последствия шейпинга (Shaping Delay). Об этом мы сегодня будем говорить много и нудно в главе Управление скоростью.
• Задержка обработки пакетов (Processing Delay) — время на принятие решения, что делать с пакетом: lookup, ACL, NAT, DPI — и доставку его от входного интерфейса до выходного. Но в день, когда Juniper в своём M40 разделил Control и Data Plane, задержкой обработки стало можно пренебречь.

Задержки не так страшны приложениям, где не требуется спешка: обмен файлами, сёрфинг, VoD, интернет-радиостанции итд. И напротив, они критичны для интерактивных: 200мс уже неприятны на слух при телефонном разговоре.

Связанный с задержкой термин, но не являющийся синонимом — RTT (Round Trip Time) — это путь туда-обратно. При пинге и трассировке вы видите именно RTT, а не одностороннюю задержку, хотя величины и имеют корреляцию.

Джиттер

Разница в задержках между доставкой последовательных пакетов называется джиттером.

Как и задержка, джиттер для многих приложений не имеет значения. И даже, казалось бы, какая разница — пакет доставлен, чего же боле?

Однако для интерактивных сервисов он важен.

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

Наибольший вклад в вариативность задержки вносит как раз QoS. Об этом тоже много и нудно в тех же главах Ограничение скорости.

---

Это три основные характеристики качества сети, но есть две другие, которые тоже играют не последнюю роль.

Неупорядоченная доставка

Ряд приложений, таких как телефония, NAS, CES экстремально чувствительны к неупорядоченной доставке пакетов, когда они приходят к получателю не в том порядке, в котором были отправлены. Это может приводить к потере связности, ошибкам, повреждению файловой системы.

И хотя неупорядоченная доставка не является формально характеристикой QoS, но определённо относится к качеству сети.

Даже в случае TCP, толерантного к этому виду проблем, происходят дублирующиеся ACK’и и ретрансмиты.

Полоса пропускания

Её не выделяют, как метрику качества сети, поскольку фактически её недостаток выливается в три указанные выше. Однако в наших реалиях, когда некоторым приложениям она должна быть гарантирована или, наоборот, по договору должна быть ограничена, а например MPLS TE её резервирует на всём протяжении LSP, упомянуть её, хотя бы как слабую метрику, стоит.
Механизмы управления скоростью рассмотрим в главах Ограничение скорости.

---

Почему характеристики могут портиться?

Итак, начнём мы с очень примитивного представления, что сетевое устройство (будь то коммутатор, маршрутизатор, файрвол, да что угодно) — это просто ещё один кусочек трубы под названием канал связи, такой же, как медный провод или оптический кабель.

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

Но на самом деле каждый маршрутизатор восстанавливает из сигнала биты и пакеты, что-то с ними делает (об этом пока не думаем) и потом обратно преобразует пакеты в сигнал.

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

Например, на входе в устройство гигабитный порт, а на выходе радио-релейная линия 620 Мб/с, подключенная в такой же гигабитный порт?

Никто не запретит пулять через формально гигабитный линк гигабит трафика.
Ничего тут не поделаешь — 380 Мб/с будут проливаться на пол.

Вот они — потери.

Но при этом очень бы хотелось, чтобы проливалась худшая его часть — видео с youtube, а телефонный разговор исполнительного директора с директором завода не прерывался и даже не квакал.

Хотелось бы, чтобы у голоса была выделенная линия.

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

Добавим щепотку теории VoIP (статью, про который никто так и не написал) — он весьма чувствителен к задержкам и их вариации.

Если для TCP-потока видео с youtube (на момент написания статьи QUIC — ещё остаётся экспериментом) задержки даже в секунды ровным счётом ничего не стоят благодаря буферизации, то директор после первого же такого разговора с камчаткой призовёт к себе руководителя тех.отдела.
В более старые времена, когда автор цикла ещё делал уроки по вечерам, проблема стояла особенно остро. Модемные соединения имели скорость 56к.

И когда в такое соединение приходил полуторакилобайтный пакет, он оккупировал всю линию на 200 мс. Никто другой в этот момент пройти не мог. Голос? Не, не слышал.

Поэтому таким важным является вопрос MTU — пакет не должен слишком надолго оккупировать интерфейс. Чем менее он скоростной, тем меньший MTU необходим.

Вот они — задержки.

Сейчас канал свободен и задержка низкая, через секунду кто-то начал качать большой файл и задержки выросли. Вот он — джиттер.

Таким образом нужно, чтобы голосовые пакеты пролетали через трубу с минимальными задержками, а youtube подождёт.

Имеющиеся 620 Мб/с нужно использовать и для голоса, и для видео, и для B2B клиентов, покупающих VPN. Хотелось бы, чтобы один трафик не притеснял другой, значит нужна гарантия полосы.

---

Все вышеуказанные характеристики универсальны относительно природы сети. Однако существует три разных подхода к их обеспечению.

2. Три модели обеспечения QoS

• Best Effort — никакой гарантии качества. Все равны.
• IntServ — гарантия качества для каждого потока. Резервирование ресурсов от источника до получателя.
• DiffServ — нет никакого резервирования. Каждый узел сам определяет, как обеспечить нужное качество.

Best Effort (BE)

Никаких гарантий.

Самый простой подход к реализации QoS, с которого начинались IP-сети и который практикуется и по сей день — иногда потому что его достаточно, но чаще из-за того, что никто и не думал о QoS.

Кстати, когда вы отправляете трафик в Интернет, то он там будет обрабатываться как BestEffort. Поэтому через VPN, прокинутые поверх Интернета (в противовес VPN, предоставляемому провайдером), может не очень уверенно ходить важный трафик, вроде телефонного разговора.

В случае BE — все категории трафика равны, никакому не отдаётся предпочтение. Соответственно, нет гарантий ни задержки/джиттера, ни полосы.

Этот подход носит несколько контринтуитивное название — Best Effort, которое новичка вводит в заблуждение словом «лучший».

Однако фраза «I will do my best» означает, что говорящий постарается сделать всё, что может, но не гарантирует ничего.

Для реализации BE не требуется ничего — это поведение по умолчанию. Это дёшево в производстве, персоналу не нужны глубокие специфические знания, QoS в этом случае не поддаётся никакой настройке.

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

Например, на трансконтинентальных линиях или в сетях некоторых ЦОДов, где нет переподписки.
Иными словами в сетях без перегрузок и где нет необходимости особенным образом относиться к какому-либо трафик (например, телефонии), BE вполне уместен.

IntServ

Заблаговременное резервирование ресурсов для потока на всём протяжении от источника до получателя.

В растущий бессистемно Интернет отцы сетей MIT, Xerox, ISI решили добавить элемент предсказуемости, сохранив его работоспособность и гибкость.

Так в 1994 году родилась идея IntServ в ответ на стремительный рост реал-тайм трафика и развитие мультикаста.  Сокращалась она тогда до IS.

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

Миссию по резервированию возложили на протокол RSVP, который для каждого потока резервирует полосу на каждом сетевом устройстве.

Грубо говоря, до установки A Single Rate Three Color MarkerP сессии или начала обменом данными, конечные хосты отправляют RSVP Path с указанием требуемой полосы. И если обоим вернулся RSVP Resv — они могут начать коммуницировать. При этом, если доступных ресурсов нет, то RSVP возвращает ошибку и хосты не могут общаться или пойдут по BE.

Пусть теперь храбрейшие из читателей представят, что для любого потока в интернете сегодня будет сигнализироваться канал заранее. Учтём, что это требует ненулевых затрат CPU и памяти на каждом транзитном узле, откладывает фактическое взаимодействие на некоторое время, становится понятно, почему IntServ оказался фактически мертворожденной идеей — нулевая масштабируемость.

В некотором смысле современная инкарнация IntServ — это MPLS TE с адаптированной под передачу меток версией RSVP — RSVP TE. Хотя здесь, конечно же не End-to-End и не per-flow.

IntServ описан в RFC 1633.
Документ в принципе любопытен, чтобы оценить, насколько можно быть наивным в прогнозах.

DiffServ

DiffServ сложный.

Когда в конце 90-х стало понятно, что End-to-End подход IntServ в IP провалился, в IETF созвали в 1997 рабочую группу «Differentiated Services», которая выработала следующие требования к новой модели QoS:

• Никакой сигнализации (Адьёс, RSVP!).
• Основан на агрегированной классификации трафика, вместо акцента на потоках, клиентах итд.
• Имеет ограниченный и детерминированный набор действий по обработке трафика данных классов.

В результате в 1998 родились эпохальные RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) и RFC 2475 (An Architecture for Differentiated Services).

И дальше всю дорогу мы будем говорить только о DiffServ.

Стоит обратить внимание, что название DiffServ — это не антитеза IntServ. Оно отражает, что мы дифференцируем сервисы, предоставляемые различным приложениям, а точнее их трафику, иными словами разделяем/дифференцируем эти типы трафика.
IntServ делает то же самое — он различает типы трафика BE и Real-Time, передающиеся на одной сети. Оба: и IntServ и DiffServ — относятся к способам дифференциации сервисов.

---

3. Механизмы DiffServ

Что же собой являет DiffServ и почему он выигрывает у IntServ?

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

Но просто не будет.

В основе DiffServ лежит идеологически выдержанная в традициях IP концепция PHB — Per-Hop Behavior. Каждый узел по пути трафика самостоятельно принимает решение о том, как вести себя относительно пришедшего пакета, на основе его заголовков.

Действия маршрутизатора с пакетом назовём моделью поведения (Behavior). Количество таких моделей детерминировано и ограничено. На разных устройствах модели поведения по отношению к одному и тому же трафику могут отличаться, поэтому они и per-hop.

Понятия Behavior и PHB я буду использовать в статье как синонимы.

Тут есть лёгкая путаница. PHB — это с одной стороны общая концепция независимого поведения каждого узла, с другой — конкретная модель на конкретном узле. С этим мы ещё разберёмся.

Модель поведения определяется набором инструментов и их параметров: Policing, Dropping, Queuing, Scheduling, Shaping.

Используя имеющиеся модели поведения, сеть может предоставлять различные классы сервиса (Class of Service).

То есть разные категории трафика могут получить разный уровень сервиса в сети путём применения к ним разных PHB.

Соответственно прежде всего нужно определить к какому классу сервиса относится трафик — классификация (Classification).

Каждый узел самостоятельно классифицирует поступающие пакеты.

После классификации происходит измерение (Metering) — сколько битов/байтов трафика данного класса пришло на маршрутизатор.

На основе результатов пакеты могут окрашиваться (Coloring): зелёный (в рамках установленного лимита), жёлтый (вне лимита), красный (совсем берега попутал).

Если необходимо, далее происходит полисинг (Policing) (уж простите за такую кальку, есть вариант лучше — пишите, я поменяю). Полисер на основе цвета пакета назначает действие по отношению к пакету — передать, отбросить или перемаркировать.

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

Но ещё до того, как пакет попадёт в очередь, он может быть отброшен (Dropper), если очередь заполнена.

Если он зелёный, то он пройдёт, если жёлтый, то его вполне вероятно, отбросят, если очередь полна, а если красный — это верный смертник. Условно, вероятность отбрасывания зависит от цвета пакета и наполненности очереди, куда он собирается попасть.

На выходе из очереди работает шейпер (Shaper), задача которого очень похожа на задачу полисера — ограничить трафик до заданного значения.

Можно настроить произвольные шейперы для отдельных очередей или даже внутри очередей.
Об отличии шейпера от полисера в главе Ограничение скорости.

Все очереди в итоге должны слиться в единый выходной интерфейс.

Вспомните ситуацию, когда на дороге 8 полос сливаются в 3. Без регулировщика это превращается в хаос. Разделение по очередям не имело бы смысла, если бы на выходе мы имели то же, что на входе.

Поэтому есть специальный диспетчер (Scheduler), который циклически вынимает пакеты из разных очередей и отправляет в интерфейс (Scheduling).

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

Далее пакеты уже выходят на интерфейс, где происходит преобразование пакетов в поток битов — сериализация (Serialization) и далее сигнал среды.

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

Для этого, во-первых, на всех маршрутизаторах, настраиваются одинаковые классы и PHB для них, а во-вторых, используется маркировка (Marking) пакета — его принадлежность определённому классу записывается в заголовок (IP, MPLS, 802.1q).

И красота DiffServ в том, что следующий узел может довериться этой маркировке при классификации.

Такая зона доверия, в которой действуют одинаковые правила классификации трафика и одни модели поведения, называется домен DiffServ (DiffServ-Domain).

Таким образом на входе в домен DiffServ мы можем классифицировать пакет на основе 5-Tuple или интерфейса, промаркировать (Remark/Rewrite) его согласно правилам домена, и дальнейшие узлы будут доверять этой маркировке и не делать сложную классификацию.
То есть явной сигнализации в DiffServ нет, но узел может сообщить всем следующим, какой класс нужно обеспечить этому пакету, ожидая, что тот доверится.

На стыках между DiffServ-доменами нужно согласовывать политики QoS (или не нужно).

Целиком картина будет выглядеть примерно так:

Чтобы было понятно, приведу аналог из реальной жизни.
Перелёт на самолёте (не Победой).
Есть три класса сервиса (CoS): Эконом, Бизнес, Первый.
При покупке билета происходит классификация (Classification) — пассажир получает определённый класс сервиса на основе цены.
В аэропорту происходит маркировка (Remark) — выдаётся билет с указанием класса.
Есть две модели поведения (PHB): Best Effort и Premium.
Есть механизмы, реализующие модели поведения: Общий зал ожидания или VIP Lounge, микроавтобус или общий автобус, удобные большие сиденья или плотностоящие ряды, количество пассажиров на одну борт-проводницу, возможность заказать алкоголь.
В зависимости от класса назначаются модели поведения — эконому Best Effort, Бизнесу — Premium базовый, а Первому — Premium SUPER-POWER-NINJA-TURBO-NEO-ULTRA-HYPER-MEGA-MULTI-ALPHA-META-EXTRA-UBER-PREFIX!
При этом два Premium отличаются тем что, в одном дают бокал полусладкого, а в другом безлимит Бакарди.

Далее по приезду в аэропорт все заходят через одни двери. Тех, кто попытался провезти с собой оружие или не имеет билета, не пускают (Drop). Бизнес и эконом попадают в разные залы ожидания и разный транспорт (Queuing). Сначала на борт пускают Первый класс, потом бизнес, потом эконом (Scheduling), однако потом они в пункт назначения все летят одним самолётом (интерфейс).

В этом же примере перелёт на самолёте — это задержка передачи (Propagation), посадка — задержка сериализации (Serialization), ожидание самолёта в залах — Queuing, а паспортный контроль — Processing. Заметьте, что и тут Processing Delay обычно пренебрежимо мал в масштабах общего времени.

Следующий аэропорт может обойтись с пассажирами совсем иначе — его PHB отличается. Но при этом если пассажир не меняет авиакомпанию, то, скорее всего, отношение к нему не поменяется, потому что одна компания — один DiffServ-domain.

Как вы могли уже заметить, DiffServ предельно (или беспредельно) сложен. Но всё описанное выше, мы разберём. При этом в статье я не буду вдаваться в нюансы физической реализации (они могут различаться даже на двух платах одного маршрутизатора), не буду рассказывать про HQoS и MPLS DS-TE.

Порог входа в круг инженеров, понимающих технологию, для QoS значительно выше, чем для протоколов маршрутизации, MPLS, или, прости меня Радья, STP.

И несмотря на это DiffServ заслужил признание и внедрение на сетях по всему миру, потому что, как говорится, хайли скэлэбл.

Всю дальнейшую часть статьи я буду разбирать только DiffServ.

Ниже мы разберём все инструменты и процессы, указанные на иллюстрации.

---

По ходу раскрытия темы некоторые вещи я буду показывать на практике.
Работать мы будем вот с такой сетью:

Trisolarans — это клиент провайдера linkmeup с двумя точками подключения.

Жёлтая область — это DiffServ-домен сети linkmeup, где действует единая политика QoS.
Linkmeup_R1 — это CPE устройство, которое находится под управлением провайдера, а потому в доверенной зоне. С ним поднят OSPF и взаимодействие происходит через чистый IP.

В пределах ядра сети MPLS+LDP+MP-BGP с L3VPN, растянутый от Linkmeup_R2 до Linkmeup_R4.
Все остальные комментарии я буду давать по мере необходимости.

Файл начальной конфигурации.

---

4. Классификация и маркировка

Внутри своей сети администратор определяет классы сервиса, которые он может предоставлять трафику.

Поэтому первое, что делает каждый узел при получении пакета, проводит его классификацию.

Существует три способа:

1. Behavior Aggregate (BA)
   Просто довериться имеющейся маркировке пакета в его заголовке. Например, полю IP DSCP.
   Называется он так, потому что под одной меткой в поле DSCP агрегированы различные категории трафика, которые ожидают одинакового по отношению к себе поведения. Например, все SIP-сессии будут агрегированы в один класс.

   Количество возможных классов сервиса, а значит и моделей поведения, ограничено. Соответственно нельзя каждой категории (или тем более потоку) выделить отдельный класс — приходится агрегировать.

2. Interface-based
   Всё, что приходит на конкретный интерфейс, помещать в один класс трафика. Например, мы точно знаем, что в этот порт подключен сервер БД и больше ничего. А в другой рабочая станция сотрудника.
3. MultiField (MF)
   Проанализировать поля заголовков пакета — IP-адреса, порты, MAC-адреса. Вообще говоря, произвольные поля.

   Например, весь трафик, который идёт в подсеть 10.127.721.0/24 по порту 5000, нужно маркировать как трафик, условно, требующий 5-й класс сервиса.

Администратор определяет набор классов сервиса, которые сеть может предоставлять, и сопоставляет им некоторое цифровое значение.

На входе в DS-домен мы никому не доверяем, поэтому проводится классификация вторым или третьим способом: на основе адресов, протоколов или интерфейсов определяется класс сервиса и соответствующее цифровое значение.

На выходе из первого узла эта цифра кодируется в поле DSCP заголовка IP (или другое поле Traffic Class: MPLS Traffic Class, IPv6 Traffic Class, Ethernet 802.1p) — происходит ремаркировка.

Внутри DS-домена принято доверять этой маркировке, поэтому транзитные узлы используют первый способ классификации (BA) — наиболее простой. Никакого сложного анализа заголовков, смотрим только записанную цифру.

На стыке двух доменов можно классифицировать на основе интерфейса или MF, как я описал выше, а можно довериться маркировке BA с оговорками.

Например, доверять всем значениям, кроме 6 и 7, а 6 и 7 перемаркировывать в 5.

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

Behavior Aggregate

В BA используется очень простая классификация — вижу цифру — понимаю класс.
Так что же за цифра? И в какое поле она записывается?

• IPv6 Traffic Class
• MPLS Traffic Class
• Ethernet 802.1p

В основном классификация происходит по коммутирующему заголовку.

Коммутирующим я называю заголовок, на основе которого устройство определяет, куда отправить пакет, чтобы он стал ближе к получателю.
То есть если на маршрутизатор пришёл IP-пакет, анализируется заголовок IP и поле DSCP. Если пришёл MPLS, анализируется — MPLS Traffic Class.

Если на обычный L2-коммутатор пришёл пакет Ethernet+VLAN+MPLS+IP, то анализироваться будет 802.1p (хотя это можно и поменять).

IPv4 TOS

Поле QoS сопутствует нам ровно столько же, сколько и IP. Восьмибитовое поле TOS — Type Of Service — по задумке должно было нести приоритет пакета.

Ещё до появления DiffServ RFC 791 (INTERNET PROTOCOL) описывал поле так:

IP Precedence (IPP) + DTR + 00.

То есть идёт приоритет пакета, далее биты требовательности к Delay, Throughput, Reliability (0 — без требований, 1 — с требованиями).

Последние два бита должны быть нулём.

Чуть позже в RFC 1349 (Type of Service in the Internet Protocol Suite) поле TOS немного переопределили:

Левые три бита остались IP Precedence, четыре следующих превратились в TOS после добавления бита Cost.

Вот как следовало читать единицы в этих битах TOS:

• D — «minimize delay»,
• T — «maximize throughput»,
• R — «maximize reliability»,
• C — «minimize cost».

Туманные описания не способствовали популярности этого подхода.

Системный подход к QoS на всём протяжении пути отсутствовал, чётких рекомендаций, как использовать поле приоритета тоже не было, описание битов Delay, Throughput и Reliability было крайне туманным.

Поэтому в контексте DiffServ поле TOS ещё раз переопределили в RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers):

Вместо битов IPP и DTRC ввели шестибитовое поле DSCP — Differentiated Services Code Point, два правых бита не были использованы.

С этого момента именно поле DSCP должно было стать главной маркировкой DiffServ: в него записывается определённое значение (код), которое в пределах данного DS-домена характеризует конкретный класс сервиса, необходимый пакету и его приоритет отбрасывания. Это та самая цифра.

Все 6 бит DSCP администратор может использовать, как ему заблагорассудится, разделяя максимум до 64 классов сервиса.

Однако в угоду совместимости с IP Precedence за первыми тремя битами сохранили роль Class Selector.

То есть, как и в IPP, 3 бита Class Selector позволяют определить 8 классов.

Однако это всё же не более, чем договорённость, которую в пределах своего DS-домена, администратор может легко игнорировать и использовать все 6 бит по усмотрению.

Далее также замечу, что согласно рекомендациям IETF, чем выше значение, записанное в CS, тем требовательнее этот трафик к сервису.

Но и это не стоит воспринимать как неоспоримую истину.

Если первые три бита определяют класс трафика, то следующие три используются для указания приоритета отбрасывания пакета (Drop Precedence или Packet Loss Priority — PLP).

Восемь классов — это много или мало? На первый взгляд мало — ведь так много разного трафика ходит в сети, что так и хочется каждому протоколу выделить по классу. Однако оказывается, что восьми достаточно для всех возможных сценариев.
Для каждого класса нужно определять PHB, который будет обрабатывать его как-то отлично от других классов.
Да и при увеличении делителя, делимое (ресурс) не увеличивается.
Я намеренно не говорю о том, какие значения какой именно класс трафика описывают, поскольку здесь нет стандартов и формально их можно использовать по своему усмотрению. Ниже я расскажу, какие классы и соответствующие им значения рекомендованы.

---

Практика классификации DSCP

Не помешает немного практики.

Схема та же.

Для начала просто отправим запрос ICMP:

    Linkmeup_R1#ping ip 172.16.2.2 source 172.16.1.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
    Packet sent with a source address of 172.16.1.1 
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Linkmeup_R1. E0/0.

pcapng

А теперь с установленным значением DSCP.

    Linkmeup_R1#ping ip 172.16.2.2 source 172.16.1.1 tos 184
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
    Packet sent with a source address of 172.16.1.1 
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Значение 184 — это десятичное представление двоичного 10111000. Из них первые 6 бит — это 101110, то есть десятичные 46, а это класс EF.

Linkmeup_R2. E0/0

pcapng

Любопытное замечание: адресат попингушек в ICMP Echo reply устанавливает такое же значение класса, как было в Echo Request. Это логично — если отправитель послал пакет с определённым уровнем важности, то, очевидно, он хочет получить его гарантировано назад.

Linkmeup_R2. E0/0

Файл конфигурации DSCP классификации.

IPv6 Traffic Class

IPv6 мало чем в вопросе QoS отличается от IPv4. Восьмибитовое поле, называемое Traffic Class, также разбито на две части. Первые 6 бит — DSCP — играют ровно ту же роль.

Да, появился Flow Label. Говорят, что его можно было бы использовать для дополнительной дифференциации классов. Но применения в жизни эта идея пока нигде не нашла.

MPLS Traffic Class

Концепция DiffServ была ориентирована на IP-сети с маршрутизацией на основе IP-заголовка. Вот только незадача — через 3 года опубликовали RFC 3031 (Multiprotocol Label Switching Architecture). И MPLS начал захватывать сети провайдеров.

DiffServ нельзя было не распространить на него.

По счастливой случайности в MPLS заложили трёхбитовое поле EXP на всякий экспериментальный случай. И несмотря на то, что уже давным-давно в RFC 5462 («EXP» Field Renamed to «Traffic Class» Field) официально стало полем Traffic Class, по инерции его называют ИЭксПи.

С ним есть одна проблема — его длина три бита, что ограничивает число возможных значений до 9. Это не просто мало, это на 3 двоичных порядка меньше, чем у DSCP.

Учитывая, что часто MPLS Traffic Class наследуется из DSCP IP-пакета, имеем архивацию с потерей. Или же… Нет, вы не хотите этого знать… L-LSP. Использует комбинацию Traffic Class + значение метки.

Вообще согласитесь, ситуация странная — MPLS разрабатывался как помощь IP для быстрого принятия решения — метка MPLS мгновенно обнаруживается в CAM по Full Match, вместо традиционного Longest Prefix Match. То есть и про IP знали, и в коммутации участие принимает, а нормальное поле приоритета не предусмотрели.

На самом деле выше мы уже увидели, что для определения класса трафика используется только первые три бита DSCP, а три другие — Drop Precedence (или PLP — Packet Loss Priority).

Поэтому в плане классов сервиса всё же имеем соответствие 1:1, теряя только информацию о Drop Precedence.

В случае MPLS классификация так же как и в IP может быть на основе интерфейса, MF, значения DSCP IP или Traffic Class MPLS.

Маркировка означает запись значения в поле Traffic Class заголовка MPLS.

Пакет может содержать несколько заголовков MPLS. Для целей DiffServ используется только верхний.

Существуют три разных сценария перемаркировки при продвижении пакета из одного чистого IP-сегмента в другой через MPLS-домен: (это просто выдержка из статьи).

1. Uniform Mode
2. Pipe Mode
3. Short-Pipe Mode

---

Практика классификации MPLS Traffic Class

Схема та же:

Файл конфигурации тот же.

В схеме сети linkmeup есть переход из IP в MPLS на Linkmeup_R2.
Посмотрим, что происходит с маркировкой при пинге ping ip 172.16.2.2 source 172.16.1.1 tos 184.

Linkmeup_R2. E0/0.

pcapng

Итак, мы видим, что изначальная метка EF в IP DSCP трансформировалась в значение 5 поля EXP MPLS (оно же Traffic Class, помним это) как VPN-заголовка, так и транспортного.
Тут мы являемся свидетелями режима работы Uniform.

---

Ethernet 802.1p

Отсутствие поля приоритета в 802.3 (Ethernet) находит своё объяснение в том, что Ethernet изначально планировался исключительно как решение для LAN-сегмента. За скромные деньги можно получить избыточную пропускную способность, и узким местом всегда будет аплинк — не за чем беспокоиться о приоритизации.

Однако очень скоро стало ясно, что финансовая привлекательность Ethernet+IP выводит эту связку на уровень магистрали и WAN. Да и сожительство в одном LAN-сегменте торрентов и телефонии нужно разруливать.

По счастью к этому моменту подоспел 802.1q (VLAN), в котором выделили 3-битовое (опять) поле под приоритеты.

В плане DiffServ это поле позволяет определить те же 8 классов трафика.

---

При получении пакета сетевое устройство DS-домена в большинстве случаев берёт в рассмотрение тот заголовок, который оно использует для коммутации:

• Ethernet-коммутатор — 802.1p
• MPLS-узел — MPLS Traffic Class
• IP-маршрутизатор — IP DSCP

Хотя это поведение можно и изменить: Interface-Based и Multi-Field классификация. А можно иногда даже явно сказать, в поле CoS какого заголовка смотреть.

---

Interface-based

Это наиболее простой способ классифицировать пакеты в лоб. Всё, что насыпалось в указанный интерфейс, помечается определённым классом.

В некоторых случаях такой гранулярности хватает, поэтому Interface-based находит применение в жизни.

Практика по Interface-based классификации

Схема та же:

Настройка политик QoS в оборудовании большинства вендоров делится на этапы.

1. Сначала определяется классификатор:
   class-map match-all TRISOLARANS_INTERFACE_CM
match input-interface Ethernet0/2
   Всё, что приходит на интерфейс Ethernet0/2.
2. Далее создаётся политика, где связываются классификатор и необходимое действие.

       policy-map TRISOLARANS_REMARK
        class TRISOLARANS_INTERFACE_CM
         set ip dscp cs7

   Если пакет удовлетворяет классификатору TRISOLARANS_INTERFACE_CM, записать в поле DSCP значение CS7.

   Здесь я забегаю вперёд, используя непонятные CS7, а далее EF, AF. Ниже можно прочитать про эти аббревиатуры и принятые договорённости. Пока же достаточно знать, что это разные классы с разным уровнем сервиса.

3. И последним шагом применить политику на интерфейс:

       interface Ethernet0/2
        service-policy input TRISOLARANS_REMARK

   Здесь немного избыточен классификатор, который проверят что пакет пришёл на интерфейс e0/2, куда мы потом и применяем политику. Можно было бы написать match any:

   class-map match-all TRISOLARANS_INTERFACE_CM
            match any

   Однако политика на самом деле может быть применена на vlanif или на выходной интерфейс, поэтому можно.

Пускаем обычный пинг на 172.16.2.2 (Trisolaran2) с Trisolaran1:

И в дампе между Linkmeup_R1 и Linkmeup_R2 увидим следующее:

pcapng

Файл конфигурации Interface-Based классификации.

Multi-Field

Наиболее часто встречающийся тип классификации на входе в DS-домен. Не доверяем имеющейся маркировке, а на основе заголовков пакета присваиваем класс.

Зачастую это способ вообще «включить» QoS, в случае, когда отправители не проставляют маркировку.

Достаточно гибкий инструмент, но в то же время громоздкий — нужно создавать непростые правила для каждого класса. Поэтому внутри DS-домена актуальнее BA.

Практика по MF классификации

Схема та же:

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

Это прекрасно внутри DS-домена, но неприемлемо в точке входа.

А давайте теперь не будем слепо доверять? На Linkmeup_R2 ICMP будем метить как EF (исключительно для примера), TCP как AF12, а всё остальное CS0.
Это будет MF (Multi-Field) классификация.

1. Процедура та же, но теперь матчить будем по ACL, которые выцепляют нужные категории трафика, поэтому сначала создаём их.

   На Linkmeup_R2:

       ip access-list extended TRISOLARANS_ICMP_ACL
        permit icmp any any
       ip access-list extended TRISOLARANS_TCP_ACL
        permit tcp any any
       ip access-list extended TRISOLARANS_OTHER_ACL
        permit ip any any

2. Далее определяем классификаторы:

       class-map match-all TRISOLARANS_TCP_CM
        match access-group name TRISOLARANS_TCP_ACL
       class-map match-all TRISOLARANS_OTHER_CM
        match access-group name TRISOLARANS_OTHER_ACL
       class-map match-all TRISOLARANS_ICMP_CM
        match access-group name TRISOLARANS_ICMP_ACL

3. А теперь определяем правила перемаркировки в политике:

       policy-map TRISOLARANS_ADMISSION_CONTROL
        class TRISOLARANS_ICMP_CM
         set ip dscp ef
        class TRISOLARANS_TCP_CM
         set ip dscp af11
        class TRISOLARANS_OTHER_CM
         set ip dscp default

4. И вешаем политику на интерфейс. На input, соответственно, потому что решение нужно принять на входе в сеть.

       interface Ethernet0/1
        service-policy input TRISOLARANS_ADMISSION_CONTROL

ICMP-тест с конечного хоста Trisolaran1. Никак сознательно не указываем класс — по умолчанию 0.

Политику с Linkmeup_R1 я уже убрал, поэтому трафик приходит с маркировкой CS0, а не CS7.

Вот два дампа рядом, с Linkmeup_R1 и с Linkmeup_R2:

Linkmeup_R1. E0/0.

pcapng

Linkmeup_R2. E0/0.

pcapng

Видно, что после классификаторов и перемаркировки на Linkmeup_R2 на ICMP-пакетах не только DSCP поменялся на EF, но и MPLS Traffic Class стал равным 5.

Аналогичный тест с telnet 172.16.2.2. 80 — так проверим TCP:

Linkmeup_R1. E0/0.

pcapng

Linkmeup_R2. E0/0.

pcapng

ЧИТО — Что И Требовалось Ожидать. TCP передаётся как AF11.

Следующим тестом проверим UDP, который должен попасть в CS0 согласно нашим классификаторам. Для этого воспользуемся iperf (привезти его в Linux Tiny Core изи через Apps). На удалённой стороне iperf3 -s — запускаем сервер, на локальной iperf3 -c -u -t1 — клиент (-c), протокол UDP (-u), тест в течение 1 секунды (-t1).

Linkmeup_R1. E0/0.

pcapng

Linkmeup_R2. E0/0

pcapng

С этого момента всё, что приходит в этот интерфейс, будет классифицировано согласно настроенным правилам.

---

Маркировка внутри устройства

Ещё раз: на входе в DS-домен может происходить классификация MF, Interface-based или BA.
Между узлами DS-домена пакет в заголовке несёт знак о необходимом ему классе сервиса и классифицируется по BA.

Независимо от способа классификации после неё пакету присваивается внутренний класс в пределах устройства, в соответствии с которым он и обрабатывается. Заголовок при этом снимается, и голый (нет) пакет путешествует к выходу.
А на выходе внутренний класс преобразуется в поле CoS нового заголовка.

То есть Заголовок 1 ⇒ Классификация ⇒ Внутренний класс сервиса ⇒ Заголовок 2.

В некоторых случаях нужно отобразить поле заголовка одного протокола в поле заголовка другого, например, DSCP в Traffic Class.

Происходит это как раз через промежуточную внутреннюю маркировку.

Например, Заголовок DSCP ⇒ Классификация ⇒ Внутренний класс сервиса ⇒ Заголовок Traffic Class.

Формально, внутренние классы могут называться как угодно или просто нумероваться, а им в соответствие только ставится определённая очередь.

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

Если мы говорим о конкретных реализациях QoS, то количество классов сервиса, которое устройство может обеспечить, не больше, чем количество доступных очередей. Зачастую их восемь (не то под влиянием IPP, не то по неписанной договорённости). Однако в зависимости от вендора, устройства, платы, их может быть как больше, так и меньше.

То есть если очередей 4, то классов сервиса просто нет смысла делать больше четырёх.

Чуть поподробнее об этом поговорим в аппаратной главе.

В плане PHB нет абсолютно никакой разницы что используется для классификации — DSCP, Traffic Class, 802.1p.

Внутри устройства они превращаются в классы трафика, определённые администратором сети.
То есть все эти маркировки — это способ сообщить соседям, какой класс сервиса им следует назначить этому пакету. Это примерно, как BGP Community, которые не значат ничего сами по себе, пока на сети не определена политика их интерпретации.

---

Рекомендации IETF (категории трафика, классы сервиса и модели поведения)

Стандарты вообще не нормируют, какие именно классы сервиса должны существовать, как их классифицировать и маркировать, какие PHB к ним применять.

Это отдано на откуп вендорам и администраторам сетей.

Имеем только 3 бита — используем, как хотим.

Это хорошо:

• Каждая железка (вендор) самостоятельно выбирает, какие механизмы использовать для PHB — нет сигнализации, нет проблем совместимости.
• Администратор каждой сети может гибко распределять трафик по разным классам, выбирать сами классы и соответствующий им PHB.

Это плохо:

• На границах DS-доменов возникают вопросы преобразования.
• В условиях полной свободой действий — кто в лес, кто бес.

Поэтому IETF в 2006 выпустила методичку, как следует подходить к дифференциации сервисов: RFC 4594 (Configuration Guidelines for DiffServ Service Classes).

Далее коротко суть этого RFC.

Модели поведения (PHB)

DF — Default Forwarding
Стандартная пересылка.
Если классу трафика не назначена модель поведения специально, он будет обрабатываться именно по Default Forwarding.

Это Best Effort — устройство сделает всё возможное, но ничего не гарантирует. Возможны отбрасывания, разупорядочивание, непредсказуемые задержки и плавающий джиттер, но это не точно.

Такая модель подходит для нетребовательных приложений, вроде почты или загрузки файлов.
Есть, кстати, PHB и ещё менее определённый — A Lower Effort.

AF — Assured Forwarding
Гарантированная пересылка.
Это улучшенный BE. Здесь появляются некоторые гарантии, например, полосы. Отбрасывания и плавающие задержки всё ещё возможны, но уже в гораздо меньшей степени.

Модель подходит для мультимедии: Streaming, видео-конференц-связь, онлайн-игры.
RFC 2597 (Assured Forwarding PHB Group).

EF — Expedited Forwarding
Экстренная пересылка.
Все ресурсы и приоритеты бросаются сюда. Это модель для приложений, которым нужны отсутствие потерь, короткие задержки, стабильный джиттер, но они не жадные до полосы. Как, например, телефония или сервис эмуляции провода (CES — Circuit Emulation Service).

Потери, разупорядочивание и плавающие задержки в EF крайне маловероятны.
RFC 3246 (An Expedited Forwarding PHB).

CS — Class Selector
Это модели поведения, призванные сохранить обратную совместимость с IP-Precedence в сетях, умеющих в DS.

В IPP существуют следующие классы CS0, CS1, CS2, CS3, CS4, CS5, CS6, CS7.
Не всегда для всех них существует отдельный PHB, обычно их два-три, а остальные просто транслируются в ближайший DSCP класс и получают соответствующий ему PHB.
Так например, пакет, помеченный CS 011000, может классифицироваться как 011010.

Из CS наверняка в оборудовании сохранились только CS6, CS7, которые рекомендованы для NCP — Network Control Protocol и требуют отдельного PHB.

Как и EF, PHB CS6,7 предназначены для тех классов, что имеют очень высокие требования к задержкам и потерям, однако до некоторой степени толерантны к дискриминации по полосе.
Задача PHB для CS6,7 обеспечить уровень сервиса, который исключит дропы и задержки даже в случае экстремальной перегрузки интерфейса, чипа и очередей.

---

Важно понимать, что PHB — это абстрактное понятие — и на самом деле реализуются они через механизмы, доступные на реальном оборудовании.

Таким образом один и тот же PHB, определённый в DS-домене, может различаться на Juniper и Huawei.

Более того, один PHB — это не статический набор действий, PHB AF, например, может состоять из нескольких вариантов, которые различаются уровнем гарантий (полосой, допустимыми задержками).

---

Классы сервиса

В IETF позаботились об администраторах и определили основные категории приложений и агрегирующие их классы сервиса.

Я здесь не буду многословен, просто вставлю пару табличек из этого Guideline RFC.

Категории приложений:

Требования в характеристикам сети:

И наконец рекомендованные имена классов и соответствующие значения DSCP:

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

Наиболее частым является, пожалуй, такое:

Классом DF (или BE) маркируется абсолютно нетребовательный трафик — он получает внимание по остаточному принципу.

PHB AF обслуживает классы AF1, AF2, AF3, AF4. Им всем нужно обеспечить полосу, в ущерб задержкам и потерям. Потери управляются битами Drop Precedence, поэтому они и называются AFxy, где x — класс сервиса, а y — Drop Precedence.

EF нужна некая минимальная гарантия полосы, но что важнее — гарантия задержек, джиттера и отсутствия потерь.

CS6, CS7 требуют ещё меньше полосы, потому что это ручеёк служебных пакетов, в котором всё же возможны всплески (BGP Update, например), но в ней недопустимы потери и задержки — какая польза от BFD с таймером в 10 мс, если Hello вялится в очереди по 100 мс?

То есть 4 класса из 8 доступных отдали под AF.

И несмотря на то, что фактически обычно так и делают, повторюсь, что это только рекомендации, и ничто не мешает в вашем DS-домене трём классам назначить EF и только двум — AF.

---

Короткий итог по классификации

На входе в узел пакет классифицируется на основе интерфейса, MF или его маркировки (BA).
Маркировка — это значение полей DSCP в IPv4, Traffic Class в IPv6 и в MPLS или 802.1p в 802.1q.
Выделяют 8 классов сервиса, которые агрегируют в себе различные категории трафика. Каждому классу назначается свой PHB, удовлетворяющий требованиям класса.

Согласно рекомендациям IETF, выделяются следующие классы сервисов, это CS1, CS0, AF11, AF12, AF13, AF21, CS2, AF22, AF23, CS3, AF31, AF32, AF33, CS4, AF41, AF42, AF43, CS5, EF, CS6, CS7 в порядке возрастания важности трафика.

Из них можно выбрать комбинацию из 8, которые реально можно закодировать в поля CoS.
Наиболее распространённая комбинация: CS0, AF1, AF2, AF3, AF4, EF, CS6, CS7 с 3 градациями цвета для AF.

Каждому классу ставится в соответствие PHB, которых существует 3 — Default Forwarding, Assured Forwarding, Expedited Forwarding в порядке возрастания строгости. Немного в стороне стоит PHB Class Selector. Каждый PHB может варьироваться параметрами инструментов, но об этом дальше.

---

В незагруженной сети QoS не нужен, говорили они. Любые вопросы QoS решаются расширением линков, говорили они. С Ethernet и DWDM нам никогда не грозят перегрузки линий, говорили они.
Они — те, кто не понимает, что такое QoS.

Но реальность бьёт VPN-ом по РКНу.

1. Не везде есть оптика. РРЛ — наша реальность. Иногда в момент аварии (да и не только) в узкий радио-линк хочет пролезть весь трафик сети.
2. Всплески трафика — наша реальность. Кратковременные всплески трафика легко забивают очереди, заставляя отбрасывать очень нужные пакеты.
3. Телефония, ВКС, онлайн-игры — наша реальность. Если очередь хоть на сколько-то занята, задержки начинают плясать.

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

Пришло время разобраться с инструментами, которые позволяют обеспечить разный сервис разным классам.

---

Инструменты PHB

Существует на самом деле всего лишь три группы инструментов обеспечения QoS, которые активно манипулируют пакетами:

• Предотвращение перегрузок (Congestion Avoidance) — что делать, чтобы не было плохо.
• Управление перегрузками (Congestion Management) — что делать, когда уже плохо.
• Ограничение скорости (Rate Limiting) — как не пустить в сеть больше, чем положено, и не выпустить столько, сколько не смогут принять.

Но все они по большому счёту были бы бесполезны, если бы не очереди.

5. Очереди

В парке аттракционов нельзя отдать кому-то приоритет, если не организовать отдельную очередь для тех, кто заплатил больше.

Такая же ситуация в сетях.

Если весь трафик в одной очереди, не получится выдёргивать из её середины важные пакеты, чтобы дать им приоритет.

Именно поэтому после классификации пакеты помещаются в соответствующую данному классу очередь.

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

Но в пределах каждой отдельной очереди действует то же правило — нельзя выдернуть пакет из середины — только из его изголовья.

Каждая очередь обладает определённой ограниченной длиной. С одной стороны это диктуется аппаратными ограничениями, а с другой тем, что нет смысла держать пакеты в очереди слишком долго. VoIP пакет не нужен, если он задержался на 200мс. TCP запросит переотправку, условно, после истечения RTT (настраивается в sysctl). Поэтому отбрасывание — не всегда плохо.
Разработчикам и дизайнерам сетевого оборудования приходится находить компромисс между попытками сохранить пакет как можно дольше и напротив не допустить бесполезной траты полосы, пытаясь доставить уже никому не нужный пакет.

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

Если же трафика приходит больше, чем может обработать чип коммутации или выходной интерфейс, очереди начинают заполняться. И хроническая утилизация выше 20-30% — это уже ситуация, к которой нужно принимать меры.

---

6. Предотвращение перегрузок (Congestion Avoidance)

В жизни любого маршрутизатора наступает момент, когда очередь переполняется. Куда положить пакет, если положить его решительно некуда — всё, буфер кончился, совсем, и не будет, даже если хорошо поискать, даже если доплатить.

Тут есть два путя: отбросить либо этот пакет, либо те, что уже очередь забили.
Если те, что уже в очереди, то считай, что пропало.

А если этот, то считай, что и не приходил он.

Эти два подхода называются Tail Drop и Head Drop.

Tail Drop и Head Drop

Tail Drop — наиболее простой механизм управления очередью — отбрасываем все вновь пришедшие пакеты, не помещающиеся в буфер.

Head Drop отбрасывает пакеты, которые стоят в очереди уже очень долго. Их уже лучше выбросить, чем пытаться спасти, потому что они, скорее всего, бесполезны. Зато у более актуальных пакетов, пришедших в конец очереди, будет больше шансов прийти вовремя. Плюс к этому Head Drop позволит не загружать сеть ненужными пакетами. Естественным образом самыми старыми пакетами оказываются те, что в самой голове очереди, откуда и название подхода.

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

Оба механизма работают с дифференциацией по очередям. То есть на самом деле не обязательно, чтобы весь буфер переполнился. Если 2-ая очередь пустая, а нулевая под завязку, то отбрасываться буду только пакеты из нулевой.

Tail Drop и Head Drop могут работать одновременно.

---

Tail и Head Drop — это Congestion Avoidance «в лоб». Даже можно сказать — это его отсутствие.
Ничего не предпринимаем, пока очередь не заполнится на 100%. А после этого все вновь прибывшие (или надолго задержавшиеся) пакеты начинаем отбрасывать.

Если для достижения цели не нужно ничего делать, значит где-то есть нюанс.
И этот нюанс — TCP.

Вспомним (поглубже и экстремально глубоко), как работает TCP — речь про современные реализации.

Есть Скользящее окно(Sliding Window или rwnd — Reciever’s Advertised Window), которым управляет получатель, сообщая отправителю, сколько можно посылать.

А есть окно перегрузки (CWND — Congestion Window), которое реагирует на проблемы в сети и управляется отправителем.

Процесс передачи данных начинается с медленного старта (Slow Start) с экспоненциальным ростом CWND. С каждым подтверждённым сегментом к CWND прибавляется 1 размер MSS, то есть фактически оно удваивается за время, равное RTT (туда данные, обратно ACK) (Речь про Reno/NewReno).

Например,

Экспоненциальный

рост продолжается до значения, называемого ssthreshold (Slow Start Threshold), которое указывается в конфигурации TCP на хосте.

Далее начинается

линейный

рост по 1/CWND на каждый подтверждённый сегмент до тех пор, пока либо не упрётся в RWND, либо не начнутся потери (о потерях свидетельсв повторное подтверждение (Duplicated ACK) или вообще отсутствие подтверждения).

Как только зафиксирована потеря сегмента, происходит TCP Backoff — TCP резко уменьшает окно, фактически снижая скорость отправки, — и запускается механизм Fast Recovery:

1. отправляются потерянные сегменты (Fast Retransmission),
2. окно скукоживается в два раза,
3. значение ssthreshold тоже становится равным половине достигнутого окна,
4. снова начинается линейный рост до первой потери,
5. Повторить.

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

Однако к чему приводит Tail Drop?

1. Допустим через маршрутизатор лежит путь тысячи TCP-сессий. В какой-то момент трафик сессий достиг 1,1 Гб/с, скорость выходного интерфейса — 1Гб/с.
2. Трафик приходит быстрее, чем отправляется, буферы заполняются всклянь.
3. Включается Tail Drop, пока диспетчер не выгребет из очереди немного пакетов.
4. Одновременно десятки или сотни сессий фиксируют потери и уходят в Fast Recovery (а то и в Slow Start).
5. Объём трафика резко падает, буферы прочищаются, Tail Drop выключается.
6. Окна затронутых TCP-сессий начинают расти, и вместе с ними скорость поступления трафика на узкое место.
7. Буферы переполняются.
8. Fast Recovery/Slow Start.
9. Повторить.

Подробнее об изменениях в механизмах TCP в RFC 2001 (TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms).

Это характерная иллюстрация ситуации, называемой глобальной синхронизацией TCP (Global TCP Synchronization):

Глобальная — потому что страдают много сессий, установленных через этот узел.
Синхронизация, потому что страдают они одновременно. И ситуация будет повторяться до тех пор, пока имеет место перегрузка.

TCP — потому что UDP, не имеющий механизмов контроля перегрузки, ей не подвержен.

Ничего плохого в этой ситуации не было бы, если бы она не вызывала неоптимальное использование полосы — промежутки между зубцами пилы — потраченные зря деньги.

Вторая проблема — это TCP Starvation — истощение TCP. В то время, как TCP сбавляет свою скорость для снижения нагрузки (не будем лукавить — в первую очередь, чтобы наверняка передать свои данные), UDP эти все моральные страдания вообще по датаграмме — шлёт сколько может.

Итак, количество трафика TCP снижается, а UDP растёт (возможно), следующий цикл Потеря — Fast Recovery случается на более низком пороге. UDP занимает освободившееся место. Общее количество TCP-трафика падает.

Чем решать проблему, лучше её избежать. Давайте попробуем снизить нагрузку до того, как она заполнит очередь, воспользовавшись Fast Recovery/Slow Start, который только что был против нас.

RED — Random Early Detection

А что если взять и дропы размазать по некоторой части буфера?

Условно говоря, начинать отбрасывать случайные пакеты, когда очередь заполняется на 80%, заставляя некоторые TCP-сессии уменьшить окно и соответственно, скорость.

А если очередь заполнена на 90%, начинаем отбрасывать случайным образом 50% пакетов.
90% — вероятность растёт вплоть до Tail Drop (100% новых пакетов отбрасывается).

Механизмы, реализующие такое управление очередью называются AQM — Adaptive (или Active) Queue Management

Именно так и работает RED.
Early Detection — фиксируем потенциальную перегрузку;
Random — отбрасываем пакеты в случайном порядке.
Иногда расшифровывают RED (на мой взгляд семантически более корректно), как Random Early Discard.

Графически это выглядит так:

До заполнения буфера на 80% пакеты не отбрасываются совсем — вероятность 0%.
От 80 до 100 пакеты начинают отбрасываться, и тем больше, чем выше заполнение очереди.
Так процент растёт от 0 до 30.

Побочным эффектом RED является и то, что агрессивные TCP-сессии скорее начнут притормаживать, просто потому что их пакетов много и они с бо́льшей вероятностью будут отброшены.

Неэффективность использования полосы RED решает тем, что притупляет гораздо меньшую часть сессий, не вызывая такую серьёзную просадку между зубьями.
Ровно по этой же причине UDP не может оккупировать всё.

WRED — Weighted Random Early Detection

Но на слуху у всех, наверно, всё-таки WRED. Проницательный читатель linkmeup уже предположил, что это тот же RED, но взвешенный по очередям. И оказался не совсем прав.
RED работает в пределах одной очереди. Нет смысла оглядываться на EF, если переполнилась BE. Соответственно и взвешивание по очередям ничего не принесёт.
Здесь как раз работает Drop Precedence.

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

Здесь есть три кривые:
Красная — менее приоритетный трафик (с точки зрения отбрасывания), жёлтая — более, зелёная — максимально.
Красный трафик начинает отбрасываться уже при заполнении буфера на 20%, с 20 до 40 он дропается вплоть до 20%, далее — Tail Drop.
Жёлтый стартует попозже — с 30 до 50 он отбрасывается вплоть до 10%, далее — Tail Drop.
Зелёный наименее подвержен: с 50 до 100 плавно растёт до 5 %. Далее — Tail Drop.
В случае с DSCP это могли бы быть AF11, AF12 и AF13, соответственно зелёная, жёлтая и красная.

Очень важно здесь то, что это работает с TCP и это абсолютно неприменимо к UDP.
Либо приложение использующее UDP игнорирует потери, как в случае телефонии или потокового видео, и это отрицательно сказывается на том, что видит пользователь.

Либо приложение само осуществляет контроль доставки и попросит повторно отправить тот же самый пакет. При этом оно совсем не обязано просить источник снизить скорость передачи. И вместо уменьшения нагрузки получается увеличение из-за ретрансмитов.

Именно поэтому для EF применяется только Tail Drop.

Для CS6, CS7 тоже применяется Tail Drop, поскольку там не предполагается больших скоростей и WRED ничего не решит.

Для AF применяется WRED. AFxy, где x — класс сервиса, то есть очередь, в которую он попадает, а y — приоритет отбрасывания — тот самый цвет.

Для BE решение принимается на основе преобладающего в этой очереди трафика.

В пределах одного маршрутизатора используются специальная внутренняя маркировка пакетов, отличная от той, что несут заголовки. Поэтому MPLS и 802.1q, где нет возможности кодировать Drop Precedence, в очередях могут обрабатываться с различными приоритетами отбрасывания.
Например, MPLS пакет пришёл на узел, он не несёт маркировки Drop Precedence, однако по результатам полисинга оказался жёлтым и перед помещением в очередь (которая может определяться полем Traffic Class), может быть отброшен.

При этом стоит помнить, что вся эта радуга существует только внутри узла. В линии между соседями нет понятия цвета.

Хотя закодировать цвет в Drop Precedence-часть DSCP, конечно, возможно.

Отбрасывания могут появиться и в незагруженной сети, где казалось бы никакого переполнения очередей быть не должно. Как?
Причиной этому могут быть кратковременные всплески — бёрсты — трафика. Самый простой пример — 5 приложений одновременно решили передать трафик на один конечный хост.
Пример посложнее — отправитель подключен через интерфейс 10 Гб/с, а получатель — 1 Гб/с. Сама среда позволяет крафтить пакеты быстрее на отправителе. Ethernet Flow Control получателя просит ближайший узел притормозить, и пакеты начинают скапливаться в буферах.

---

Ну а что же делать, когда плохо всё-таки стало?

7. Управление перегрузками (Congestion Management)

Когда всё плохо, приоритет обработки следует отдать более важному трафику. Важность каждого пакета определяется на этапе классификации.

Но что такое плохо?

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

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

Эту проблему призван решить механизм управления перегрузками (Congestion Management).
Трафик разных приложений разделяется по очередям, как мы уже видели выше.
Вот только в результате всё снова должно слиться в один интерфейс. Сериализация всё равно происходит последовательно.

Каким же образом разным очередям удаётся предоставлять различный уровень сервисов?
По-разному изымать пакеты из разных очередей.

Занимается этим диспетчер.

Мы рассмотрим большинство существующих сегодня диспетчеров, начиная с самого простого:

• FIFO — только одна очередь, все в BE, С — несправедливость.
• PQ — дорогу олигархам, холопы уступают.
• FQ — все равны.
• DWRR — все равны, но некоторые ровнее.

FIFO — First In, First Out

Простейший случай, по сути отсутствие QoS, — весь трафик обрабатывается одинаково — в одной очереди.

Пакеты уходят из очереди ровно в том порядке, в котором они туда попали, отсюда и название: первым вошёл — первым и вышел.

FIFO не является ни диспетчером в полном смысле этого слова, ни вообще механизмом DiffServ, поскольку фактически никак классы не разделяет.

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

Агрессивные TCP-сессии с размером пакетов по 1500 байтов могут оккупировать всю очередь, заставляя страдать мелкие голосовые пакеты.

В FIFO все классы сливаются в CS0.

Однако несмотря на все эти недостатки именно так работает сейчас Интернет.

У большинства вендоров FIFO и сейчас является диспетчером по умолчанию с одной очередью для всего транзитного трафика и ещё одной для локально-сгенерированных служебных пакетов.
Это просто, это крайне дёшево. Если каналы широкие, а трафика мало — всё отлично.
Квинтэссенция мысли о том, что QoS — для бедных — расширяй полосу, и заказчики будут довольны, а зарплата твоя будет расти кратно.

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

FIFO стало недостаточно, поэтому создали несколько очередей и начали плодить схемы диспетчеризации трафика.

Однако FIFO никогда не уходит из нашей жизни: внутри каждой из очередей пакеты всегда обрабатываются по принципу FIFO.

PQ — Priority Queuing

Второй по сложности механизм и попытка разделить сервис по классам — приоритетная очередь.

Трафик теперь раскладывается в несколько очередей согласно своему классу — приоритету (например, хотя не обязательно, те же BE, AF1-4, EF, CS6-7). Диспетчер перебирает одну очередь за другой.

Сначала он пропускает все пакеты из самой приоритетной очереди, потом из менее, потом из менее. И так по кругу.

Диспетчер не начинает изымать пакеты низкого приоритета, пока не пуста высокоприоритетная очередь.

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

PQ работает почти так же в лоб, как FIFO.

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

Ну, согласитесь, не стоит придерживать BFD Hello из-за того, что пришли несколько больших видео-чанков с ютуба?

Но тут и кроется недостаток PQ — если приоритетная очередь нагружена трафиком, диспетчер вообще никогда не переключится на другие.

И если какой-то Доктор ЗЛО в поисках методов завоевания мира решит помечать весь свой злодейский трафик наивысшей чёрной меткой, все другие будут покорно ждать, а потом отбрасываться.

О гарантированной полосе для каждой очереди говорить тоже не приходится.
Высокоприоритетные очереди можно прирезать по скорости обрабатываемого в них трафика. Тогда другие не будут голодать. Однако контролировать это непросто.

---

Следующие механизмы ходят по всем очередям по очереди, забирая из них некое количество данных, тем самым предоставляя более честные условия. Но делают они это по-разному.

FQ-Fair Queuing

Следующий претендент на роль идеального диспетчера — механизмы честных очередей.

FQ — Fair Queuing

История его началась в 1985, когда Джон Нейгл предложил создавать очередь на каждый поток данных. По духу это близко к подходу IntServ и это легко объяснимо тем, что идеи классов сервиса, как и DiffServ тогда ещё не было.

FQ извлекал одинаковый объём данных из каждой очереди по порядку.

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

Так агрессивный TCP-поток не может затопить интерфейс, и все получают равные возможности.
В теории. FQ так и не был реализован на практике как механизм диспетчеризации очередей в сетевом оборудовании.

Недостатка тут три:
Первый — очевидный — это очень дорого — заводить очередь под каждый поток, считать вес каждого пакета и всегда беспокоиться о пропускаемых битах и размере пакета.
Второй — менее очевидный — все потоки получают равные возможности в плане пропускной способности. А если я хочу неравные?
Третий — неочевидный — честность FQ абсолютная: задержки у всех тоже равные, но есть потоки которым задержка важнее, чем полоса.
Например, среди 256 потоков присутствуют голосовые, это значит, что до каждого из них дело будет доходить только раз из 256-и.
И что делать с ними непонятно.

Здесь вы можете видеть, что из-за большого размера пакета в 3-ей очереди, в первые два цикла обработали по одному пакету из первых двух.

Описание механизмов bit-by-bit Round Robin и GPS уже за пределами этой статьи, и я отсылаю читателя к самостоятельному изучению.

WFQ — Weighted Fair Queuing

Второй и отчасти третий недостатки FQ попытался закрыть WFQ, обнародованный в 1989 году.
Каждая очередь наделялась весом и соответственно правом за один цикл отдавать трафика кратно весу.
Вес высчитывался на основе двух параметров: ещё актуальном тогда IP Precedence и длине пакета.

В контексте WFQ чем больше вес, тем хуже.
Поэтому чем выше IP Precedence, тем меньше вес пакета.
Чем меньше размер пакета, тем меньше и его вес.
Таким образом высокоприоритетные пакеты небольшого размера получают больше всего ресурсов, тогда как, низкоприоритетные гиганты ждут.
На иллюстрации ниже пакеты получили такие веса, что сначала пропускается один пакет из первой очереди, потом два из второй, снова из первой и только потом обрабатывается третья. Так, например, могло сложиться, если размер пакетов во второй очереди сравнительно маленький.

Про суровую машинерию WFQ, с её packet finish time, виртуальным временем и Теоремой Парика можно почитать в любопытном цветном документе.

Впрочем первую и третью проблемы это никак не решало. Flow Based подход был так же неудобен, а потоки, нуждающиеся в коротких задержках и стабильных джиттерах, их не получали.
Это, впрочем, не помешало WFQ найти применение в некоторых (преимущественно старых) устройствах Cisco. Там имелось до 256 очередей, в которые потоки помещались на основе хэша от своих заголовков. Этакий компромисс между Flow-Based парадигмой и ограниченными ресурсами.

CBWFQ — Class-Based WFQ

Заход на проблему сложности сделал CBWFQ с приходом DiffServ. Behavior Aggregate классифицировал все категории трафика в 8 классов и, соответственно, очередей. Это дало ему имя и значительно упростило обслуживание очередей.

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

То есть DSCP определял в какую очередь помещать, а настроенный вес — сколько полосы доступно данной очереди.

Самое главное, что это косвенно немного облегчило жизнь и low-latency потокам, которые теперь были агрегированы в одну (две-три-…) очереди и получали свой звёздный час заметно чаще. Жить стало лучше, но ещё не хорошо — гарантий никаких так и нет — в целом в WFQ все по-прежнему равны в плане задержек.

Да и необходимость постоянного слежения за размером пакетов, их фрагментации и дефрагментации, никуда не делась.

CBWFQ+LLQ — Low-Latency Queue

Последний заход, кульминация бит-по-биту подхода, — это объединение CBWFQ с PQ.
Одна из очередей становится так называемой LLQ (очередь с низими задержками), и в то время, пока все остальные очереди обрабатываются диспетчером CBWFQ, между LLQ и остальными работает диспетчер PQ.

То есть пока в LLQ есть пакеты, остальные очереди ждут, растят свои задержки. Как только пакеты в LLQ кончились — пошли обрабатывать остальные. Появились пакеты в LLQ — про остальные забыли, вернулись к нему.

Внутри LLQ работает также FIFO, поэтому не стоит туда пихать всё, что ни попадя, увеличивая утилизацию буфера и заодно задержки.

И всё-таки чтобы неприоритетные очереди не голодали, в LLQ стоит ставить ограничение по полосе.

Вот так и овцы сыты и волки целы.

RR — Round-Robin

Рука об руку с FQ шёл и RR.
Один был честен, но не прост. Другой совсем наоборот.

RR перебирал очереди, извлекая из них равное число пакетов. Подход более примитивный, чем FQ, и оттого нечестный по отношению к различным потокам. Агрессивные источники легко могли затопить полосу пакетами размером в 1500 байтов.

Однако он очень просто реализовывался — не нужно знать размер пакета в очереди, фрагментировать его и собирать потом обратно.

Однако его несправедливость в распределении полосы перекрыла ему путь в мир — в мире сетей чистый Round-Robin не был реализован.

WRR — Weighted Round Robin

Та же судьба и у WRR, который придавал очередям вес на основе IP Precedence. В WRR вынималось не равное число пакетов, а кратное весу очереди.

Можно было бы давать больший вес очередям с более мелкими пакетами, но делать это динамически не представлялось возможным.

DWRR — Deficit Weighted Round Robin

И вдруг, крайне любопытный подход в 1995-м году предложили M. Shreedhar and G. Varghese.
Каждая очередь имеет отдельную кредитную линию в битах.

При проходе из очереди выпускается столько пакетов, на сколько хватает кредита.

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

Если даже первому пакету не хватает кредита, что ж, увы-селявы, он остаётся в очереди.
Перед следующим проходом кредит каждой очереди увеличивается на определённую сумму, называемую квант.

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

Таким образом все очереди получают гарантированную полосу, независимо от размера пакетов в ней.

Мне бы из объяснения выше не было понятно, как это работает.

С DWRR всё же остаётся вопрос с гарантией задержек и джиттера — вес его никак не решает.
Теоретически, здесь можно поступить как и с CB-WFQ, добавив LLQ.

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

PB-DWRR — Priority-Based DWRR

Собственно практически мейнстримом сегодня становится PB-DWRR — Priority Based Deficit Weighted Round Robin.

Это тот же старый злой DWRR, в который добавлена ещё одна очередь — приоритетная, пакеты в которой обрабатываются с более высоким приоритетом. Это не значит, что ей отдаётся бóльшая полоса, но то, что оттуда пакеты будут забираться чаще.

Существует несколько подходов к реализации PB-DWRR. В одних из них, как в PQ, любой пришедший в приоритетную очередь пакет изымается сразу. В других, обращение к ней происходит каждый раз при переходе диспетчера между очередями. В третьих и для неё вводится кредит и квант, чтобы приоритетная очередь не могла отжать всю полосу.
Разбирать мы их, конечно, не будем.

Короткий итог про механизмы диспетчеризации

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

Начиная с FIFO, оно изобрело PQ — голос смог сосуществовать с сёрфингом, но не было речи про гарантию полосы.

Появились несколько монструозные FQ, WFQ, работавшие если не per-flow, то почти так. CB-WFQ пришёл к классовому обществу, но не стал от этого проще.

Как альтернатива ему развивался RR. Он превратился в WRR, а затем и в DWRR.
И в глубине каждого из диспетчеров живёт FIFO.

Однако, как видите, нет некоего универсального диспетчера, который все классы обрабатывал так, как они того требуют. Это всегда комбинация диспетчеров, один из которых решает задачу обеспечения задержек, джиттера и отсутствия потерь, а другой распределения полосы.
CBWFQ+LLQ или PB-WDRR или WDRR+PQ.

На реальном оборудовании можно указать какие именно очереди каким диспетчером обрабатывать.

CBWFQ, WDRR и их производные — это сегодняшние фавориты.
PQ, FQ, WFQ, RR, WRR — не скорбим и не помним (если, конечно, не готовимся к CCIE Клиппер).

---

Итак, гарантировать скорость диспетчеры умеют, но как же ограничить её сверху?

8. Ограничение скорости

Необходимость ограничения скорости трафика на первый взгляд очевидна — не выпустить клиента за пределы его полосы согласно договору.

Да. Но не только. Допустим имеется РРЛ-пролёт шириной в 620 Мб/с, подключенный через порт 1Гб/с. Если пулять в него весь гигабит, то где-то на РРЛ, которая, вполне вероятно, не имеет представления об очередях и QoS, начнутся чудовищные отбрасывания случайного характера, не привязанные к реальным приоритетам трафика.

Однако, если на маршрутизаторе включить шейпинг до 600 Мб/с, то EF, CS6, CS7 не будут отбрасываться совсем, а в BE, AFх полоса и дропы распределятся согласно их весам. До РРЛ будет доходить 600 Мб/с и мы получим предсказуемую картину.

Другой пример — входной контроль (Admission Control). Например, два оператора договорились доверять всей маркировке друг друга, кроме CS7 — если что-то пришло в CS7 — отбрасывать. Для CS6 и EF — давать отдельную очередь с гарантией задержки и отсутствия потерь.

Но, что если хитроумный партнёр начал лить в эти очереди торренты? Прощай телефония. Да и протоколы начнут, скорее всего, разваливаться.

Логично в этом случае договориться с партнёром о полосе. Всё, что укладывается в договор — пропускаем. Что не укладывается — отбрасываем или переводим в другую очередь — BE, например. Таким образом защищаем свою сеть и свои сервисы.

Существует два принципиально разных подхода к ограничению скорости: полисинг и шейпинг. Решают они одну задачу, но по-разному.

Рассмотрим разницу на примере такого профиля трафика:

Traffic Policing

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

Что срезано, то забыто. На картинке видно, что красный пакет отсутствует в трафике после полисера.

И вот как будет выглядеть выбранный профиль после полисера:

Из-за строгости принимаемых мер это называется Hard Policing.
Однако есть и другие возможные действия.
Полисер обычно работает совместно с измерителем трафика. Измеритель красит пакеты, как вы помните, в зелёный, жёлтый или красный.
А на основе уже этого цвета полисер может не отбросить пакет, а поместить в другой класс. Это мягкие меры — Soft Policing.
Применяться может как ко входящему трафику, так и к исходящему.
Отличительная черта полисера — способность абсорбировать всплески трафика и определять пиковую допустимую скорость благодаря механизму Token Bucket.
То есть на самом деле не срезается всё, что выше заданного значения — разрешается немного за него выходить — пропускаются кратковременные всплески или небольшие превышения выделенной полосы.

Название «Policing» диктуется довольно строгим отношением инструмента к лишнему трафику — отбрасывание или разжалование в более низкий класс.

Traffic Shaping

Шейпинг ограничивает скорость путём буферизации лишнего трафика.

Весь приходящий трафик проходит через буфер. Шейпер из этого буфера с постоянной скоростью изымает пакеты.

Если скорость поступления пакетов в буфер ниже выходной, они в буфере не задерживаются — пролетают насквозь.

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

На иллюстрации хорошо видно, как пакет, пришедший буфер в момент времени t2, на выходе оказывается в момент t3. t3-t2 — это задержка, вносимая шейпером.

Шейпер обычно применяется к исходящему трафику.

Так выглядит профиль после шейпера.

Название «Shaping» говорит о том, что инструмент придаёт профилю трафика форму, сглаживая его.

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

Главный недостаток — непредсказуемая задержка — при заполнении буфера, пакеты будут томиться в нём долго. Поэтому не для всех типов трафика шейпинг хорошо подходит.
Shaping использует механизм Leaky Bucket.

Шейпинг против полисинга

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

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

Для тех же, для которых опоздавший пакет всё равно, что потерянный, лучше его отбросить сразу — тогда полисинг.

Шейпер никак не влияет на заголовки пакетов и их судьбу за пределами узла, в то время как после полисинга устройство может перемарикровать класс в заголовке. Наример, на входе пакет имел класс AF11, метеринг покрасил его в жёлтый цвет внутри устройства, на выходе оно перемаркировало его класс на AF12 — на следующем узле у него будет более высокая вероятность отбрасывания.

---

Практика Полисинг и шейпинг

Схема та же:

Файл конфигурации.

Такую картину наблюдаем без применения ограничений:

Мы поступим следующим образом:

• На входном интерфейсе Linkmeup_R2 (e0/1) настроим полисинг — это будет входной контроль. По договору мы даём 10 Мб/с.
• На выходном интерфейсе Linkmeup_R4 (e0/2) настроим шейпинг на 20 Мб/с.

Начнём с шейпера на Linkmeup_R4.

Матчим всё:

    class-map match-all TRISOLARANS_ALL_CM
     match any 

Шейпим до 20Мб/с:

    policy-map TRISOLARANS_SHAPING
     class TRISOLARANS_ALL_CM
      shape average 20000000

Применяем на выходной интерфейс:

    interface Ethernet0/2
     service-policy output TRISOLARANS_SHAPING

Всё, что должно покинуть (output) интерфейс Ethernet0/2, шейпим до 20 Мб/с.

Файл конфигурации шейпера.

И вот результат:

Получается достаточно ровная линия общей пропускной способности и рваные графики по каждому отдельному потоку.

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

---

Теперь настроим полисинг на Linkmeup_R2.

К существующей политике добавим полисер.

    policy-map TRISOLARANS_ADMISSION_CONTROL
    class TRISOLARANS_TCP_CM
     police cir 10000000 bc 1875000 conform-action transmit exceed-action drop 

На интерфейс политика уже применена:

    interface Ethernet0/1
     service-policy input TRISOLARANS_ADMISSION_CONTROL

Здесь указываем среднюю разрешённую скорость CIR (10Mб/с) и разрешённый всплеск Bc (1 875 000 байтов около 14,6 МБ).

Позже, объясняя, как работает полисер, я расскажу, что за CIR да Bc и как эти величины определять.

Файл конфигурации полисера.

Такая картина наблюдается при полисинге. Сразу видно резкие изменения уровня скорости:

---

А вот такая любопытная картина получается, если мы сделаем слишком маленьким допустимый размер всплеска, например, 10 000 байтов.

    police cir 10000000 bc 10000 conform-action transmit  exceed-action drop 

Общая скорость сразу упала до примерно 2Мб/с.
Будьте аккуратнее с настройкой всплесков:)

Таблица тестов.

---

Механизмы Leaky Bucket и Token Bucket

Звучит легко и понятно. Но как работает на практике и реализовано в железе?

Пример.

Ограничение в 400 Мб/с — это много (или мало)? В среднем клиент использует только 320. Но иногда поднимается до 410 на 5 минут. А иногда до 460 на минуту. А иногда до 500 на полсекунды.
Как договоропорядочный провайдер linkmeup может сказать — 400 и баста! Хотите больше, подключайтесь на тариф 1Гб/с+27 аниме-каналов.
А можем повысить лояльность клиента, если это не мешает другим, разрешив такие всплески.
Как разрешить 460Мб/с на всего лишь одну минуту, а не на 30 или навсегда?
Как разрешить 500 Мб/с, если полоса свободна, и прижать до 400, если появились другие потребители?

Теперь передохните, налейте ведро крепкого.

Начнём с более простого механизма, используемого шейпером — протекающее ведро.

Алгоритм Leaky bucket

Leaky Bucket — это протекающее ведро.

Имеем ведро с отверстием заданного размера внизу. В это ведро сверху сыпятся/льются пакеты. А снизу они вытекают с постоянной битовой скоростью.

Когда ведро заполняется, новые пакеты начинают отбрасываться.

Размер отверстия определяется заданным ограничением скорости, которая для Leaky Bucket измеряется в битах в секунду.

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

В плане реализации Leaky Bucket — это обычный буфер на основе SD-RAM.

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

Leaky Bucket используется только для шейпинга и не подходит для полисинга.

Алгоритм Token Bucket

Многие считают, что Token Bucket и Leaking Bucket — одно и то же. Сильнее ошибался только Эйнштейн, добавляя космологическую постоянную.

Чипы коммутации не очень-то хорошо понимают, что такое время, ещё хуже они считают сколько битов они за единицу времени передали. Их работа — молотить.

Вот этот приближающийся бит — это ещё 400 000 000 бит в секунду или уже 400 000 001?

Перед разработчиками ASIC стояла нетривиальная инженерная задача.

Её разделели на две подзадачи:

1. Собственно ограничение скорости путём отбрасывания лишних пакетов на основе очень простого условия. Выполняется на чипах коммутации.
2. Создание этого простого условия, которым занимается более сложный (более специализированный) чип, ведущий счёт времени.

Алгоритм, решающий вторую задачу называется Token Bucket. Его идея изящна и проста (нет).

Задача Token Bucket — пропускать трафик, если он укладывается в ограничение и отбрасывать/красить в красный, если нет.

При этом важно разрешить всплески трафика, поскольку это нормальное явление.
И если в Leaky Bucket всплески амортизировались буфером, то Token Bucket ничего не буферизирует.

Single Rate — Two Color Marking

Пока не обращайте внимания на название =)
Имеем ведро, в которое падают монетки с постоянной скорость — 400 мегамонет в секунду, например.

Объём ведра — 600 миллионов монет. То есть наполняется оно за полторы секунды.

Рядом проходят две ленты конвейера: одна подвозит пакеты, вторая — увозит.
Чтобы попасть на отвозящий конвейер, пакет должен заплатить.
Монетки для этого он берёт из ведра в соответствии со своим размером. Грубо говоря — сколько битов — столько и монеток.

Если ведро опустело и монет пакету не хватило, он окрашивается в красный сигнальный цвет и отбрасывается. Увы-селявы. При этом монеты из ведра не вынимаются.

Следующему пакету монет уже может хватить — во-первых, пакет может быть поменьше, а, во-вторых, ещё монет за это время нападает.

Если ведро уже полное, все новые монеты будут выбрасываться.

Всё зависит от скорости поступления пакетов и их размера.
Если она стабильно ниже или равна 400 Мб в секунду, значит монет всегда будет хватать.
Если выше, то часть пакетов будет теряться.

Более конкретный пример с гифками, как мы все любим.

• Есть ведро ёмкостью 2500 байтов. На начальный момент времени в нём лежит 550 токенов.
  На конвейере три пакета по 1000 байтов, которые хотят быть отправлены в интерфейс.
  В каждый квант времени в ведро падает 500 байтов (500*8 = 4 000 бит/квант времени — ограничение полисера).
• На исходе первого кванта времени в ведро падает 500 токенов. И в это время подходит первый пакет. Его размер 1000 байтов, а в ведре 1050 токенов — хватает. Пакет красится в зелёный цвет и пропускается. 1000 токенов вынимается из ведра.
  В ведре остаётся 50 токенов.
• На исходе второго кванта времени в ведро падает ещё 500 токенов — итого 550. А размер пришедшего пакета — 1000 — не хватает.
  Пакет красится красным и отбрасывается, токены не вынимаются.
• На исходе третьего кванта в ведро падает ещё 500 токенов — снова 1050. Размер пришедшего пакета — 1000 — хватает.
  Пакет красится в зелёный и пропускается, токены вынимаются из ведра.

Объём ведра в 2500 байтов фактически означает, что через такой полисер ни при каких условиях не пройдёт пакет больше 2500 байтов — ему никогда не будет хватать токенов. Поэтому его объём должен быть не меньше MTU и вообще рекомендуется объём, равный количеству трафика на максимальной скорости, разрешённой полисером, за 1,5-2 секунды.

То есть формула следующая:

CBS = CIR (бит в секунду)*1,5 (секунды)/8 (бит в байте)

Если вернуться к практическому примеру по полисингу, где мы настраивали всплески (Bc), то станет понятно, что при большом значении (1 875 000 байтов) все всплески амортизируются хорошо. А при маленьком (10 000 байтов), несмотря на то, что оно заметно больше MTU, полисер упирается в постоянное заполнение ведра и отбрасывает большое количество пакетов.

Зачем ведру объём? Битовый поток не всегда равномерен, это очевидно. Ограничение в 400 Мб/с — это не асимптота — трафик может её пересекать. Объём хранящихся монет позволяет небольшим всплескам пролетать, не будучи отброшенными, однако среднюю скорость сохранить на уровне 400Мб/с.

Например, стабильный поток 399 Мб/с за 600 секунд позволит ведру наполниться до краёв.
Далее трафик может подняться до 1000Мб/с и держаться на этом уровне 1 секунду — 600 Мм (Мегамонет) запаса и 400 Мм/с гарантированной полосы.

Или же трафик может подняться до 410 Мб/с и держаться таким на протяжении 60 секунд.

То есть запас монет позволяет слегка выйти за ограничение на продолжительное время или выплеснуть короткий но высокий всплеск.
Теперь к терминологии.
Скорость поступления монет в ведро — CIR — Committed Information Rate (Гарантированная средняя скорость). Измеряется в битах в секунду.
Количество монет, которые могут храниться в ведре — CBS — Committed Burst Size. Разрешённый максимальный размер всплесков. Измеряется в байтах. Иногда, как вы уже могли заметить, называется Bc.
Tc — Количество монет (Token) в ведре C (CBS) в данный момент.

В статье я использую термин «Tc«, так же, как он использован в RFC 2697 (A Single Rate Three Color Marker).
Однако есть и другой Tc, который описывает интервал времени, когда в ведро ссыпается новая порция монет.
Здесь следует сделать отступление.
Невозможно подстроить скорость интерфейса, чтобы удовлетворить условиям полисера, поэтому и вводится система Token Bucket, реализующая по сути TDM (Time-Division Multiplexing) — она разрешает отправку трафика только в определённые моменты времени.
То есть монеты не льются в ведро непрерывным потоком — современный мир, увы, дискретен.
В первом приближении предлагается один раз в секунду насыпать CIR монет. Потом через секунду итд.
Это работает плохо, потому что всплеск — и секунда молчания, всплеск — и секунда молчания, всплеск — и секунда молчания.
Поэтому во втором приближении секунда делится на интервалы времени, в которые спускается определённое число монет.
Такой интервал времени тоже называется (как минимум в литературе Cisco) Tc, а количество падающих монет — Bc. При этом Bc = CIR*Tc.
То есть в начале каждого интервала Tc в ведро опускается Bc монет.

Это самый простой сценарий. Он называется Single Rate — Two Color.
Single Rate означает, что есть только одна средняя разрешённая скорость, а Two Color — что можно покрасить трафик в один из двух цветов: зелёный или красный.

1. Если количество доступных монет (бит) в ведре C больше, чем количество бит, которые нужно пропустить в данный момент, пакет красится в зелёный цвет — низкая вероятность отбрасывания в дальнейшем. Монеты изымаются из ведра.
2. Иначе, пакет красится в красный — высокая вероятность дропа (либо, чаще, сиюминутное отбрасывание). Монеты при этом из ведра С не изымаются.

Используется для полисинга в PHB CS и EF, где превышения по скорости не ожидается, но если оно произошло, то лучше сразу отбросить.

Дальше рассмотрим посложнее: Single Rate — Three Color.

Single Rate — Three Color Marking

Недостаток предыдущей схемы в том, что есть только два цвета. Что если мы не хотим отбрасывать всё, что выше средней разрешённой скорости, а хотим быть ещё более лояльными?
sr-TCM (Single Rate — Three Color Marking) вводит второе ведро в систему — E. На этот раз монеты, не поместившиеся в заполненное ведро C, пересыпаются в E.

К CIR и CBS добавляется EBS — Excess Burst Size — Разрешённый размер всплесков во время пиков. Te — количество монет в ведре E.

Допустим пакет размера B пришёл по конвейеру. Тогда

1. Если монет в ведре C хватает, пакет красится в зелёный и пропускается. Из ведра C вынимается B монет (Остаётся: Tc — B).
2. Если монет в ведре C не хватает, проверяется ведро E. Если в нём монет хватает, пакет красится в жёлтый (средняя вероятность дропа), из ведра E вынимается B монет.

   

3. Если и в ведре E не хватает монет, то пакет красится в красный, монеты не вынимаются ниоткуда.

   

Обратите внимание, что для конкретного пакета Tc и Te не суммируются.
То есть пакет размером 8000 байтов не пройдёт, даже если в ведре C будет 3000 монет, а в E — 7000. В C не хватает, в E не хватает — ставим красное клеймо — шуруй отсюда.

Это очень изящная схема. Весь трафик, который укладывается в среднее ограничение CIR+CBS (автор знает, что нельзя так напрямую складывать биты/с и байты) — проходит зелёным. В пиковые моменты, когда клиент исчерпал монеты в ведре C, у него есть ещё накопленный за время простоя запас Te в ведре E.

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

sr-TCM описан в RFC 2697.
Используется для полисинга в PHB AF.

Ну и последняя система — самая гибкая и потому сложная — Two Rate — Three Color.

Two Rate — Three Color Marking

Модель Tr-TCM родилась из идеи, что не в ущерб другим пользователям и типам трафика, почему бы клиенту не дать чуть больше приятных возможностей, а ещё лучше продать.
Скажем ему, что ему гарантировано 400 Мб/с, а если есть свободные ресурсы, то 500. Готовы заплатить на 30 рублей больше?

Добавляется ещё одно ведро P.

Таким образом:

CIR — гарантированная средняя скорость.
CBS — тот же разрешённый размер всплеска (объём ведра C).
PIR — Peak Information Rate — максимальная средняя скорость.
EBS — разрешённый размер всплесков во время пиков (Объём ведра P).

В отличие от sr-TCM, в tr-TCM в оба ведра теперь независимо поступают монеты. В C — со скоростью CIR, в P — PIR.

Какие правила?

Приходит пакет размером B байтов.

1. Если монет в ведре P не хватает — пакет помечается красным. Монеты не выниваются. Иначе:
2. Если монет в ведре C не хватает — пакет помечается жёлтым, и из ведра P вынимаются B монет. Иначе:
3. Пакет помечается зелёным и из обоих вёдер вынимаются B монет.

То есть правила в tr-TCM другие.

Пока трафик укладывается в гарантированную скорость, монеты вынимаются из обоих вёдер. Благодаря этому, когда в ведре C монеты кончатся, останутся в P, но ровно столько, чтобы не превысить PIR (если бы вынимались только из C, то P наполнялось бы больше и давало гораздо бо́льшую скорость).

Соответственно, если он выше гарантированной, но ниже пиковой, монеты вынимаются только из P, потому что в C уже нет ничего.

tr-TCM следит не только за всплесками, но и за постоянной пиковой скоростью.

tr-TCM описан в RFC 2698.
Тоже используется для полисинга в PHB AF.

---

Короткий итог по ограничению скорости

В то время как шейпинг откладывает трафик при превышении, полисинг его отбрасывает.
Шейпинг не подходит для приложений, чувствительных к задержкам и джиттеру.
Для реализации полисинга в железе используется алгоритм Token Bucket, для шейпинга — Leaky Bucket.

Token Bucket может быть:

• С одним ведром — Single Rate — Two Color Marking. Позволяет допустимые всплески.
• С двумя вёдрами — Single Rate — Three Color Marking (sr-TCM). Излишки из ведра C (CBS) пересыпаются в ведро E. Позволяет допустимые и избыточные всплески.
• С двумя вёдрами — Two Rate — Three Color Marking (tr-TCM). Вёдра C и P (PBS) пополняются независимо с разными скоростями. Позволяет пиковую скорость и допустимые и избыточные всплески.

sr-TCM сфокусирован на объёме трафика сверх лимита. tr-TCM — на скорости, с которой он поступает.

Полисинг может использоваться на входе и на выходе с устройства. Шейпинг преимущественно на выходе.
Для PHB CS и EF используется Single Rate Two Color Marking.
Для AF — sr-TCM или tr-TCM.

Для, возможно, лучшего понимания, рекомендую обратиться к оригинальным RFC или почитать тут.

Механизм Token Bucket вполне применим и в быту. Например, если я иду с друзьями в бар, в то время, как жена проводит время с двумя детьми, то каждую минуту из ведра вынимается токен.
Если я вычерпаю всё ведро, то на выходных не могу пойти на пробежку — жду, пока накапает. Если токенов мало, то часок побегать можно, а вот уехать на выходной на работу, чтобы заняться статьёй — уже нет.
Правда рейт наполнения ведра не постоянный, токены выделяются за добрые дела. На самом деле здесь система из двух связанных ведёр — моего и жены. Но так можно и на целую статью материала написать.

---

Выше я описал все основные механизмы QoS, если не углубляться в иерархический QoS. Сложнейшая система с многочисленными движущимися частями.
Всё хорошо (правда ведь?) звучало до сих пор, но что же творится под ванильной внешней панелью маршрутизатора?

Годами вендоры добавляли всё новые и новые конутры, разрабатывали сложнейшие чипы, расширяли буферы, чтобы с одной стороны поспевать за растущим объёмом трафика и новыми его категориями, а с другой, решать нарастающий проблемы, вызываемые первым пунктом.
Непрекращающаяся гонка. Нельзя терять пакеты, если конкурент их не теряет. Нельзя отказаться от функционала, если соперник стоит с ним под дверями заказчика.
Айда в логово проприетарщины!

9. Аппаратная реализация QoS

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

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

В общем, сделаю дисклеймер, что в действительности всё не так, как на самом деле, и пойду по варианту простого изложения.

Да простит меня мой попутчик-перфекционист.

Что управляет поведением узла и запускает соответствующие механизмы по отношению к пакету? Приоритет, который он несёт в одном из заголовков? И да, и нет.

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

Как только пакет попал на чип коммутации, заголовки с него снимаются и отправляются на анализ, а полезная нагрузка томится в каком-то временном буфере.

На основе заголовков происходит классификация (BA или MF) и принимается решение о пересылке.

Через мгновение на пакет навешивается внутренний заголовок с метаданными о пакете.
Эти метаданные несут много важной информации — адреса отправителя и получателя, выходной чип, порядковый номер ячейки, если была фрагментация пакета и обязательно маркировку класса (CoS) и приоритет отбрасывания (Drop Precedence). Только маркировку во внутреннем формате — он может совпадать с DSCP, а может и нет.

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

У Cisco внутренняя маркировка зовётся QoS Group, у Juniper — Forwarding Class, Huawei не определился: где-то называет internal priorities, где-то local priorities, где-то Service-Class, а где-то просто CoS. Добавляйте в комментарии названия для других вендоров — я дополню.

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

Однако, на входе в DS-домен после классификации обычно происходит перемаркировка в определённый класс сервиса, принятый в данной сети. Тогда внутренняя маркировка преобразуется в значение, принятое для данного класса на сети, и записывается в заголовок отправляемого пакета.

Внутренняя маркировка CoS и Drop Precedence определяет поведение только внутри данного узла и никак явным образом не передаётся соседям, кроме перемаркировки заголовков.

CoS и Drop Precedence определяют PHB, его механизмы и параметры: предотвращение перегрузок, управление перегрузками, диспетчеризация, перемаркировка.

---

Через какие круги проходят пакеты между входным и выходным интерфейсами я рассмотрел в предыдущей статье. Собственно она и оказалась внеплановой, поскольку в какой-то момент стало очевидно, что без понимания архитектуры говорить о QoS преждевременно.

Однако, давайте повторимся.

1. Сигнал попадает на физический входной интерфейс и его чип (PIC). Из него вналивается битовый поток и потом пакет со всеми заголовками.
2. Далее на входной чип коммутации (FE), где заголовки отделяются от тела пакета. Происходит классификация и определяется, куда пакет нужно отправить дальше.
3. Далее во входную очередь (TM/VOQ). Уже здесь пакеты раскладываются в разные очереди на основе своего класса.
4. Далее на фабрику коммутации (если она есть).
5. Далее в выходную очередь (TM).
6. Далее в выходной чип коммутации (FE), где навешиваются новые заголовки.
7. Далее в выходной интерфейс (возможно, через ещё одну очередь) (PIC).

При этом маршрутизатор должен решить сложное уравнение.
Разложить всё по классам, предоставить кому-то широкую полосу, кому-то низкие задержки, кому-то обеспечить отсутствие потерь.
И при этом успеть пропустить по возможности весь трафик.
Кроме того, нужно сделать шейпинг, возможно, полисинг. Если вдруг имеет место перегрузка, то справиться с ней.
И это не считая лукапов, обработки ACL, подсчёта статистик.
Незавидная доля. Но вкалывают роботы, а не человек.

На самом деле есть всего два места, где работают механизмы QoS — это чип коммутации и чип Traffic Management/очереди.

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

• Классификация
• Полисинг
• Перемаркировка

Остальное берёт на себя TM. В основном это рутинные операции с предопределённым алгоритмом и настраиваемыми параметрами:

• Предотвращение перегрузок
• Управление перегрузками
• Шейпинг

TM — это умный буфер, обычно на основе SD-RAM.

Умный он потому что, а) программируемый, б) с очередями умеет делать всякие хитрые штуки.
Зачастую он распределённый — чипы SD-RAM расположены на каждой интерфейсной плате, и все вместе они объединяются в VOQ (Virtual Output Queue), решающий проблему Head of Line Blocking.
Дело в том, что если чип коммутации или выходной интерфейс захлёбывается, то они просят входной чип притормозить и не отправлять некоторое время трафик. Если там только одна очередь на все направления, то очень обидно, что из-за одного выходного интерфейса страдают все остальные. Это и есть Head of Line Blocking.

VOQ же создаёт на входной интерфейсной плате несколько виртуальных выходных очередей для каждого существующего выходного интерфейса.

Причём эти очереди в современном оборудовании учитывают и маркировку пакета.
Про VOQ достаточно подробно описано в серии заметок здесь.

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

VOQ — это программная очередь (английский термин Software Queue более точен). После него сразу перед интерфейсом находится ещё аппаратная очередь, которая всегда, строго работает по FIFO. Управлять какими-либо её параметры практически невозможно (для примера, Cisco позволяет настроить только глубину командой tx-ring-limit).

Как раз между программной и аппаратной очередью можно запускать произвольные диспетчеры. Именно в программной очереди работают Head/Tail-drop и AQM, полисинг и шейпинг.

Размер аппаратной очереди очень небольшой (единицы пакетов), потому что всю работу по укладыванию в line-rate делает диспетчер.

К сожалению, здесь можно сделать много оговорок, да и вообще всё перечеркнуть красной ручкой и сказать «у вендора Х всё не так».

---

Хочется сделать ещё одно замечание о служебных пакетах. Они обрабатываются иначе, чем транзитные пользовательские пакеты.

Будучи сгенерированными локально, они не проверяются на подпадание под правила ACL, и ограничения скорости.

Пакеты же извне, предназначенные на CPU, с выходного чипа коммутации попадают в другие очереди — к CPU — на основе типа протокола.

Например, BFD имеет наивысший приоритет, OSPF может подождать подольше, а ICMP и вообще не страшно отбросить. То есть, чем важнее пакет для работоспособности сети, тем выше его класс сервиса при посылке на CPU. Именно поэтому видеть в пинге или трассировке варьирующиеся задержки на транзитных хопах — это нормально — ICMP — не приоритетный для CPU трафик.
Кроме того, на протокольные пакеты применяется CoPP — Control Plane Protection (или Policing) — ограничение скорости во избежание высокой загрузки CPU — опять же, лучше предсказуемые отбрасывания в низкоприоритетных очередях до того, как начались проблемы.
CoPP поможет и от целенаправленного DoS и от аномального поведения сети (например, петли), когда на устройство начинает приходить много широковещательного трафика.

---

Полезные ссылки

• Лучшая книга по теории и философии QoS: QOS-Enabled Networks: Tools and Foundations.
  Некоторые отрывки из неё можно почитать тут, однако я бы рекомендовал читать её от и до, не размениваясь.
• На удивление обстоятельная и хорошо написанная книга про QoS от Huawei: Special Edition QoS(v6.0). Очень плотно разбирается архитектура оборудования и работа PHB на разных платах.
• Очень подробное сравнение sr-TCM и tr-TCM от Айни: Understanding Single-Rate and Dual-Rate Traffic Policing.
• Про VOQ: What is VOQ and why you should care?
• Про QoS в MPLS: MPLS and Quality of Service.
• Относительно краткий бриф по QoS на примере Juniper: Juniper CoS notes.
• Практически весь QoS так или иначе ориентирован на специфику TCP и UDP. Не лишним будет досконально разобраться в них: The TCP/IP Guide
• Ну а для тех, кто не чувствует в себе силы одолеть весь этот труд, Лохматый Мамонт для вас написал отдельную заметку: В поисках утерянного гигабита или немного про окна в TCP.
• На этой странице сложно, но подробно описано как работают механизмы группы FQ: Queuing and Scheduling.
  А если подняться на уровень выше, то откроется масштабный открытый документ, называющийся An Introduction to Computer Networks, вгоняющий краску, потому что настолько мощный Introduction, что я там половину не знаю. Даже самому захотелось почитать.
• Про WFQ очень научно, но при должно интеллекте, коим, очевидно, я не обладаю, понятно и в цветах: Weighted Fair Queueing: a packetized approximation for FFS/GP.
• Есть ещё механизм LFI, который я затрагивать не стал, потому что сложно и в наших реалиях стогигиабитных интерфейсов не очень актуально, однако ознакомиться может быть интересно: Link Fragmentation and Interleaving.

Заключение

У этого выпуска было много рецензентов.
Спасибо.
Александру Фатину (LoxmatiyMamont) за вводное слово и ценные советы по выразительности и доходчивости текста.
Александру Клипперу (@metallicat20) за экспертную оценку.
Александру Клименко (@v00lk) за суровую критику и самые массивные изменения в последние дни.
Андрею Глазкову (@glazgoo) за замечания по структуре, терминологии и за запятые.
Артёму Чернобаю за КДПВ.
Антону Клочкову (@NAT_GTX) за контакты с Миран.
Миран (miran.ru) за организацию сервера с Евой и трансляцией. Традиционно моей семье, которая впрочем в этот раз наименее всего пострадала ввиду её отсутствия рядом в самые тяжёлые моменты.