Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

Этот алгоритм настолько "заумный", что даже Алексей (главный автор CBQ) утверждает — будто бы не до конца понял его суть. С его слов:

David D. Clark, Scott Shenker и Lixia Zhang. Поддержка Приложений Реального Времени в Пакетных Сетях c Интеграцией Сервисов: Архитектура и Механизм .

Насколько я понял, основная идея заключается в создании WFQ-потоков для каждого из сервисов с гарантированным качеством обслуживания и привязка оставшейся пропускной способности к фиктивному потоку flow-0 . В поток flow-0 отправляется весь предиктивный трафик и трафик, который обслуживается по принципу "лучшее из оставшегося" (best effort). Планировщик потока в первую очередь пропускает предиктивный трафик, а оставшаяся пропускная способность отдается трафику "best effort".

Примечательно, что в CSZ-потоках (Clark-Shenker-Zhang) НЕ производится наложения ограничений пропускной способности. Предполагается, что поток уже прошел входной контроль QoS сети и не нуждается в дополнительном формировании. Любая попытка что-то улучшить или ограничить, на промежуточных переходах, может привести к нежелательным задержкам и увеличению нестабильности.

На сегодняшний день CSZ – единственный планировщик, который может дать настоящую гарантию качества обслуживания. Другие схемы (включая CBQ) не гарантируют величину задержки.

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

Esteve Camps

< marvin@grn.es>

Этот текст — отрывки из моих тезисов Поддержка QoS в Linux , сентябрь 2000 года.

Исходные документы:

• Draft-almesberger-wajhak-diffserv-linux-01.txt

• Примеры, прилагаемые к дистрибутиву iproute2

• White Paper-QoS protocols and architecturesи IP QoS Frequently Asked Questions.

Автор главы: Esteve Camps < esteve@hades.udg.es>.

Прежде всего, было бы неплохо, если бы вы предварительно ознакомились с RFC, посвященными данной теме (RFC2474, RFC2475, RFC2597 и RFC2598) по адресам: IETF DiffServ working Groupи домашняя страничка проекта diffserv.

Dsmark -— это дисциплина организации очереди, которая предлагает возможности, необходимые в "Differentiated Services" (известной также, как DiffServ, или просто — DS). DiffServ — фактически одна из двух архитектур QoS (вторая называется "Integrated Services"), которая базируется на значении поля DS в заголовке IP-пакетов.

Одним из первых решений в IP, которое предлагало некоторый уровень QoS, был "Type of Service" (Тип Обслуживания) — поле TOS в IP-заголовке. Изменяя это поле, можно было выбрать высокую/низкую пропускную способность, минимальную задержку или высокую надежность. Но это решение не обеспечивало достаточной гибкости, которую требовали вновь появляющиеся услуги (например, приложения реального времени, интерактивные приложения и т.п.). С появлением новых требований, появились и новые архитектуры. Одна из них — DiffServ, которая подменяет первые шесть битов ToS в пакете IPv4 или октет "класс трафика" в пакете IPv6, полем, с названием DS, в котором можно указать до 64 классов трафика.

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

Сеть маршрутизаторов с поддержкой механизмов DiffServ называют "облаком DiffServ" (или "доменом DiffServ"). Классификация, формирование и установка меток (под установкой меток понимается установка значений в поле DS) происходит на входе в "облако". Внутри домена метка определяет — какой уровень QoS должен применяться к трафику внутренними маршрутизаторами сети.

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

Фактически, внутри своих локальных доменов, вы можете диктовать любую политику обслуживания, но при соединении с другими DS-доменами вы должны следовать Соглашению об Уровне Обслуживания (SLA).

К этому моменту у вас наверняка возникла масса вопросов. Diffsrv — это много больше, чем я смог сказать. Вы должны понять, что я не в состоянии в 50 строках изложить содержимое трех RFC. :-)

Как уже было определено выше, в случае с DiffServ, пограничные и внутренние узлы различаются между собой. Это два важных пункта на пути трафика. Оба типа узлов выполняют классификацию трафика. Результат классификации может использоваться для различной DS-обработки, прежде чем пакет уйдет в сеть. Код diffserv представляет пакет в виде структуры sk_buff, в которой имеется поле skb->tc_index. В данном поле сохраняется результат начальной классификации, который может использоваться для различной интерпретации DS на пограничных и внутренних маршрутизаторах.

Значение skb->tc_index изначально устанавливается дисциплиной DSMARK qdisc для каждого входящего пакета, в соответствии с полем DS в IP-заголовке. Кроме того, классификатор cls_tcindex считывает, целиком или частично, значение skb->tcindex и использует его для выбора нужного класса.

Для начала рассмотрим команду DSMARK qdisc и ее параметры:

… dsmark indices INDICES [ default_index DEFAULT_INDEX ] [ set_tc_index ]

Каково назначение этих параметров?

• indices: размер таблицы пар маска-значение. Максимальное значение 2^n, где n >= 0.

• Default_index: индекс в таблице, принимаемый по-умолчанию, если классификатор не находит ни одного совпадения.

• Set_tc_index: инструкция, которая считывает значение поля DS и записывает его в skb->tc_index.

Эта дисциплина выполняет следующие шаги:

• Если вставлена инструкция set_tc_index, то считывается поле DS и сохраняется в skb->tc_index.

• Вызывается классификатор. Он возвращает идентификатор класса, который будет сохранен в skb->tc_index. Если такой класс не найден, то используется класс по-умолчанию из параметра default_index. Если ни set_tc_index, ни default_index не объявлены, то результат может оказаться непредсказуемым.

• После этого управление передается внутренней qdisc, где вы можете повторно использовать результаты фильтрации. Идентификатор класса, возвращаемый внутренней qdisc, запоминается в skb->tc_index. Это значение будет использоваться в качестве индекса таблицы маска-значение. Конечный результат, который будет связан с пакетом, получается из выражения:

New_Ds_field = (Old_DS_field & mask) | value

• Таким образом, конечный результат получается в результате объединения по "И" ds_field и маски, и затем объединения по "ИЛИ" с параметром value. Следующая диаграмма иллюстрирует этот процесс: