Dscp что это в роутере

СДСМ-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) за организацию сервера с Евой и трансляцией. Традиционно моей семье, которая впрочем в этот раз наименее всего пострадала ввиду её отсутствия рядом в самые тяжёлые моменты.

Introduction

This document describes how to set the Differentiated Services Code Point (DSCP) values in Quality of Service (QoS) configurations on a Cisco router.

Prerequisites

Requirements

You must be familiar with the fields in the IP header and Cisco IOS^®CLI.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to Cisco Technical Tips Conventions.

Background Information

Differentiated Services (DiffServ) is a new model in which traffic is treated by intermediate systems with relative priorities based on the type of services (ToS) field. Defined inRFC 2474and RFC 2475, the DiffServ standard supersedes the original specification to define packet priority described in RFC 791. DiffServ increases the number of definable priority levels when it reallocates bits of an IP packet to mark it as a priority.

The DiffServ architecture defines the DiffServ (DS) field, which supersedes the ToS field in IPv4 to make per-hop behavior (PHB) decisions about packet classification and traffic conditioning functions, such as metering , marking , shaping , and policing .

The RFCs do not dictate the way to implement PHBs; this is the responsibility of the vendor. Cisco implements queuing  techniques that can base their PHB on the IP precedence or DSCP value in the IP header of a packet. Based on DSCP or IP precedence, traffic can be put into a particular service class. Packets within a service class are treated the same way.

Differentiated Services Code Point

The six most significant bits of the DiffServ field is called as the DSCP. The last two Currently Unused (CU) bits in the DiffServ field were not defined within the DiffServ field architecture; these are now used as Explicit Congestion Notification (ECN) bits. Routers at the edge of the network classify packets and mark them with either the IP Precedence or DSCP value in a Diffserv network. Other network devices in the core that support Diffserv use the DSCP value in the IP header to select a PHB behavior for the packet and provide the appropriate QoS treatment.

The diagrams in this section show a comparison between the ToS byte defined by RFC 791 and the DiffServ field.

ToS Byte

P2

P1

P0

T2

T1

T0

CU1

CU0

• IP precedence—three bits (P2 to P0)

• Delay, Throughput and Reliability—three bits (T2 to T0)

• CU (Currently Unused)—two bits(CU1-CU0)

DiffServ Field

DS5	DS4	DS3	DS2	DS1	DS0	ECN	ECN

• DSCP—six bits (DS5-DS0)

• ECN—two bits

The standardized DiffServ field of the packet is marked with a value so that the packet receives a particular forwarding treatment or PHB, at each network node.

The default DSCP is 000 000. Class selector DSCPs are values that are backward compatible with IP precedence. When you convert between IP precedence and DSCP, match the three most significant bits. In other words:

IP Prec 5 (101) maps to IP DSCP 101 000

ToS Byte

1

0

1

T2

T1

T0

CU2

CU0

DiffServ Field

1	0	1	0	0	0	ECN	ECN

The DiffServ standard utilizes the same precedence bits (the most significant bits—DS5, DS4 and DS3) for priority setting, but further clarifies the definitions, which provides finer granularity through the use of the next three bits in the DSCP. DiffServ reorganizes and renames the precedence levels (still defined by the three most significant bits of the DSCP) into these categories (the levels are explained in greater detail in this document):

Precedence Level	Description
7	Stays the same (link layer and routing protocol keep alive)
6	Stays the same (used for IP routing protocols)
5	Express Forwarding (EF)
4	Class 4
3	Class 3
2	Class 2
1	Class 1
0	Best effort

With this system, a device prioritizes traffic by class first. Then it differentiates and prioritizes same-class traffic, and takes the drop probability into account.

The DiffServ standard does not specify a precise definition of «low,» «medium,» and «high» drop probability. Not all devices recognize the DiffServ (DS2 and DS1) settings; and even when these settings are recognized, they do not necessarily trigger the same PHB forwarding action at each network node. Each node implements its own response based on how it is configured.

Assured Forwarding

RFC 2597 defines the assured forwarding (AF) PHB and describes it as a means for a provider DS domain to offer different levels of forwarding  assurances for IP packets received from a client DS domain. The Assured Forwarding  PHB guarantees a certain amount of bandwidth to an AF class and allows access to extra bandwidth, if available. There are four AF classes, AF1x through AF4x. Within each class, there are three drop probabilities. Contingent on a given network policy, packets can be selected for a PHB based on required throughput, delay, jitter, loss, or by priority of access to network services.

Classes 1 to 4 are referred to as AF classes. This table illustrates the DSCP code that specifies the AF class with the probability. Bits DS5, DS4 and DS3 define the class; bits DS2 and DS1 specify the drop probability; bit DS0 is always zero.

Drop	Class 1	Class 2	Class 3	Class 4
Low	001010 AF11 DSCP 10	010010 AF21 DSCP 18	011010 AF31 DSCP 26	100010 AF41 DSCP 34
Medium	001100 AF12 DSCP 12	010100 AF 22 DSCP 20	011100 AF32 DSCP 28	100100 AF42 DSCP 36
High	001110 AF13 DSCP 14	010110 AF23 DSCP 22	011110 AF33 DSCP 30	100110 AF43 DSCP 38

Expedited Forwarding

RFC 2598 defines the Expedited Forwarding (EF) PHB: «The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS (Diffserv) domains. Such a service appears to the endpoints like a point-to-point connection or a «virtual leased line.» This service has also been described as Premium service. Codepoint 101110 is recommended for the EF PHB, which corresponds to a DSCP value of 46.

Again, vendor-specific mechanisms need to be configured to implement these PHBs. Refer to RFC 2598 for more information about EF PHB.

Use the DSCP Field

There are three ways you can use the DSCP field:

• Classifier—Select a packet based on the contents of some portions of the packet header and apply PHB based on service characteristic defined by the DSCP value.

• Marker—Set the DSCP field based on the traffic profile.

• Metering —Check compliance to traffic profile with either a shaper or dropper function.

Cisco IOS software considers the precedence bits of the ToS field if there is traffic that is queued in Weighted Fair Queuing (WFQ), Weighted Random Early Detection (WRED) or Weighted Round Robin (WRR). The precedence bits are not considered when Policy Routing, Priority Queuing (PQ), Custom Queuing (CQ), or Class Based Weighted Fair Queuing (CBWFQ) are configured. For more information, see Class Based Weighted Fair Queuing (CBWFQ).

Packet Classification

Packet classification involves the use of a traffic descriptor to categorize a packet within a specific group and to make the packet accessible for the QoS that manages in the network. When you use packet classification, you can partition network traffic into multiple priority levels or a class of service (CoS).

You can use either access lists (ACLs) or the match command in the modular QoS CLI to match on DSCP values. The Cisco IOS Software Release 12.1(5)T introduced the ability to select a DSCP value in the match command.

Router1(config)#access-list 101 permit ip any any ?
dscp       Match packets with given dscp value 
fragments  Check non-initial fragments 
log        Log matches against this entry 
log-input  Log matches against this entry, including input interface 
precedence Match packets with given precedence value 
time-range Specify a time-range 
tos        Match packets with given TOS value

When you specify the ip dscp value in the class map command, you have these:

Router(config)#class-map match-all VOIP 
 1751-uut1(config-cmap)#match ip dscp ? 
   <0-63>   Differentiated services codepoint value 
   af11     Match packets with AF11 dscp (001010) 
   af12     Match packets with AF12 dscp (001100) 
   af13     Match packets with AF13 dscp (001110) 
   af21     Match packets with AF21 dscp (010010) 
   af22     Match packets with AF22 dscp (010100) 
   af23     Match packets with AF23 dscp (010110) 
   af31     Match packets with AF31 dscp (011010) 
   af32     Match packets with AF32 dscp (011100) 
   af33     Match packets with AF33 dscp (011110) 
   af41     Match packets with AF41 dscp (100010) 
   af42     Match packets with AF42 dscp (100100) 
   af43     Match packets with AF43 dscp (100110) 
   cs1      Match packets with CS1(precedence 1) dscp (001000) 
   cs2      Match packets with CS2(precedence 2) dscp (010000) 
   cs3      Match packets with CS3(precedence 3) dscp (011000) 
   cs4      Match packets with CS4(precedence 4) dscp (100000) 
   cs5      Match packets with CS5(precedence 5) dscp (101000) 
   cs6      Match packets with CS6(precedence 6) dscp (110000) 
   cs7      Match packets with CS7(precedence 7) dscp (111000) 
   default  Match packets with default dscp (000000) 
   ef       Match packets with EF dscp (101110) 
 Router1(config-cmap)#match ip dscp af31 

Marking

The DSCP can be set to a desired value at the edge of the network in order to make it easy for core devices to classify the packet as shown in the Packet Classification section and provide a suitable level of service. Class-Based Packet Marking can be used to set the DSCP value as shown here:

policy-map pack-multimedia-5M 

!--- Creates a policy map named pack-multimedia-5M.

  class management 
  
!--- Specifies the policy to be created for the !--- traffic classified by class management.

    bandwidth 50 
    set ip dscp 8 
    
!--- Sets the DSCP value of the packets matching !--- class management to 8.

  class C1 
    priority 1248 
    set ip dscp 40 
  class voice-signalling 
    bandwidth 120 
    set ip dscp 24

Use Committed Access Rate or Class-Based Policing

Committed Access Rate and Class-Based Policing are traffic regulation mechanisms, used to regulate traffic flow to conform with the agreed upon service parameters. These mechanisms along with DSCP can be used to provide different levels of service that do not and do conform to traffic when it appropriately modifies the DSCP value, as shown in this section.

Refer to Configuring Traffic Policing  and Comparing Class-Based Policing and Committed Access Rate for more information.

interface Serial1/0.1 point-to-point 
 bandwidth 5000 
 ip address 192.168.126.134 255.255.255.252 
rate-limit output access-group 150 8000 1500 2000 conform-action 
  set-dscp-transmit 10 exceed-action set-dscp-transmit 20 

!--- For traffic matching access list 150, sets the DSCP value of conforming traffic !--– to 10 and that of non-conforming traffic to 20.

rate-limit output access-group 152 8000 1500 2000 conform-action 
  set-dscp-transmit 15 exceed-action set-dscp-transmit 25 
rate-limit output access-group 154 8000 1500 2000 conform-action 
  set-dscp-transmit 18 exceed-action set-dscp-transmit 28 
frame-relay interface-dlci 17 
class shaper-multimedia-5M

DSCP-Compliant WRED

Weighted Random Early Detection (WRED), selectively discards lower-priority traffic when the interface begins to get congested. WRED can provide differentiated performance characteristics for different CoS. This differentiated service can be on basis of the DSCP, as shown here:

class C2 
 bandwidth 1750 
 random-detect dscp-based 
    
!--- Enable dscp-based WRED as drop policy.

 random-detect exponential-weighting-constant 7 
    
!--- Specifies the exponential weight factor for the !--- average queue size calculation for the queue.
  
 random-detect dscp 16 48 145 10 
    
!--- Specifies the minimum and maximum queue thresholds !--- for each DSCP value.

 random-detect dscp 32 145 435 10

Refer to theDiffServ Compliant WREDsection of Congestion Avoidance Overview for more information.

Known Issues in Cisco IOS Software 12.2 Release Trains

Access to Bug tools and information is only available for registered Cisco clients.

You can search for these bugs with the Bug Search Tool.

• Cisco bug ID CSCdt63295  — If you fail to set the ToS byte with the new DSCP marking commands on the dial peers (set to 0) in Cisco IOS Software Release 12.2.2T, then packets cannot be marked and they can remain with a ToS set to 0.

• Cisco bug ID CSCdt74738 — Support for the set ip dscp command on the Cisco 7200 router and lower-end platforms for the for multicast packets must be available as of Cisco IOS Software Release 12.2(3.6) and later.

Related Information

• Cisco IOS Software: Service Provider Network Solutions
• Technical Support — Cisco Systems
• QoS: Congestion Avoidance Configuration Guide

Что такое ToS, DSCP, CoS, QoS

Добавил(а) microsin
  

Для начала расшифруем аббревиатуры. ToS означает Type of Service, DSCP — Differenciated Services Code Point, CoS — Class of Service, QoS — Quality of Service.

Термин QoS объединяет три термина ToS, DSCP, CoS. QoS — Quality of Service (качество обслуживания) выражается в построении и обработке очереди пакетов с разным приоритетом по одному из алгоритмов DWRED (Distributed Weighted Random Early Detection), WFQ (weighted fair queueing), CAR (Committed Access Rate).

Аббревиатуры ToS и DSCP родственны — используются для обозначения специального байта данных стандартного заголовка IP-пакета. Этот байт несет информацию о приоритете трафика, который в бизнес-трафике обычно назначается для пакетов IP-телефонии (третий сетевой уровень L3). Поскольку этот один и тот же байт иногда интерпретируется по-разному (либо как ToS байт, либо как DS/DSCP байт), получается некоторая путаница, хотя смысл и принцип технологии приоритезации не меняется — пакеты, помеченные более высоким приоритетом, передаются быстрее (менее приоритетные становятся в очередь). Накладывание на пакеты битов приоритета еще называют «маркированием» трафика, и чтобы приоритезация действительно работала, на всем пути прохождения трафика биты приоритета должны быть проанализированы и обработаны на активном сетевом оборудовании (настраиваемые роутеры и коммутаторы). На рисунке показано расположение бит байта маркировки трафика (красным помечена наиболее важная, серым — неиспользуемая часть).

IP Precedence Value

Уровень	Имя
0	routine
1	priority
2	immediate
3	flash
4	flash-override
5	critical
6	internet
7	network

Когда используют терминологию DSCP, имеются в виду 6 старших бит DS5..DS0, где DS5..DS3 кодируют уровень класса обслуживания от 0 (минимальный приоритет) до 7 (максимальный приоритет) и приоритет удаления (от 0, когда приоритет удаления максимальный, до 7, когда приоритет удаления минимальный — кодирование приоритета удаления “обратное”). В итоге получается число от 0 до 63, кодирующее приоритет (чем больше число, тем трафик важнее). Такое многоуровневое кодирование приоритета часто оказывается избыточным, и поэтому используются только биты DS5..DS3. При IP-телефонии применяется класс сервиса 5 (DS-байт равен 0xA0 или 10100000b), а для обычного трафика класс сервиса 0 (DS-байт равен 0x00 или 00000000b). Сравните с ToS — изменилась только терминология, а значение байта передается то же самое.

Буквенные мнемонические коды величины DSCP можно посмотреть командой:
Router(config)# class-map match-all VOIP
 1751-uut1(config-cmap)# match ip dscp ?
   <0-63>  Differentiated services codepoint value
   af11    Match packets with AF11 dscp (001010)
   af12    Match packets with AF12 dscp (001100)
   af13    Match packets with AF13 dscp (001110)
   af21    Match packets with AF21 dscp (010010)
   af22    Match packets with AF22 dscp (010100)
   af23    Match packets with AF23 dscp (010110)
   af31    Match packets with AF31 dscp (011010)
   af32    Match packets with AF32 dscp (011100)
   af33    Match packets with AF33 dscp (011110)
   af41    Match packets with AF41 dscp (100010)
   af42    Match packets with AF42 dscp (100100)
   af43    Match packets with AF43 dscp (100110)
   cs1     Match packets with CS1(precedence 1) dscp (001000)
   cs2     Match packets with CS2(precedence 2) dscp (010000)
   cs3     Match packets with CS3(precedence 3) dscp (011000)
   cs4     Match packets with CS4(precedence 4) dscp (100000)
   cs5     Match packets with CS5(precedence 5) dscp (101000)
   cs6     Match packets with CS6(precedence 6) dscp (110000)
   cs7     Match packets with CS7(precedence 7) dscp (111000)
   default Match packets with default dscp (000000)
   ef       Match packets with EF dscp (101110)
 Router1(config-cmap)# match ip dscp af31

Эти коды используются также при назначении трафику маркировки, при конфигурировании policy-map:
!создается карта политики Police-GE0/1
policy-map Police-GE0/1
  class Voice-GE0/1
  priority 5000
  set dscp ef
  class Route-GE0/1
  set dscp cs6
  priority 1000
  class Signal-GE0/1
  set dscp cs3
  priority 4500
  class class-default
  fair-queue

Когда используется термин CoS, то обычно имеется в виду перенос информации о приоритете на втором сетевом уровне L2 (MAC-адреса). При этом для кодирования приоритета используются 3 бита (получаются уровни от 0 до 7). Расположение этих бит в потоке данных зависит типа магистрального канала L2.

From Wikipedia, the free encyclopedia

The type of service (ToS) field is the second byte of the IPv4 header. It has had various purposes over the years, and has been defined in different ways by five RFCs.^[1]

Prior to the redefinition, the ToS field could specify a datagram’s priority and request a route for low-latency, high-throughput, or highly-reliable service.
Based on these ToS values, a packet would be placed in a prioritized outgoing queue,^[2] or take a route with appropriate latency, throughput, or reliability. In practice, the ToS field never saw widespread use outside of US Department of Defense networks. However, a great deal of experimental, research, and deployment work has focused on how to make use of these eight bits, resulting in the current DS field definition.

The modern redefinition of the ToS field, also used for the Traffic Class field in IPv6 packets, is an 8-bit differentiated services field (DS field) which consists of a 6-bit Differentiated Services Code Point (DSCP) field^[3] and a 2-bit Explicit Congestion Notification (ECN) field.^[4] While Differentiated Services is somewhat backwards compatible with ToS, ECN is not.

History[edit]

The Type of Service field in the IP header was originally defined in RFC 791, and has been interpreted for IP Precedence and ToS ever since. The definition was largely derived from a US DoD Specification JANAP-128, which defines message precedence. It defined a mechanism for assigning a precedence to each IP packet, as well as a mechanism to request specific treatment such as high throughput, high reliability or low latency, etc. In the RFC 1349 update, the Monetary Cost bit is introduced (this bit was previously marked «Reserved for Future Use»). Section 2.4 of RFC 1583 (OSPFv2) introduces a ToS-aware routing method.

In practice, only the IP Precedence part of the field was ever used outside US DoD networks: the higher the value of the IP Precedence field, the higher the priority of the IP packet. Some US DoD networks did use the delay bit for route selection between oceanic cable paths and Satellite Communication (SATCOM) paths when both paths existed. IPv6 has never had an IPv4-like «traditional» ToS field, partially because the authors were aware of DiffServ efforts at its drafting (RFC 2460 Section 7).

In RFC 2474 the definition of this entire field was changed. It is now called the «DS» (Differentiated Services, «DiffServ») field and the upper 6 bits contain a value called the «DSCP» (Differentiated Services Code Point). The upper 3 bits of DS maintains compatibility with IP Precedence. Since RFC 3168, the remaining two bits (the two least significant bits) are used for Explicit Congestion Notification.

RFC 8622 added lower-effort (LE) DS for traffic that may be pre-empted by other traffic (best-effort traffic). It is intended for background traffic of low precedence, such as bulk data transfers with low priority in time.

Allocation[edit]

Precedence and ToS[edit]

Prior to its deprecation, the Type of Service field was defined as follows from RFC 791:

7	6	5	4	3	2	1	0
Precedence	Type of Service	Unused (0)

Precedence was a 3 bit field which treats high priority packets as more important than other packets. If a router is congested and needs to discard some packets, it will discard packets having lowest priority first. Although precedence field was part of IP version 4, it was never used.

RFC 1349 introduced an additional «lowcost» field. The four available ToS bits now becomes:

7	6	5	4	3	2	1	0
(IP Precedence)	lowdelay	throughput	reliability	lowcost (RFC 1349)	(Must be zero)

The naming here follows the convention of Unix operating systems.^[5] RFC 1349 and RFC 1060 only show examples of one bit used at a time for application-default values, although RFC 791 mentions that at most two of the three indications it has should be set nominally. One such use is known from mod_iptos.^[6]

Because the last three bits went through many definitions prior to RFC 2474 (see below), documentation and implementations may be confusing and contradictory.

DSCP and ECN[edit]

RFC 2474 (which was released in December 1998) reserved the first six bits of the DS (or IPv4 ToS) field for the Differentiated Services Code Point (DSCP), and RFC 3168 reserved the last two bits for Explicit Congestion Notification.

7	6	5	4	3	2	1	0
DSCP	ECN

DSCP defines a Class Selector (CS) naming to each value it defines, mirroring what would have been interpreted as the IP Precedence if one follows the older specification:

DSCP/IP Precedence Conversion Table

DSCP Name	DS Field Value (Dec)	IP Precedence (Description)
CS0	0	0: Best Effort
LE	1	n/a
CS1, AF11-13	8,10,12,14	1: Priority
CS2, AF21-23	16,18,20,22	2: Immediate
CS3, AF31-33	24,26,28,30	3: Flash — mainly used for voice signaling
CS4, AF41-43	32,34,36,38	4: Flash Override
CS5, EF	40,46	5: Critical — mainly used for voice RTP
CS6	48	6: Internetwork Control
CS7	56	7: Network Control

DSCP Nomenclature:

CS

Class Selector (RFC 2474)

AFxy

Assured Forwarding (x=class, y=drop precedence) (RFC 2597)

EF

Expedited Forwarding (RFC 3246)

LE

Lower-Effort (RFC 8622)

The above table, with individual values written out for values of the entire ToS field (not to be confused with the little-used 5-bit part):

DSCP/ToS/IP Precedence Conversion Table

DSCP Dec	ToS value	IP Prec
0	0	0
8	32	1
10	40	1
14	56	1
18	72	2
22	88	2
24	96	3
28	112	3
34	136	4
36	144	4
38	152	4
40	160	5
46	184	5
48	192	6
56	224	7

Note: In the above table, ToS is shown in decimal format. However, many routers express ToS in hex format.

Example: mixed interpretation[edit]

Let’s start with an IP priority of 1, or 0b001 in Binary. The entire ToS field would then be 001 00000, assuming that the unused 5 bits are zero. The DSCP can be interpreted by resegmenting to 001000 00, where 001000 = 8 is the DSCP value.

Software support[edit]

Although not frequently used, IP ToS definitions are widely found in netinet/ip.h of Unix-like or Unix operating systems as IPTOS_FIELDNAME macros.^[5] The «lowcost» field is commented out in OpenBSD due to its newer use for indicating ECN support.^[5] Remnants of the old RFC 1349 terminology can be found in Transmission 2.93^[7] as well as other tools that support setting this field.

An old Apache module «mod_iptos», once packaged in Ubuntu, notes that a way to use multiple RFC 1349 option bits together emerged after some point.^[6]

See also[edit]

• Class of service
• Quality of service
• Explicit Congestion Notification

References[edit]

Further reading[edit]

• John Evans, Clarence Filsfils (2007). Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice. Morgan Kaufmann. ISBN 978-0123705495.

External links[edit]

• Linux Advanced Routing & Traffic Control. How to set ToS byte via IPChains
• Simple Traffic Queueing by ToS values

2014-06-01 (updated: 2020-06-15) by

This article explains in detail the different commonly used network QoS packet prioritization methods. It should be noted that QoS and ToS/DSCP across the internet is not a 100% reliable means.  Internet Service Providers (ISPs) do not have to honor client DSCP markups, they can, and many do reclassify traffic by remarking ToS/DSCP bits in packets.

Quality of Service (QoS)

In general, QoS defines standard ways to prioritize traffic in a network where different types of packets should be assigned different priorities, based on their type. It is often used to classify VoIP, SIP, Video Streaming, gaming, and other types of priority traffic to improve user experience. By implementing QoS policies, network administrators can use existing resources more efficiently to ensure the required level of service for critical applications without over-provisioning networks.

Traditionally, when there is no set QoS policy, all network traffic is treated equally using the network’s «best effort», with no guarantees for reliability, delay, throughput, or any other performance characteristics. With this type of best-effort delivery, any bandwidth-intensive application can use the majority of the network capacity, causing unacceptable or poor performance for all other time-critical applications. The QoS model, on the other hand allows for prioritizing some type of traffic (VoIP, gaming, etc.), or some users, to be treated with higher priority. There are also mechanisms that allow for prioritizing and shaping different types of traffic in a different way (high throughput vs. low delay, for example).

The goal of QoS is to provide preferential delivery to mission-critical and time-sensitive applications by controlling four main network characteristics:

bandwidth — throughput
latency — delay, rtt, ping
jitter — variation in latency
reliability — the percentage of packets discarded by the router

Latency and jitter are important for voice communications, and gaming for example, while bandwidth and reliability are important for bulk transfers.

QoS depends on support throughout the network — all devices from the sender network adapter, routers, and all the way to the receiving end must support QoS mechanisms. It is sometimes helpful to use QoS policies on a local network, however, to be able to pass QoS tagged packets through an ISP is not always possible, as it may conflict with their QoS policies. Many residential ISPs can ignore (or zero out) QoS/ToS/DSCP tagging in packets.

The SG TCP Analyzer can detect and display ToS/DSCP tagged packets, it can be used to determine whether the desired tagging is able to pass all the way to our server.

The sections below explain the different standard ways of marking packets with different priorities. The ToS/DSCP field is a part of IP packet headers used to classify and prioritize different types of traffic.

IP Type of Service (ToS)

The Type of Service (TOS) field in IP packet headers defines how packets should be routed, e.g. delay, precedence, reliability, etc. This ToS field is now redefined and more commonly used by Differentiated Services, a.k.a. the Diffserv Code Point (DSCP).

The TOS field consists of 8 bits that mark packets as follows:

Precedence (3 bits)	Delay (1 bit)	Throughput (1 bit)	Reliability (1 bit)	Cost (1 bit)	MBZ check bit (1 bit)
000 (0) — Routine (best effort, default) 001 (1) — Priority 010 (2) — Immediate 011 (3) — Flash 100 (4) — Flash Override 101 (5) — Critical 110 (6) — Internetwork Control 111 (7) — Network Control	0 — normal 1 — low delay	0 — normal 1 — high throughput	0 — normal 1 — high reliability	0 — normal 1 — low cost	should be zero

Type of Service is described in RFC 791 and RFC 1583. The newer Differentiated Services Code Point (DSCP) variant consists of the first 6 bits, and the last two are left unused (or used for explicit congestion notification — ECN).

Notes:  The TOS Precedence field is also detailed in 802.1p/802.1q, Layer 2 Class of Service (CoS). Layer 2 switches can use the Class of Service (CoS) values of packets to classify them and put them into appropriate queues.

0 (BK) — Background traffic
1 (BE) — Best Effort
2 (EE) — Excellent Effort
3 (CA) — Critical Applications
4 (VI) — Video, 5 (VO) — Voice, 6 (IC) — Internetwork Control
7 (NC) — Network Control

Differentiated Services Code Point (DSCP)

DiffServ/DSCP uses the first 6 bits of the above ToS field, giving 2^6 = 64 different possible values. It leaves the remaining two bits available for use by Explicit Congestion Notification (ECN). In practice, not all 64 different traffic classes are used. Most networks use the following commonly defined per-hop behaviors (PHBs):

Default PHB (per hop behavior) — typically best effort traffic, the default behavior for all traffic that does not fit any other defined class. DSCP is 000000 (0).

Expedited Forwarding (EF) [RFC 3246] — low-loss, low-latency, low-jitter traffic, suitable for voice, video and other real time services. EF is often given strict priority queuing above all other traffic classes. Typical networks will limit EF traffic to no more than 20-30% of the capacity of a link. The recommended DSCP for EF is 101110 (46).

Voice Admit (VA) [RFC 5865] — low loss, low-latency, low-jitter traffic. Newer standard with identical characteristics to Expedited Forwarding (EF), with added Call Admission Control (CAC) by the network to prevent congestion. Recommended DHCP for VA is 101100 (44).

Assured Forwarding (AF) [RFC 2597, RFC 3260] — gives assurance of delivery under prescribed conditions. AF allows the operator to provide assurance of delivery as long as the traffic does not exceed some subscribed rate. Traffic that exceeds the subscription rate faces a higher probability of being dropped if congestion occurs. The AF behavior group defines four separate AF classes, where higher classes often (but not always) have higher priority. Within each class, packets are given a «drop precedence» of high, medium or low (where higher precedence means more dropped packets). The combination of classes and drop precedence allows for twelve separate DSCP encodings from AF11 through AF43 as follows:

	Class 1	Class 2	Class 3	Class 4
low drop	AF11 (DSCP 10)	AF21 (DSCP 18)	AF31 (DSCP 26)	AF41 (DSCP 34)
medium drop	AF12 (DSCP 12)	AF22 (DSCP 20)	AF32 (DSCP 28)	AF42 (DSCP 36)
high drop	AF13 (DSCP 14)	AF23 (DSCP 22)	AF33 (DSCP 30)	AF43 (DSCP 38)

Note from the above table that within the same class, higher DSCP numbers may have lower priority (higher packet drops). For example, DSCP 34 will take precedence with less packet loss over DSCP 38.

Class Slectors (CS) — maintains backward compatibility with the IP precedence field (the IP TOS value, as described above). The CS code points are of the form «nnn 000» where the first three bits are the IP precedence bits, and the remaining three are zeroes. Each IP precedence value can be mapped into a DiffServ class. If a packet is received from a non-DiffServ router that used IP TOS markings, the DiffServ router can still understand the encoding as a Class Selector code point.  CS codepoint values are as follows:

DSCP	Binary	Decimal
CS0	000 000	0
CS1	001 000	8
CS2	010 000	16
CS3	011 000	24
CS4	100 000	32
CS5	101 000	40
CS6	110 000	48
CS7	111 000	56

The table below combines all the above PHB methods in a single table that lists all common DSCP field values. The DSCP value in the IP header is used to select appropriate QoS treatment for packets.

DSCP, DiffServ and ToS values

DSCP Name	DSCP Binary	DSCP Decimal	IP Precedence	ToS Hex	ToS Decimal	Notes
CS0	000 000	0	000 (0) — best effort	0x00	0
CS1	001 000	8	001 (1) — priority	0x20	32	CS1 has lower wireless priority than zero with WMM
AF11	001 010	10	001 (1) — priority	0x28	40
AF12	001 100	12	001 (1) — priority	0x30	48
AF13	001 110	14	001 (1) — priority	0x38	56
CS2	010 000	16	010 (2) — immediate	0x40	64
AF21	010 010	18	010 (2) — immediate	0x48	72
AF22	010 100	20	010 (2) — immediate	0x50	80
AF23	010 110	22	010 (2) — immediate	0x58	88
CS3	011 000	24	011 (3) — flash	0x60	96
AF31	011 010	26	011 (3) — flash	0x68	104	call signalling RFC 2597
AF32	011 100	28	011 (3) — flash	0x70	112
AF33	011 110	30	011 (3) — flash	0x78	120
CS4	100 000	32	100 (4) — flash override	0x80	128
AF41	100 010	34	100 (4) — flash override	0x88	136	Video RFC 4594
AF42	100 100	36	100 (4) — flash override	0x90	144
AF43	100 110	38	100 (4) — flash override	0x98	152
CS5	101 000	40	101 (5) — critical	0xa0	160	call signaling RFC 4594
VA	101 100	44	101 (5) — critical	0xb0	176	Voice Admit (VA) RFC 5865
EF	101 110	46	101 (5) — critical	0xb8	184	Expedited Forwarding (EF) Audio RFC 3246, RFC 4594
CS6	110 000	48	110 (6) — internetwork control	0xc0	192
CS7	111 000	56	111 (7) — network control	0xe0	224

CS = Class Selector
AF = Assured Forwarding
EF = Expedited Forwarding

Notes:
The IP Precedence fields in the above table are listed in decimal notation, refer to the ToS section for the corresponding binary values.
The DiffServ Code Point (DSCP) is described in RFC 2474
With Assured Forwarding (AF), higher DSCP is not always better (higher class with lower drop precedence is better).

How to Apply DSCP under Windows 7/8/10

QoS Policy

QoS Policy settings under Windows 7/8/10 can be edited using Powershell cmdlets, or the Group Policy Editor (gpedit.msc): Computer Configuration -> Windows Settings -> Policy-based QoS

In order to define DiffServ (DSCP) values, according to Microsoft the machine needs to have joined a domain, and interfaces have to see the domain controller. To overcome this limitation, so that you can tag DSCP values even for adapters that do not have access to a domain, use the following hidden registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\QoS (you may have to create the QoS key)
«Do not use NLA»=»1» (REG_SZ string value, not DWORD, not present by default, recommended: 1 if you plan to edit DSCP values via gpedit.msc)

Note: This registry key may also be needed in systems with multiple network adapters present. Rebooting after setting the value is required.

PowerShell Cmdlet to change DSCP values

In Windows 10, 8, and Server 2012 it is possible to use PowerShell to configure the DSCP values with the NetQosPolicy Cmdlet. Below are a few examples of setting the DSCP value for an app called «MyApp»:

New-NetQosPolicy -Name «MyApp HTTP» -DSCPAction 26 -NetworkProfile All -AppPathNameMatchCondition «%programfiles(x86)%\MyAppFolder\MyApp.exe» -IPProtocolMatchCondition TCP -IPDstPortMatchCondition 80
New-NetQosPolicy -Name «MyApp Audio RTP» -DSCPAction 46 -NetworkProfile All -AppPathNameMatchCondition «%programfiles(x86)%\MyAppFolder\MyApp.exe» -IPProtocolMatchCondition UDP -IPSrcPortStartMatchCondition 2050 -IPSrcPortEndMatchCondition 3000
New-NetQosPolicy -Name «MyApp Video RTP» -DSCPAction 34 -NetworkProfile All -AppPathNameMatchCondition «%programfiles(x86)%\MyAppFolder\MyApp.exe» -IPProtocolMatchCondition UDP -IPSrcPortStartMatchCondition 50000 -IPSrcPortEndMatchCondition 50100
New-NetQosPolicy -Name «MyApp Signalling H323/TLS» -DSCPAction 26 -NetworkProfile All -AppPathNameMatchCondition «%programfiles(x86)%\MyAppFolder\MyApp.exe» -IPProtocolMatchCondition TCP -IPDstPortMatchCondition 1300

In the above examples, the «-DSCPAction …» parameter determines the DSCP value, and the «IPProtocolMatchCondition» defines the protocol and port number. Note that for a range of ports, you’d have to use «IPSrcPortStartMatchCondition» and «IPSrcPortEndMatchCondition».

Notes: QoS policies added via PowerShell are not visible in the Group Policies Editor.

Group Policies Editor (gpedit.msc)

To enter a DSCP value using local group policy:

1. Click the start button, type: gpedit.msc

2. In the left pane, navigate to: Computer Configuration -> Windows Settings -> Policy-based QoS

3. Right-click on Policy-based Qos and choose «Create a new Policy» -> add name -> enter appropriate decimal number between 0-56 for DSCP, use the above tables for reference -> click Next -> All applications / All source IPs / All destination IPs -> Select both TCP and UDP, From any source port / To any destination port -> Finish

Notes:
gpedit.msc is only available in the professional/ultimate Windows variants, not in Home editions.
To apply changes without rebooting, you can run the following in command prompt:  gpupdate /force

To manually edit an existing policy in the registry, see:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\
DiffservByteMappingConforming\
ServiceTypeBestEffort=26
ServiceTypeControlledLoad
ServiceTypeGuaranteed HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\Psched\
DiffservByteMappingConforming\
ServiceTypeBestEffort=26

See Also:
IEEE 802.1p (802.1q) value — QoS at the MAC level allowing values of 0 through 7.
gpedit.msc -> Administrative Templates -> Network -> QoS Packet Scheduler -> DSCP value of conforming packets / DSCP value of non-conforming packets.

For MS Communicator 2007, OSC, see also:
HKEY_LOCAL_MACHINE\Software\Microsoft\RTC\Transport\QoSEnabled=1
HKEY_LOCAL_MACHINE\Software\WoW6432Node\Microsoft\RTC\Transport\QoSEnabled=1

Hierarchical Token Bucket (HTB)

Some linux-based NAT routers use HTB to schedule packets. The HTB is a traffic shaping QoS packet scheduling algorithm included in stock Linux kernels since 2.4.20.  It allows for traffic shaping in linux-based NAT routers as well, here is an example of DSCP based QoS with HTB in MikroTik devices:

Traffic Type	Precedence	DSCP Range	HTB Priority
Routine (default)	000 (0)	000000(0) – 000111 (7)	8
Priority	001 (1)	001000 (8) – 001111 (15)	7
Immediate	010 (2)	010000 (16) – 010111 (23)	6
Flash	011 (3)	011000 (24) – 011111 (31)	5
Flash Override	100 (4)	100000 (32) – 100111 (39)	4
Critical	101 (5)	101000 (40) – 101111 (47)	3
Internetwork Control	110 (6)	111000 (48) – 110111 (55)	2
Network Control	111 (7)	111000 (56) – 111111 (63)	1

Wi-Fi Multimedia (WMM)

Boost Network Performance: Windows 7 <a class=»term1 piterm» href=»/_iframe_term.php?seek=QOS» title=»What is QOS ?» rel=»sg-term»>QOS</a> — BizTech

Wi-Fi Multimedia (WMM), formerly known as Wireless Multimedia Extensions (WME), is part of the 802.11e WLAN specification that enhances quality of service (QoS) on a network by prioritizing data packets.

WMM has four access categories: background, best effort, video and voice. These are used to assign priority to traffic on wireless networks. WMM access categories are mapped to DSCP values as shown in the table. Windows automatically adds packets with DSCP values to the appropriate WMM access category; packets not assigned to a specific category are automatically tagged as «best effort.»

Mapping WMM Access Categories to DSCP Marks

WMM Access Categories	DSCP Value
Background (BG)	8-23
Best Effort (BE)	0-7 and 24-31
Video (VI)	32-47
Voice (VO)	48-63

Background: file downloads, print jobs, and other traffic that does not suffer from increased latency.
Best Effort: traffic from devices that lack QoS tagging, default for all legacy devices/applications.
Video: priority over all other data traffic.
Voice: highest priority allows for Voice over IP (VoIP) with minimal latency/jitter and the highest possible quality.

Note: The Wi-Fi Alliance has also added a Power Save Certification to WMM. PowerSave is designed to fine-tune power consumption, and to save power for battery-powered devices.

See Also

SpeedGuide TCP Optimizer
Windows 10 Registry Tweaks