Качество обслуживания в IP-сетях | Компьютерное Обозрение

Дмитрий Андрушко

БПотенциально обслуживание разнородного трафика на базе модели best-effort вызывает две проблемы: сетевые перегрузки и несправедливое распределение ресурсов, откуда следует неприемлемое качество услуг. Это заставило выработать принципиально новый подход к обработке IP-пакетов для обслуживания трафика в режиме реального времени (РВ). В 90-х годах создаются модели обработки пакетов, гарантирующие определенный уровень качества обслуживания (Quality of Service -- QoS). В общем случае под качеством услуг понимается возможность получения приложением требуемого количества ресурсов при передаче пакетов через сеть. Обычно выделяют четыре ключевых элемента QoS: задержка, пропускная способность, джиттер (вариации в задержке) и потери пакетов.

QoS без лишних затрат?

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

Как известно, для передачи данных на транспортном уровне используется протокол TCP, ориентированный на предварительное установление соединения и повторную передачу сегментов при отсутствии подтверждения о получении. Простейший способ минимизации потерь пакетов из очереди -- увеличение ее размера. Для передачи мультимедийной информации обычно используется протокол UDP, не устанавливающий предварительного соединения и никоим образом не реагирующий на перегрузки. При этом требуется снизить задержки пакетов (пусть даже путем отбрасывания некоторых из них), что может быть достигнуто уменьшением размера очереди. Предположим, что в очередь, обслуживаемую с помощью механизма best-effort (т. е. First In First Out -- FIFO), поступают пакеты одного TCP- и одного UDP-источника, при этом интенсивность поступления UDP-пакетов изменяется от 0 до уровня пропускной способности исходящего канала. Пока обслуживаются только пакеты данных, нагрузка, создаваемая TCP, регулируется встроенными механизмами. По мере роста интенсивности UDP-трафика свободное место в очереди будет заниматься UDP-пакетами, и результатом конкуренции потоков станут потери пакетов. При этом потеря сегментов заставит TCP снижать нагрузку, в то время как UDP продолжит и далее отправлять большое количество пакетов. Если характеристики нагрузки не изменятся, пропускная способность TCP-соединения снизится до нуля.

Для предотвращения перегрузок в 1993 г. был предложен механизм RED (Random Early Detection -- случайное раннее обнаружение). Он, как и FIFO, относится к алгоритмам активного обслуживания, т. е. регулирует размер очереди путем исключения из нее пакетов. В отличие от FIFO, удаление ожидающих пакетов производится случайным образом, что позволяет избегать перегрузок и обрабатывать пульсирующий трафик. Алгоритм состоит из двух процедур -- оценки среднего размера очереди и принятия решения о сбросе пакета. RED анализирует два параметра -- minth (минимальный размер порога) и maxth (максимальный размер порога). Если размер очереди qlen меньше, чем значение minth, то поступающие пакеты отбрасываться не будут. Если qlen превышает значение параметра maxth, то пакеты удаляются до постановки в очередь. В случае если qlen окажется в пределах minth<qlen<maxth, пакеты будут отбрасываться с вероятностью, линейно изменяющейся от 0 до maxp, где maxp -- максимальная вероятность отброса пакетов. Несмотря на простоту, RED позволяет эффективно бороться с перегрузками. Алгоритм был реализован во многих сетевых ОС (FreeBSD, Linux) и в аппаратных маршрутизаторах. Позднее предлагались и другие алгоритмы борьбы с перегрузками, но в каждом из них была заложена фундаментальная идея RED -- вероятностное регулирование размера очереди. К примеру, ARED (Adaptive RED) старается поддерживать очередь в пределах среднего размера. WRED (Weighted RED) отбрасывает пакеты на основании значения 3-битного поля приоритета IP-пакета. FRED (Flow RED) принимает решение об удалении пакетов на основании статистики обслуживания каждого потока.

Алгоритмы активного управления очередью позволяют эффективно бороться с перегрузками, но не решают проблем неадекватного распределения ресурсов между потоками. Этого можно добиться единственным способом -- их изоляцией, т. е. организацией отдельной очереди для потоков на основании передаваемой информации. Такие дисциплины обслуживания очереди называются планирующими (scheduling). Среди сетевых специалистов больше прижилось другое название -- traffic shaper (формирователь трафика), что достаточно точно отражает специфику решаемых задач. Если отбросить дорогостоящие аппаратные решения для предоставления QoS, речь о которых пойдет ниже, планирующие дисциплины обслуживания очереди -- единственное решение для предоставления гарантированных услуг информационным потокам.

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

К сегодняшнему дню предложено множество таких дисциплин обслуживания очереди. В 1992 г. А. Парех (A. Parekh) развил идею обобщенной модели "справедливого" управления FQ (Fair Queuing) и показал, что если маршрутизатор поддерживает предложенную им дисциплину WFQ (Weighted FQ -- взвешенное FQ) и трафик можно охарактеризовать (например, он подчиняется алгоритму token bucket), то можно обеспечить некоторое максимальное значение задержки. Такой простой и мощный результат позволил организовать предоставление гарантированных услуг для модели IntServ (см. ниже). Но более интересна дисциплина обслуживания очереди, основанная на классах, -- CBQ (Class Based Queuing). CBQ способна распределять пропускную способность канала между классами в соответствии с заданной конфигурацией. Несмотря на незначительную задержку при обработке пакетов, вносимую CBQ, это идеальный вариант для предоставления гарантированных услуг на основании любой Unix-системы. Совместное использование CBQ с алгоритмом активного управления очередью, таким, как RED, позволяет создать современную высокопроизводительную систему обслуживания разнородного трафика при нулевых затратах на обновление оборудования.

Но для Internet в целом нужна была более серьезная альтернатива best-effort. Поэтому...

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

..IntServ, или Каждому по потреб-ностям

одель с интеграцией услуг (Integrated Services -- IntServ) была предложена в начале 90-х годов и разрабатывалась для обслуживания единичных потоков, которым предоставляется два вида услуг: гарантированные и с управляемой нагрузкой. Гарантированные услуги позволяют обеспечить определенному объему трафика поддающееся количественному вычислению максимальное значение задержки при прохождении пакетов из конца в конец. Услуги с управляемым уровнем нагрузки предоставляют определенному объему трафика обслуживание best-effort при виртуальной низкой сетевой нагрузке без строгих гарантий.

Рассмотрим структуру IntServ (рис. 1). Согласно RFC1633, в каждом узле, поддерживающем IntServ, должно быть несколько обязательных элементов:

Рис. 1 Взаимодействие элементов IntServ

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

диспетчер пакетов -- извлекает из каждой очереди пакеты и направляет их на канальный уровень. Для IntServ предложен двухступенчатый диспетчер пакетов. Все поступающие пакеты обрабатываются в соответствии с дисциплиной обслуживания WFQ для изоляции потоков, получающих гарантированные услуги, от всех остальных. Потоки с управляемой нагрузкой и потоки best-effort разделяются с помощью приоритетов;

блок управления доступом (admission control) -- принимает решения о возможности получения трафиком требуемого количества ресурсов, не влияя при этом на ранее предоставленные гарантии. Управление доступом выполняется на каждом узле для принятия или отклонения запроса на выделение ресурсов по всему пути прохождения потока;

протокол резервирования ресурсов -- информирует участников соединения (отправителя, получателя, промежуточные маршрутизаторы) о требуемых параметрах обслуживания. Для модели IntServ рекомендуется использовать протокол RSVP.

Сервисная модель IntServ в сочетании с RSVP позволяет организовать гибкое обслуживание разнотипного трафика, максимально учитывая потребности каждого приложения, а использование WFQ для обслуживания пакетов гарантирует максимальное значение задержки. Эта особенность делает IntServ идеальной для обслуживания мультимедийного трафика.

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

DiffServ, или Простота -- секрет успеха

В 1997--1998 годах была предложена модель Differentiated Services (DiffServ, или DS), представляющая в определенном смысле среднее между сервисными моделями best-effort и IntServ, -- с одной стороны, отсутствуют строгие гарантии получаемого QoS, а с другой -- уровень сервиса выше, чем при использовании best-effort. DiffServ обрабатывает только группы потоков, которые называются агрегированными. Под агрегированным потоком понимается объединение нескольких информационных потоков, требующих сходного обслуживания и получающих одинаковое значение QoS. Для решения проблемы с масштабируемостью было решено перенести выполнение "сложных" функций на периферию сети в пограничные (boundary) узлы. Внутренние (interior) узлы обрабатывают только агрегированные потоки и предоставляют услуги на основании кодов, установленных пограничными маршрутизаторами. Для размещения кода был выбран байт "Тип услуги" (Type of Service -- ToS) из заголовка IPv4 и байт "Класс трафика" (Class of Traffic -- CoT) из заголовка IPv6, названные DS-байтами. Стандарты предполагают для значения кода использование первых 6 бит, последние 2 бита применяются для реализации механизма ECN (Explicit Congestion Notification -- явное предупреждение о перегрузке).

Услуги DiffServ предоставляются в области сети, называемой доменом. DS-домен -- множество смежных DS-узлов, работающих в соответствии с определенными наборами политик обслуживания трафика и согласованными множествами правил пошагового обслуживания групп PHB (см. далее) в каждом узле.

Для обслуживания трафика клиент заключает с провайдером соглашение о предоставлении некоторого уровня сервиса SLA (Service Level Agreement). SLA может содержать правила формирования трафика, полностью или частично составляющие соглашение о формировании трафика (Traffic Condition Agreement -- TCA). TCA определяет правила классификатора и соответствующих профилей трафика, а также правила маркировки, формирования и отбрасывания пакетов, применяемые к тем или иным потокам.

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

Рассмотрим работу пограничного маршрутизатора. Структурная схема обработки поступающих пакетов приведена на рис. 2.

Рис. 2 Структурная схема обработки трафика

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

Следующая далее группа элементов называется блоком формирования трафика (traffic conditioning). Эта группа включает в себя: измеритель (meter), маркировщик (marker), формирователь (shaper), отбраковщик (dropper). Информация о классификации пакета передается в измеритель. Он определяет соответствие параметров потока характеристикам, заданным в профиле с помощью TCA. В зависимости от результата работы измерителя настраиваются маркировщик, отбраковщик и формирователь. Маркировщик устанавливает код DS-байта. Для некоторой группы пакетов маркировщик может быть настроен для установки единственного значения кода либо для маркировки пакета одним из нескольких кодов согласно результату работы измерителя. Формирователь используется для задержки отправления пакетов в случае превышения потоком лимитов, определенных в профиле. Отбраковщик производит удаление пакетов для приведения параметров потока к конфигурации профиля. Необходимо отметить, что блок формирования трафика может содержать не все 4 элемента, а только некоторые из них. На внутренних узлах обычно производятся только процедуры классификации трафика и простой пересылки согласно PHB. Однако процедуры формирования трафика разрешается осуществлять и на внутренних узлах.

Какие же услуги обеспечивает DiffServ? RFC-2638 предлагает два вида услуг -- premium service и assured services. Первый предоставляет гарантированное значение пропускной способности и минимальные задержки. Этот вид услуг может использоваться для организации виртуальных выделенных линий, передачи информации в режиме реального времени. Второй похож на услуги с управляемой нагрузкой для модели IntServ. В пределах одного домена предлагалось организовать также предоставление так называемых "олимпийских услуг" (Olympic Services). Согласно предложению, весь трафик разделяется на три группы -- "золотой", "серебряный" и "бронзовый". При перегрузке в сети "золотой" трафик получает большее количество сетевых ресурсов, чем остальные виды трафика, "серебряный" -- большее количество сетевых ресурсов, чем "бронзовый", и т. д. При этом, в случае отсутствия других видов трафика, любой из них может полностью использовать доступные сетевые ресурсы.

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

DiffServ + IntServ = ?

Опубликованный в конце 2000 г. RFC2998 описывает принципы организации взаимодействия IntServ/RSVP и DiffServ для предоставления QoS из конца в конец. Действительно, из сказанного выше видно, что слабые места одной модели компенсируются соответствующими решениями другой. С одной стороны, плохо масштабируемая IntServ на магистральных участках сети может быть заменена на более простую DiffServ, с другой -- с помощью RSVP может решаться (если не полностью, то в большей степени) проблема с неопределенностью получаемого сервиса в "чистой" DiffServ-сети.

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

Возможна организация двух вариантов взаимодействия:

• DiffServ-регион не поддерживает RSVP-сигнализацию, и ресурсы выделяются на статической основе;
• обработка RSVP-сообщений производится в DiffServ-регионе.

Рис.3 Модель Int-DiffServ

При прохождении через DiffServ-регион содержимое RSVP-сообщений игнорируется, и они пересылаются как обычный пакет с данными. При получении узлом Rx сообщения Path генерируется запрос на резервирование RESV, который затем направляется обратно к узлу Tx. В случае успешной обработки запроса каждым RSVP-совместимым маршрутизатором и прохождения через DiffServ-регион сообщение RESV достигает маршрутизатора Er1. Er1 на основании SLS производит сравнение ресурсов, запрашиваемых в сообщении RESV, и ресурсов, доступных в DiffServ-регионе. Если Er1 подтверждает запрос, сообщение RESV отсылается далее по направлению к узлу Tx. Иначе сообщение отвергается, и узлу Rx отправляется сообщение об ошибке. В полученном узлом Tx сообщении может содержаться информация о маркировании соответствующим кодом пакетов, адресуемых в узел Rx. Значение кода определяется по умолчанию или из сообщения RESV.

Во втором случае предполагается, что пограничные маршрутизаторы в DiffServ-регионе (например, маршрутизатор Br1) поддерживают протокол RSVP. Отметим, что, несмотря на поддержку RSVP-сигнализации, обрабатываются только агрегированные потоки, а не единичные, как в сети IntServ/RSVP. Порядок обмена RSVP-сообщениями такой же, как и в предыдущем случае. Однако благодаря поддержке RSVP в DiffServ-регионе блок управления доступом является частью DiffServ-сети. В результате маршрутизатор Br1 имеет возможность непосредственно обработать RSVP-запрос, исходя из доступности ресурсов.

По-видимому, совместная работа IntServ и DiffServ является оптимальным вариантом для предоставления требуемого QoS из конца в конец. Реализация такой модели позволит ликвидировать причину низкого качества мультимедийных услуг на основе IP-протокола и повысить производительность традиционных сервисов.