Компьютерные сети. 6-е изд.

5.4. QoS и QoE приложений

Методы, представленные в предыдущих разделах, направлены на устранение перегрузок и повышение производительности сети. Однако некоторым приложениям (и клиентам) нужны более строгие гарантии качества, чем просто обязательство предоставить «лучшее из возможного в данных обстоятельствах» (иногда это называется подходом best effort). Кроме того, многие приложения требуют определенной минимальной пропускной способности и плохо функционируют, если задержка превышает некоторое пороговое значение. В этом разделе мы продолжим разговор о производительности сети с акцентом на методах обеспечения качества обслуживания, отвечающего требованиям конкретных приложений. Уже долгое время в данной области интернета происходят значительные изменения. В последнее время важную роль приобретает QoE (Quality of Experience — качество пользовательского опыта), поскольку в конечном итоге важен лишь полученный пользователем опыт взаимодействия, а у разных приложений пороговые значения и требования к производительности сети могут сильно различаться. Все большее внимание уделяется способам оценки QoE, когда для наблюдения доступен только зашифрованный сетевой трафик.

5.4.1. Требования приложений к QoS

Последовательность пакетов, передающихся от источника к получателю, называется потоком (flow) (Кларк; Clark, 1988). При этом в сетях, ориентированных на установление соединения, его могут составлять все пакеты канала, а в сетях без установления соединения — все пакеты, отправленные от одного процесса к другому. Каждый поток требует определенных условий, которые можно охарактеризовать четырьмя основными параметрами: пропускная способность, задержка, джиттер и потери. Все вместе они формируют необходимый потоку QoS (Quality of Service — качество обслуживания).

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

Приложение

Пропускная способность (bandwidth)

Задержка (delay)

Джиттер (jitter)

Потери (loss)

Электронная почта

Низкая

Низкая

Низкая

Средняя

Передача файлов

Высокая

Низкая

Низкая

Средняя

Веб-доступ

Средняя

Средняя

Низкая

Средняя

Удаленный доступ

Низкая

Средняя

Средняя

Средняя

Аудио по запросу

Низкая

Низкая

Высокая

Низкая

Видео по запросу

Высокая

Низкая

Высокая

Низкая

Телефония

Низкая

Высокая

Высокая

Низкая

Видеоконференции

Высокая

Высокая

Высокая

Низкая

Илл. 5.27. Строгость требований приложений к QoS

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

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

Колебание (то есть стандартное отклонение) времени задержки или времени прибытия пакета называется джиттером (jitter). Первые три приложения на илл. 5.27 спокойно отнесутся к неравномерной задержке доставки пакетов. При организации удаленного доступа этот фактор имеет большее значение, поскольку при сильном джиттере обновления экрана будут происходить скачками. Видео- и особенно аудиоданные крайне чувствительны к джиттеру. Если пользователь смотрит видео по сети и все фреймы приходят с задержкой ровно 2,000 с, проблем не возникнет. Но если время передачи колеблется от 1 до 2 с и приложению не удается скрыть джиттер, результат будет просто ужасен. При прослушивании звукозаписей заметен джиттер даже в несколько миллисекунд.

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

Чтобы удовлетворить требования различных приложений, сеть может предлагать разные категории QoS. Яркий пример — сети ATM, которые когда-то считались перспективными, но впоследствии стали нишевой технологией. Они поддерживают:

1. Постоянную битовую скорость (например, телефония).

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

3. Переменную битовую скорость не в реальном времени (например, просмотр фильмов по запросу).

4. Доступную битовую скорость (например, передача файлов).

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

5.4.2. Избыточное обеспечение

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

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

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

1. Что приложениям нужно от сети?

2. Как регулировать трафик, поступающий в сеть?

3. Как зарезервировать ресурсы на маршрутизаторах, необходимые для обеспечения производительности?

4. Может ли сеть принять больший объем трафика?

Ни один подход не в состоянии эффективно решить все эти проблемы. Поэтому для сетевого (и транспортного) уровня разработано множество различных методов. На практике для обеспечения QoS используются комбинации методов. Мы рассмотрим два варианта QoS для интернета: комплексное и дифференцированное обслуживание.

5.4.3. Планирование пакетов

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

Механизмы, распределяющие ресурсы маршрутизаторов между пакетами одного потока или между конкурирующими потоками, называются алгоритмами планирования пакетов (packet scheduling algorithm). Для разных потоков могут резервироваться три типа ресурсов:

1. Пропускная способность.

2. Буферное пространство.

3. Время центрального процессора (CPU).

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

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

Наконец, время CPU также может быть очень ценным ресурсом. Маршрутизатор тратит его на обработку пакета, а значит, скорость этого процесса ограниченна. Современные маршрутизаторы в основном быстро справляются с этой задачей, но некоторые типы пакетов (в частности, ICMP, о которых мы поговорим в разделе 5.7.4) все же требуют более длительной работы CPU. Уверенность в том, что процессор не перегружен, — залог своевременной обработки пакетов.

Планирование пакетов по принципу FIFO

Алгоритмы планирования пакетов распределяют пропускную способность и другие ресурсы маршрутизатора, решая, какой пакет из буфера отправить по исходящей линии следующим. Простейший вариант планировщика мы уже обсуждали, когда говорили о принципе работы маршрутизатора. Каждый маршрутизатор помещает пакеты в очередь (отдельную для каждой исходящей линии), где они ждут отправки. Дальнейшая передача пакетов происходит в том же порядке, в каком они пришли. Этот принцип называется FIFO (First-In First-Out, первым пришел — первым ушел) или FCFS (First-Come First-Serve, первым пришел — первым обслуживается).

Маршрутизаторы, работающие по принципу FIFO, при переполнении очереди обычно удаляют пакеты, которые пришли последними. Новые пакеты помещаются в конец очереди, поэтому такой принцип работы называется «обрубанием хвоста» (tail drop). Трудно представить альтернативу настолько простому и привычному методу. Однако алгоритм RED (см. раздел 5.3.2) при росте очереди отбрасывает прибывающие пакеты случайным образом. Другие алгоритмы планирования, которые мы обсудим, применяют самые разные принципы выбора пакетов для удаления.

Справедливое обслуживание

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

Чтобы обеспечить изоляцию потоков и предотвратить их конфликты, было разработано множество различных алгоритмов планирования пакетов (Бхатти и Кроукрофт; Bhatti and Crowcroft, 2000). Одним из первых был алгоритм равноправных очередей (fair queueing) (Нейгл; Nagle, 1987). Маршрутизаторы организуют отдельные очереди для каждой исходящей линии, по одной для каждого потока. Как только линия освобождается, маршрутизатор циклически сканирует очереди (илл. 5.28) и выбирает первый пакет следующей очереди. Таким образом, если за данную исходящую линию конкурируют n хостов, то каждый из них отправляет один пакет из каждых n пакетов. Получается, что все потоки передают пакеты с одинаковой скоростью и агрессивному хосту не поможет отправка большего числа пакетов.

Илл. 5.28. Циклическая обработка равноправных очередей

Однако у этого метода есть один недостаток. Предоставляемая им пропускная способность напрямую зависит от размера пакетов, отправляемых хостом: чем они крупнее, тем больше ресурса ему выделяется. В книге Демерса и др. (Demers et al., 1990) предлагается улучшенная версия алгоритма, в которой циклический опрос производится с целью выхватывания байта, а не пакета. Идея заключается в вычислении виртуального времени, то есть номера цикла, на котором отправка пакета завершится. Каждый цикл выхватывает один байт из всех очередей, содержащих пакеты для передачи. Затем пакеты сортируются согласно времени завершения отправки и передаются в этой последовательности.

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

Таблица на илл. 5.29 (б) показывает, что первые два пакета в двух верхних очередях прибывают в порядке A, B, D, F. Пакет A приходит на нулевом цикле, а его длина равна 8 байт, поэтому отправка завершается на 8-м цикле. Точно так же отправка пакета B завершается на цикле 11. Пакет D прибывает в момент отправки B. Его передача заканчивается через 9 циклов после окончания

Илл. 5.29. (а) WFQ. (б) Время окончания отправки для пакетов

отправки B; время равно 20. Аналогичным образом время завершения отправки F равно 16. Если новых пакетов нет, порядок окончания отправки пакетов будет таким: A, B, F, D (хотя F прибывает после D). Может случиться так, что в верхний поток поступит небольшой пакет, который будет передан раньше D. Но он обойдет D только в том случае, если отправка D еще не началась. При использовании равноправных очередей передача пакета не прерывается. Алгоритм передает пакеты целиком и потому является лишь приближением идеальной схемы побайтовой передачи. Но это достаточно хорошее приближение: в каждый момент времени передается ровно один пакет.

Взвешенные равноправные очереди

Проблема данного алгоритма в том, что он дает всем хостам одинаковые приоритеты. Как правило, видеосерверам лучше предоставлять большую пропускную способность, чем обычным файл-серверам, чтобы они могли передавать два или несколько байтов за цикл. Такая модификация алгоритма называется взвешенными равноправными очередями (Weighted Fair Queueing, WFQ). Если количество байтов, передаваемое за цикл, считать весом потока W, то формула времени окончания передачи выглядит так:

Fi = max( Ai, Fi–1) + Li/W,

где Ai — время прибытия, Fi — время окончания отправки, а Li — длина i-го пакета. Нижняя очередь (илл. 5.29 (а)) имеет вес 2, поэтому ее пакеты передаются быстрее. Это хорошо видно, если посмотреть на значения времени окончания отправки на илл. 5.29 (б).

Еще один важный фактор — сложность реализации. WFQ помещает пакеты в очередь, сортируя их по времени окончания отправки. Для N потоков это требует по меньшей мере O(log N) операций для каждого пакета, а это трудновыполнимо при большом количестве потоков на высокоскоростных маршрутизаторах. Упрощенная схема дефицитного циклического обслуживания (Deficit Round Robin, DRR) работает гораздо эффективнее: всего за O(1) операций для каждого пакета (Шридхар и Варгезе; Shreedhar and Varghese, 1995). Она широко применяется для алгоритма WFQ.

Существуют другие алгоритмы планирования пакетов, например приоритетный, при котором пакеты обладают каким-либо приоритетом. Высокоприоритетные пакеты передаются раньше, чем низкоприоритетные; последние помещаются в буфер. Пакеты с одинаковым приоритетом отправляются по принципу FIFO. Важным недостатком этого алгоритма является то, что высокоприоритетные пакеты препятствуют отправке низкоприоритетных, которые могут ждать своей очереди бесконечно долго. С этой точки зрения более удачным вариантом является WFQ. Если присвоить высокоприоритетной очереди большой вес (скажем, 3), пакеты в ней будут в основном проходить по быстрой линии (поскольку их сравнительно немного). При этом часть низкоприоритетных пакетов тоже будет передаваться. Фактически бинарная приоритетная система представляет собой две очереди, одна из которых имеет бесконечный вес.

Наконец, существует алгоритм планирования, при котором у каждого пакета есть временной штамп, определяющий порядок отправки. В реализации, которую предложили Кларк и др. (Clark et al., 1992), временной штамп регистрирует информацию о том, насколько пакет, проходя через маршрутизаторы сети, отстает от графика или опережает его. Как правило, пакеты, ожидающие отправки, отстают, а передаваемые в первую очередь — опережают график. Использование временных штампов — эффективный способ ускорить отправку медленных пакетов и замедлить передачу быстрых. При таком подходе все пакеты доставляются с приблизительно равной задержкой, что является очевидным преимуществом.

Собираем все воедино

Теперь, когда мы познакомились с основными компонентами QoS, самое время объединить их, чтобы реально его обеспечить. Гарантии QoS предоставляются через управление допуском. Мы рассматривали его как средство борьбы с перегрузкой, что является гарантией производительности, пусть даже не очень эффективной. Здесь мы предъявляем к гарантиям более серьезные требования, но модель остается той же. Пользователь передает в сеть поток, предъявляя определенные требования QoS. Сеть принимает или отвергает этот поток в зависимости от своих возможностей и обязательств перед другими клиентами. Если поток принимается, сеть должна заранее зарезервировать ресурсы, чтобы при передаче по нему трафика клиент получил необходимый уровень QoS.

Необходимо зарезервировать ресурсы на всех маршрутизаторах, расположенных в узлах пути, по которому следуют пакеты. Иначе может возникнуть коллапс, и гарантии QoS не будут выполнены. Многие алгоритмы маршрутизации выбирают наилучший путь от отправителя до получателя и направляют по нему весь трафик. Однако некоторые потоки могут быть отвергнуты из-за недостатка ресурсов в узлах наилучшего маршрута. Тогда, чтобы выполнить свои обязательства, сеть выберет другой путь для отправки крупного потока. Этот подход называется QoS-маршрутизацией (QoS routing); см. работу Чэня и Нарштедт (Chen and Nahrstedt, 1998). Также можно разделить трафик для одного адресата по нескольким маршрутам, чтобы было проще найти дополнительные ресурсы. Маршрутизаторы могут выбирать пути с одинаковой стоимостью и использовать маршрутизацию, пропорциональную или эквивалентную емкостям исходящих связей. Однако существуют и более сложные алгоритмы (Нелакудити и Чжан; Nelakuditi и Zhang, 2002).

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

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

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

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

В качестве содержимого спецификации потока рассмотрим пример на илл. 5.30. Он основан на RFC 2210 и RFC 2211 для комплексного обслуживания — технологии QoS, о которой мы поговорим в следующем разделе. В специ­фикации содержится пять параметров. Первые два, скорость маркерного ведра и размер маркерного ведра, позволяют вычислить максимальную скорость, которую источник может поддерживать в течение долгого времени, усредненную по большому временному отрезку, а также максимальный объем пачки, передаваемой за короткий промежуток времени.

Параметр

Единицы измерения

Скорость маркерного ведра

байт/с

Размер маркерного ведра

байт

Пиковая скорость передачи данных

байт/с

Минимальный размер пакета

байт

Максимальный размер пакета

байт

Илл. 5.30. Пример спецификации потока

Третий параметр, пиковая скорость передачи данных, — это максимальная допустимая скорость (даже для коротких временных интервалов). Отправитель ни в коем случае не должен превышать это значение.

Наконец, последние два параметра определяют минимальный и максимальный размеры пакетов, включая заголовки транспортного и сетевого уровней (например, TCP и IP). Минимальный размер удобен, поскольку обработка каждого пакета занимает фиксированное время, пусть даже небольшое. Возможно, маршрутизатор готов принимать 10 000 килобайтных пакетов в секунду, но не готов обрабатывать 100 000 50-байтных пакетов в секунду, хотя во втором случае скорость передачи меньше. Максимальный размер пакета не менее важен, но уже по другой причине. Дело в том, что существуют определенные внутрисетевые ограничения, которые нельзя превышать. Например, если путь потока лежит через Ethernet, то максимальный размер пакета будет ограничен 1500 байтами, независимо от того, пакеты какого размера поддерживаются другими участками сети.

Каким образом маршрутизатор преобразует спецификацию потока в набор определенных резервируемых ресурсов? На первый взгляд может показаться, что если один из каналов маршрутизатора работает со скоростью 1 Гбит/с, а средний размер пакета равен 1000 бит, он может обрабатывать 1 млн пакетов в секунду. Но это не так, поскольку из-за статистического джиттера нагрузки передача будет периодически останавливаться на некоторое время. Если для выполнения всей работы канал должен использовать всю емкость, перерыв длиной в несколько секунд станет причиной завала, который невозможно разгрести.

Однако даже если нагрузка несколько меньше теоретической емкости, все равно могут образовываться очереди и возникать задержки. Рассмотрим ситуацию, в которой пакеты приходят нерегулярно со средней скоростью λ пакетов/c. Они имеют случайную длину и могут передаваться по каналу со средней скоростью обслуживания μ пакетов/c. Предположим, что обе скорости имеют пуассоновское распределение (такие системы называются системами массового обслуживания M/M/1, где «M» означает «марковский процесс», который в данном случае является еще и пуассоновским). Тогда, используя теорию массового обслуживания, можно доказать, что средняя задержка T, присущая пакету, равна

где ρ = λ/μ — коэффициент использования CPU. Первый сомножитель 1/μ — это задержка при отсутствии конкуренции. Второй — дополнительная задержка, возникающая из-за конкуренции с другими потоками. Например, если λ = 950 000 пакетов/с, а μ = 1 000 000 пакетов/с, тогда ρ = 0,95 и средняя задержка каждого пакета составляет 20 мкс вместо 1 мкс. Эти подсчеты учитывают и задержку доставки, и задержку обработки: при малом трафике отношение λ/μ ≈ 0. Если на пути потока стоят, скажем, 30 маршрутизаторов, то одна только задержка обслуживания составит 600 мкс.

Один из методов соотнесения характеристик потока и ресурсов маршрутизатора, необходимых для выполнения гарантий пропускной способности и времени задержки, был предложен Парехом и Галлагером (Parekh and Gallager, 1993; 1994). Отправитель формирует трафик с помощью маркерных ведер (R, B), а маршрутизаторы используют WFQ. Каждому потоку присваивается вес W, достаточный для того, чтобы опустошить маркерное ведро со скоростью R (илл. 5.31). Если, например, скорость потока составляет 1 Мбит/с, а мощности маршрутизатора и исходящей связи равны 1 Гбит/с, вес потока должен превышать одну тысячную от общей суммы весов всех потоков этого маршрутизатора для исходящей связи. Это обеспечит потоку минимальную пропускную способность. Если поток не может получить необходимую ему скорость, он не будет допущен в сеть.

Илл. 5.31. Гарантии пропускной способности и задержки с использованием маркерных ведер и WFQ

Самая большая задержка в очереди для данного потока — это функция максимальной емкости маркерного ведра. Рассмотрим два крайних случая. При равномерном трафике пакеты проходят через маршрутизатор с той же скоростью, с какой прибывают. При этом не происходит никаких задержек (не считая эффектов пакетирования). С другой стороны, если трафик передается пачками, то пачка максимального размера B может прийти на маршрутизатор полностью. Тогда максимальная задержка D будет равна времени прохождения пакета через маршрутизатор при фиксированной пропускной способности, или B/R (опять же, не считая эффектов пакетирования). Если этот показатель слишком высокий, поток может запросить большую пропускную способность.

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

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

5.4.4. Комплексное обслуживание

В 1995–1997 годах IETF приложила множество усилий по продвижению архитектуры потокового мультимедиа. В результате появилось две дюжины документов RFC: от RFC 2205 до RFC 2212. Общее название этих трудов — комплексное обслуживание (integrated services). Эта технология предназначена как для одноадресных, так и для многоадресных приложений. В первом случае это может быть просмотр потокового видео на новостном сайте одним пользователем; во втором — набор станций цифрового телевидения, транслирующих свои программы в виде потоков IP-пакетов. Данной услугой может пользоваться большое число абонентов в разных географических точках. Далее мы подробнее рассмотрим многоадресную рассылку, поскольку одноадресная передача — это лишь частный случай многоадресной.

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

RSVP — протокол резервирования ресурсов

Главный компонент архитектуры комплексного обслуживания, открытый для пользователей сети, — протокол резервирования ресурсов (Resource reSerVation Protocol, RSVP). Он описывается в стандартах RFC 2205–RFC 2210. Как следует из названия, протокол предназначен для резервирования ресурсов; другие протоколы применяются для описания передачи данных. RSVP позволяет нескольким отправителям отправлять данные нескольким группам абонентов, разрешает отдельным получателям переключать каналы и оптимизирует использование пропускной способности, в то же время устраняя перегрузки.

Самый простой вариант этого протокола использует упомянутую ранее многоадресную маршрутизацию с применением связующих деревьев. Каждая группа получает адрес. Чтобы передать ей данные, отправитель помещает этот адрес в заголовки пакетов. Затем стандартный алгоритм многоадресной маршрутизации строит связующее дерево, охватывающее всех членов группы. Этот алгоритм не является частью протокола RSVP. Единственное отличие от обычной многоадресной маршрутизации состоит в том, что группе периодически рассылается дополнительная информация, с помощью которой маршрутизаторы обновляют в памяти определенные структуры данных.

Рассмотрим сеть на илл. 5.32 (а). Хосты 1 и 2 — многоадресные отправители, а хосты 3, 4 и 5 — многоадресные получатели. В данном примере они разделены, однако в большинстве случаев эти два множества могут перекрываться. Деревья многоадресной рассылки для хостов 1 и 2 показаны на илл. 5.32 (б) и (в) соответственно.

Илл. 5.32. Протокол резервирования ресурсов (а) Сеть. (б) Связующее дерево многоадресной рассылки для хоста 1. (в) Связующее дерево многоадресной рассылки для хоста 2

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

Пример резервирования показан на илл. 5.33 (а). Здесь хост 3 запросил канал к хосту 1. После создания канала поток пакетов от хоста 1 к хосту 3 может идти без перегрузок. Рассмотрим, что произойдет, если теперь хост 3 зарезервирует канал к другому отправителю, хосту 2, чтобы пользователь мог одновременно смотреть две телевизионные программы. Резервирование второго канала показано на илл. 5.33 (б). Обратите внимание: между хостом 3 и маршрутизатором E должно быть два отдельных канала, так как передаются два независимых потока.

Илл. 5.33. Пример резервирования. (а) Хост 3 запрашивает канал к хосту 1. (б) Затем хост 3 запрашивает второй канал к хосту 2. (в) Хост 5 запрашивает канал к хосту 1

Наконец, на илл. 5.33 (в) хост 5 решает посмотреть программу, передаваемую хостом 1, и также резервирует себе канал. Сначала требуемая пропускная способность резервируется до маршрутизатора H. Затем он замечает, что у него уже есть канал от хоста 1, поэтому дополнительное резервирование выше по дереву не требуется. Обратите внимание, что хосты 3 и 5 могут запросить разную пропускную способность (например, у хоста 3 маленький экран, поэтому ему не нужно высокое разрешение). Следовательно, H должен зарезервировать пропускную способность, достаточную для получателя с самым большим запросом.

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

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

5.4.5. Дифференцированное обслуживание

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

По этим причинам IETF разработал упрощенный подход к QoS. Его можно реализовать локально в каждом маршрутизаторе без предварительной настройки и без участия остальных устройств маршрута. Подход известен как основанное на классах (в отличие от основанного на потоках) QoS. IETF стандартизировал специальную архитектуру под названием дифференцированное обслуживание (differentiated services) и описал в документах RFC 2474, RFC 2475 и во многих других.

Дифференцированное обслуживание может предоставляться набором маршрутизаторов, которые образуют административный домен (например, интернет-провайдер или телефонную компанию). Администрация определяет набор классов обслуживания и соответствующие правила маршрутизации. Пакеты от абонента, пользующегося дифференцированным обслуживанием, получают метку с информацией о классе. Эти сведения записываются в поле Differentiated services пакетов IPv4 и IPv6 (см. раздел 5.7.1). Классы определяются как поведение при переходах (per hop behaviors), так как они отвечают за то, что будет происходить с пакетом на маршрутизаторе, а не во всей сети. Таким пакетам предоставляется улучшенное обслуживание (например, премиум-обслуживание) по сравнению с остальными пакетами (обычное обслуживание). Может потребоваться, чтобы трафик внутри класса соответствовал определенной форме (например, дырявому ведру с заданной скоростью «вытекания» данных). Оператор с хорошим бизнес-чутьем может брать дополнительную плату за передачу каждого премиум-пакета либо установить абонентскую плату за передачу N таких пакетов в месяц. Обратите внимание: здесь не требуется никакой предварительной настройки, резервирования ресурсов и трудоемких согласований параметров для каждого потока, как при комплексном обслуживании. Это делает дифференцированное обслуживание относительно простым в реализации.

Система классов обслуживания встречается и в других сферах. Например, службы доставки посылок могут предлагать несколько уровней обслуживания на выбор: доставка на следующий день, через день или через два дня. Авиакомпании предлагают первый класс, бизнес-класс и эконом. То же самое касается поездов дальнего следования. В парижском метро одно время даже использовались два класса обслуживания при одинаковом качестве сидячих мест. Что касается нашей темы, то классы пакетов могут отличаться друг от друга задержкой, джиттером, вероятностью отклонения в случае коллизии, а также другими параметрами (которых, впрочем, не больше, чем у фреймов Ethernet).

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

Беспрепятственная пересылка

Выбор класса обслуживания зависит от оператора, но поскольку пакеты зачастую необходимо пересылать между сетями разных операторов, IETF установил классы, не зависящие от сети. Простейший из них — класс беспрепятственной пересылки (expedited forwarding), описанный в стандарте RFC 3246. С него и начнем.

Идея, на которой основана беспрепятственная пересылка, очень проста. Существует два класса обслуживания: обычный и ускоренный. Ожидается, что подавляющая часть трафика будет использовать обычный класс. Но есть ограниченная доля пакетов, которые необходимо передавать в ускоренном режиме. Их нужно пересылать так, будто кроме них в сети больше нет никаких пакетов. Тогда они получат обслуживание с низкими потерями, низкой задержкой и низким джиттером — как раз то, что нужно для IP-телефонии. Графическое представление такой двухканальной системы показано на илл. 5.34. Имейте в виду, что физическая линия здесь только одна. Два логических пути на рисунке обозначают резервирование пропускной способности для разных классов (а вовсе не два физических провода).

Данную стратегию можно реализовать следующим образом. Пакеты разделяются на обычные и ускоренные, после чего они получают соответствующие отметки. Это может выполнять хост-источник или входной (первый) маршрутизатор. Преимущество первого варианта в том, что источник располагает большей информацией о распределении пакетов по потокам. Классификация пакетов может производиться сетевым ПО или операционной системой, что позволяет избежать изменений в существующих приложениях. Например, сейчас VoIP-пакеты все чаще помечаются хостами как ускоренные. Если они передаются по корпоративной сети или через провайдера, поддерживающего беспрепятственную пересылку, им будет предоставлено приоритетное обслуживание. Иначе отметка не будет иметь никаких негативных последствий. Таким образом, имеет смысл поставить ее на всякий случай.

Илл. 5.34. Ускоренные пакеты движутся по свободной от трафика сети

Разумеется, если пакет получает метку на хосте, входной маршрутизатор, скорее всего, проверит, не выходит ли объем срочного трафика за установленные пределы. В сети маршрутизаторы могут использовать две очереди для каждой исходящей линии — для обычных и для ускоренных пакетов. Прибывший пакет ставится в очередь, соответствующую его классу обслуживания. Беспрепятственная очередь получает более высокий приоритет (к примеру, с помощью планировщика приоритетов). Таким образом, для ускоренного трафика сеть кажется свободной, хотя на самом деле она может быть сильно загружена обычным трафиком.

Гарантированная пересылка

Более совершенная схема управления классами обслуживания — гарантированная пересылка (assured forwarding), описанная в документе RFC 2597. Она подразумевает наличие четырех классов приоритетов, каждый из которых обладает своими ресурсами. Первые три класса можно назвать золотым, серебряным и бронзовым. Кроме того, определены три класса игнорирования пакетов при перегрузке (низкий, средний и высокий). В итоге получается 12 сочетаний, то есть 12 классов обслуживания.

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

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

Илл. 5.35. Возможная реализация гарантированной пересылки

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