Принцип слоёв

© 2003 by Lawrence B. Solum and Minn Chung.

VI. Приложение: Качество обслуживания, сквозной принцип и анализ слоёв

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

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

А. “Лучшее из возможного”: модель QoS первоначального Интернета

Модель QoS для первоначального Интернета была “лучшей из возможной” доставкой. При “лучшей из возможной” доставке сеть не гарантирует ничего — она будет делать “все от нее зависящее”, чтобы доставить пакеты данных за возможно короткое время, при данном состоянии сети, в данный момент времени. Хотя может показаться, что это вовсе и не проект, модель “лучшее из возможного” была обманчиво простым и элегантным решением для проектных требований к первоначальному Интернету. По словам одного из авторов первоначального Интернета, требования были такими:

  1. Межсетевое взаимодействие: существующие сети должны быть взаимосвязаны.
  2. Надежность: Интернет-связь должна осуществляться, несмотря на потерю сетей или маршрутизаторов.
  3. Неоднородность: Интернет-архитектура должна учитывать множество сетей.
  4. Распределенное управление: Интернет-архитектура должна допускать распределенное управления своими ресурсами.
  5. Стоимость: Интернет архитектура должна быть экономически эффективной.
  6. Простота подключения: Интернет-архитектура должна позволять подключение к хост‑машине без значительных усилий.
  7. Отчетность: ресурсы, используемые в Интернет-архитектуре должны быть надёжными.

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

Второе, самое важное в списке требований надежности, это чтобы Интернет-связь продолжалась, несмотря на потери сетей и маршрутизаторов — “живучесть в условиях провала”. Можно оценить важность требований к надежности при рассмотрении исторического происхождения Интернета, то есть Интернет получился из проекта времён “холодной войны” Агентства по Перспективным Оборонным Научно-Исследовательским Разработкам США (DARPA), цель которого заключалась в создании системы связи, которая выдерживает потери значительной части основных сетей. Интернет устроен так, что он будет продолжать работать даже тогда, когда большая часть составных сетей выпадают из‑за катастрофических сбоев — назовем эту особенность архитектуры Интернета обеспечением непрерывности. Поскольку обеспечение непрерывности требует функционирования Интернета в условиях, где пропускная способность (полоса пропускания) может быть очень низка, — следовательно существует напряженность между обеспечением непрерывности и QoS.

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

Первоначальный Интернет решил эти проблемы совершенно просто и элегантно: для Интернета не будет сложного механизма QoS; сеть просто делает все от нее зависящее. Любые проблемы с производительностью, которые следуют из модели “лучшее из возможного”, должны быть облегчены путем прикладного кода — например, путем буферизации или кэширования данных — или малозатратным простым добавлением дешевых, относительно простых сетей.

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

Тем не менее (а может быть из‑за громкого успеха в Интернете), многие сетевые дизайнеры пришли к вопросу о том, будет ли модель 20-летней давности — “лучшая из возможной” доставка — продолжать отвечать значительно изменившимся требованиям современного Интернета. Например, является ли разумным вопрос о том, будет ли удовлетворять доставка “лучшее из возможного” требованиям, предъявляемым к качеству услуг в отношении прямой трансляции видео высокого разрешения посредством Интернета. Для критичных/зависящих от времени приложений покажется естественным запрос на сети с более надёжными гарантиями качества обслуживания. Такой запрос на сети, поддерживающие приложения, которые зависят от времени и имеют большие объемы данных и при этом эффективно управляют сетевым “трафиком для всех”, привело к поиску более сложного механизма QoS, чем доставка “лучшее из возможного”.

B. QoS и сквозной принцип

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

В добавление они так же сказали, что:

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

C. QoS и анализ слоёв

Анализ вопроса о том, нарушают ли QoS-механизмы принципы разделения и прозрачности слоёв по большей части идёт по следам аналогичного анализа для сквозного аргумента. Во‑первых, необходимо отметить, что, когда дизайнеры говорят о “сетях” в QoS контексте они имеют в виду сетевой (или Интернет) слой, то есть IP-слой. Хотя характеристика пропускной способности и задержки передачи данных будет зависеть от физической среды, это почти не представляет собой проблему для проектирования сетевого трафика. Если у вас медленный модем по старой доброй проводной телефонной связи, в этом случае нет механизма QoS, позволяющего вам получать или передавать “живые” видеоматериалы с высоким разрешением. Вопрос заключается в следующем: учитывая, что пользователи имеют физические каналы, которые могут поддерживать сервисы, пользующиеся высоким спросом, среди, по крайней мере, некоторых людей и приложений, как мы можем гарантировать уровень QoS для этих людей, обеспечивая разумный сервис для менее требовательных пользователей или приложений? Вопрос связан главным образом с функционированием IP-слоя. Таким образом, функцию QoS посредством Интернета иногда называют IP-QoS.

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

Тогда ключевым вопросом является, то, к какому уровню на самом деле относятся функции QoS. Поскольку под качеством обслуживания имеется в виду пропускная способность и задержки сети, QoS механизмы представляются функцией IP-слоя. Как отмечалось выше Бхаттачарджи, Калверт и Зегура, такая информация, как время и место происхождения затора — доступна только внутри сети. Таким образом, сквозной аргумент может также указать на размещение QoS-функций в IP-слое. С другой стороны, по крайней мере, некоторые QoS-функции совершенно точно определяются приложением или пользователем. Например, услуга прямой трансляции видео требует более приоритетного качества обслуживания. Но и при этом, функцию QoS нельзя полностью поместить в прикладном слое, поскольку она не может быть полностью реализована в этом слое. Фактическое осуществление или выполнение функции QoS должно осуществляться в IP-слое, хотя спецификации или запросы для этого исходят с прикладного слоя или слоя контента. Таким образом, принцип слоёв представляется неубедительным применительно к анализу функции QoS.

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

Модель первоначального Интернета “лучшее из возможного” представляет собой классический пример четкого разделения двух функций. Пользователь или приложение говорит: “Доставьте этот пакет, меня не волнует, как вы это делаете”. А сеть говорит: “Я сделаю все, что могу, но мы не можем рассказать вам, как мы будем это делать”.

Альтернатива “лучшее из возможного” (ABE) и сервис QBone Scavenger (QBSS) проекта Интернет-2 являются примерами слабой связи или слабого взаимодействия между спецификацией и исполняемыми функциями. С использованием ABE, все пакеты данных получают “лучшее из возможного” обслуживания, но пользователи или приложения могут указать свое предпочтение одному из двух возможных сценариев “лучшего из возможного” или двух возможных интерпретаций того, что является “лучшим из возможного”, то есть получение низкой сквозной задержки или получение большей общей пропускной способности. Приложения указывают свои предпочтения, помечая пакеты как “зеленые” или “синие”. “Зеленые” пакеты получают низкое “ограничение задержки очереди” в маршрутизаторах. Однако, чтобы удостовериться, что “синие” пакеты не пострадали в результате этого, поток “зеленых” получает меньше пропускной способности во время вспышек перегруженности. Гарантии всё же нет, и приложения не вмешиваются с указаниями, как пакеты обрабатываются маршрутизаторами в сети. Таким образом, существует минимальное взаимодействие или слабая связь между спецификацией и выполнением функций QoS.

Сервис QBone Scavenger (QBSS) представляет собой новую концепцию, созданную рабочей группой Интернет-2 по QoS. Это тоже разновидность сервиса “лучшее из возможного”, но в отличие от ABE, QBSS позволяет пользователям и приложениям помечать их трафик для возможного ухудшения обработки в перегруженных точках сети. Хотя такой подход кажется нелогичным (то есть, зачем кому‑то помечать, что их трафик следует обрабатывать “хуже”, чем другой?), он получает распространение среди университетов, принимающих участие в Интернет-2. По‑видимому, многие пользователи не считают свои действия в Интернете зависящими от времени и готовы жить с возможными задержками, дабы их деятельность не засоряла сети. Например, многие пользователи университетских сетей, пользуясь приложениями пирингового обмена файлами скорее согласятся на возможные незначительные задержки их загрузки, чем навлечь на себя гнев сетевых администраторов за перегрузку сети.

QBSS еще проще, чем модель ABE, поскольку пользователь просто помечает пакеты данных “ниже”, вместо “зеленые” или “синие” как в ABE. Таким образом, взаимодействие и связь между спецификацией QoS и исполнением даже меньше, чем в ABE, что даёт возможно минимальный тип взаимосвязи из всех возможных.

Интересно отметить, что рабочая группа Интернет-2 по QoS переключается на метод QBSS или ABE после приостановки на неопределенный срок своих многолетних усилий по разработке и развертыванию сервиса Premium в связи с неразрешимыми проблемами ввода в действие. QBone Премиум Сервис (QPS) является весьма сложной методикой, влекущей за собой сложное взаимодействие между спецификацией функции (Соглашения об уровне предоставления услуг), и её исполнением.

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

D. Послойный анализ различных методологий QoS

В рамках послойного анализа, приведенного выше, методологии QoS могут быть классифицированы как относящиеся к категориям, где: (1) спецификация функции в прикладном слое явно отделена от исполнения функции в IP-слое; (2) они слабо связаны; (3) они значительно связаны; или (4) функция IP-слоя прямо нарушает принцип разделения слоёв.

Как отмечалось выше, единственной методологией с явным разделением является модель первоначального Интернета “лучшее из возможного”, а Альтернатива “лучшее из возможного” (ABE) или сервис QBone Scavenger являются методами “лучшее из возможного” со слабым взаимодействием между слоем спецификации и слоем исполнения. Большинство имеющихся методологий QoS “самое наилучшее из возможного” относятся к третьей и четвертой категориям.

1. Дифференцированное обслуживание (DiffServ)

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

Дифференцированное обслуживание включает в себя довольно значимое взаимодействие между спецификацией функции в прикладном слое или слое контента и выполнением функции в слое IP, особенно в том, что DS-поля пакетов могут быть пере-записаны в рамках сети, т. е. на IP-слое, когда пересекают границы доменов DiffServ. Однако это не является нарушением слоёв само по себе, так как предположительно, между пользователем и сетью было заключено соглашение об уровне предоставления услуг операторов в слое контента. Когда пакет, который запрашивает более высокий уровень сервиса, повторно пере-помечается иначе, данные не подвергаются дискриминированию в слое IP. Напротив, IP-слой просто выполняет SLA, указанные в слое контента. Кроме того, в худшем случае, все пакеты, предположительно, получат негарантированную доставку.

Тем не менее, взаимодействие между спецификацией и исполнением является довольно важным и сложным. Спецификация QoS в пакете сама по себе не может быть соизмерима с SLA, и сети будет нужно найти SLA для конкретного пользователя и решить, что делать — всё в слое IP. И процесс должен повторяться на границе каждого домена DiffServ, а также необходимы любые дополнительные соглашения по ограничениям между доменами.

2. Интегрированный сервис (IntServ)

Модель интегрированного сервиса требует таких сетевых ресурсов, как пропускная способность и буфера, которые будут зарезервированы априори для данного потока трафика, чтобы обеспечить удовлетворительное качество обслуживания, запрошенное для потока. Модель включает в себя дополнительные компоненты, помимо тех, которые используются в модели негарантированной доставки “наилучшей из возможной”, такие как классификаторы пакетов, планировщики пакетов и контроль приема. Классификатор пакетов используется для определения потоков, которые должны получить определенный уровень сервиса. Планировщик пакетов планирует обслуживание различных потоков пакетов для обеспечения выполнения обязательств QoS. Контроль приёма используется для определения того, имеет ли маршрутизатор необходимые ресурсы для принятия нового потока.

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

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

Хотя модели DiffServ и IntServ сами по себе не нарушают принцип разделения слоёв, их трудно разрабатывать и внедрять в основном за счет больших затрат, из‑за сложного взаимодействия спецификации QoS и режима исполнения, вследствие высокой степени связи между спецификацией в прикладном слое или слое контента и выполнением в IP-слое. Доклад о “посмертном” анализе столь широко обсуждаемого провала IP-сервиса Интернет-2 Премиум подвёл опыт многих лет разочарований следующим образом:

Авторы доклада заключили, сделав следующее замечание:

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

3. Методологии QoS с нарушением слоёв

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

Распознавание сетевых приложений Cisco (NBAR) является одним из примеров этого. В соответствии с технической литературой Cisco, NBAR может “заглянуть поглубже в пакет” и определить URL или MIME тип (медиатип контента). Кроме того, NBAR может определить различные приложения, которые используют динамические порты, а также обнаружить какие‑либо протоколы приложений, которые проходят через маршрутизатор.

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

Фиксированная скорость доступа (CAR) у CISCO — другой пример. CAR может определять и классифицировать пакеты, основываясь на их источнике и IP-адресе назначения, также как протоколы их приложений. Одним из конкретных примеров, приведенных в качестве использования CAR в литературе CISCO является: “Видео-трафик с указанного IP-адреса классифицируется как среднего приоритета”. Как уже говорилось выше, дискриминирование данных на основе такой классификации является явным нарушением принципа разделения слоев.

E. Выводы касательно качества обслуживания

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