В поисках качества
В повседневном использовании Интернета мы не очень задумываемся о параметрах качества Сети. Для большинства приложений Интернет просто работает, а если работает плохо, то трудно сказать, в чем проблема – то ли домашняя сеть тормозит, то ли провайдер, то ли сам веб-сайт. И никого не удивляет, что, например, качество видеоконференции Zoom или Skype вчера было отличным, а сегодня видео замирает, а речь участников прерывается. И тем не менее, сегодня также никого не удивляет, что телефония через Интернет по качеству мало отличается от традиционной (а если и отличается, то винить в первую очередь стоит плохую настройку домашней сети), что мы можем смотреть стриминг-видео высокого разрешения, и что облачное хранилище подчас превосходит по производительности локальный диск. А как насчет удаленной хирургии и автономных автомобилей?
Мы знаем, что Интернет – это технология «best effort», а это значит, что сеть будет пытаться обеспечить передачу до последнего, пока пользователь сам не оставит свои попытки. Но сегодня «best effort» уже не ассоциируется с мучительными замираниями передачи, а то и вовсе прерыванием связи. Интернет пережил колоссальную трансформацию, которая сделала возможным видеостриминг высокого разрешения, облачные вычисления и сетевые компьютерные игры с погружением в виртуальную реальность. Так все-таки, может Интернет обеспечивать качество или нет?
Попробуем в этом разобраться.
Начну с того, что задачи обеспечения параметров качества передачи, или QoS (Quality of Service), органично вписываются в сети коммутации каналов, такие как традиционные телефонные сети. В традиционной телефонии каждая сеть, через которую проходит вызов, должна сначала зарезервировать ресурсы, а затем предоставить канальную емкость для соединения или разговора, если вызываемый абонент снял трубку. В результате соединение между двумя говорящими имеет гарантированные пропускную способность и другие параметры качества, как, например, задержку.
Но если хотя бы одна из сетей перегружена и не может обеспечить канальную емкость, все предыдущие резервирования должны быть отыграны назад, и сеанс передачи не состоится.
Другой особенностью является то, что сети коммутации каналов являются синхронными, по существу, не использующими буферизации. Это означает, что задержка при передаче между пользователями определяется в основном скоростью распространения сигнала или, другими словами, расстоянием между абонентами.
Интернет же коренным образом отличается от телефонных сетей. Топология и связность сетей, как правило, весьма разветвленная и нерегулярная. «Стандартной услуги» как таковой нет – различные приложения имеют различные требования к пропускной способности и качеству сети. Также Интернет является сетью пакетной передачи, где IP-дейтаграммы асинхронно передаются узлами-маршрутизаторами по каналам со значительной вариацией пропускной способности. Это, в свою очередь, выражается в нерегулярности трафика и требует использования буферов для сглаживания «всплесков». Как мы увидим дальше, буферизация и управление очередями пакетов является важным фактором качества связи.
Но пакетная передача – это полбеды. Основная проблема обеспечения качества заключается в обеспечении связности между сетями и соответствующих взаимоотношений между операторами. Подавляющее большинство этих взаимоотношений берут в расчет только усредненные параметры пропускной способности и только в целом по каналу, не различая отдельные приложения и типы трафика.
Таким образом, для обеспечения заданных параметров качества в Интернете или хотя бы приоритизации отдельных приложений необходимо а) создать возможность для сетей договариваться не только о «связности», но и о более детальных параметрах передачи, включая динамическое резервирование пропускной полосы; и б) внедрить механизмы обеспечения заданных параметров качества в рамках одной сети, или точнее, в рамках одного административного домена.
Начнем с межсетевого вопроса.
IntServ или интеграция служб
В середине 90-х годов прошлого века в IETF (www.ietf.org) была разработана концепция, получившая название Integrated Services, или IntServ (Интегрированные службы). Как указано в документе RFC1633 (http://datatracker.ietf.org/doc/rfc1633), описывавшем архитектуру IntServ, «это расширение [архитектуры Интернета] необходимо для удовлетворения растущих потребностей в услуге реального времени для широкого диапазона приложений, включая телеконференции, удаленные семинары и распределенное моделирование». Также IntServ должен был обеспечить возможность мультиплексирования различных классов трафика в сети, что позволило бы операторам предоставлять различные изолированные друг от друга услуги, используя общую сетевую инфраструктуру.
IntServ определяет два основных класса приложений: приложения реального времени, чувствительные к задержке, и «эластичные» приложения, для которых не так важно, когда именно будут получены данные, а точнее, дейтаграммы.
Чувствительность к задержке приложений реального времени также различается. Например, для передачи голосового или видеопотока приложению необходимо знать максимально возможную задержку для обеспечения адекватной буферизации. В противном случае поток будет прерываться и его качество деградирует. Для таких приложений IntServ предлагает т.н. гарантированную услугу, при которой задержка не может превысить заданную величину.
Менее чувствительные приложения смогут удовольствоваться т.н. предсказуемыми услугами, гарантирующими среднестатистическую задержку. Соответственно, предполагается, что стоимость таких услуг будет значительно дешевле, так как этот подход позволяет достичь гораздо большей утилизации сети.
Наконец, «эластичные» приложения могут продолжать пользоваться «обычным» Интернетом с его услугой best effort.
Хотя сам подход казался привлекательным, он требовал двух существенных изменений в архитектуре и функционировании Интернета. А именно, обеспечения требования контроля доступа и резервирования.
Действительно, для возможности предоставления гарантий по задержке и пропускной способности сетевые ресурсы должны быть первоначально зарезервированы по всему пути передачи данных от источника к получателю (и обратно, поскольку большинство потоков являются дуплексными). Этот процесс очень напоминает резервирование канала в телефонии, только вариация параметров этих каналов значительно больше. Это, в свою очередь, потребовало внедрения дополнительного сигнального протокола резервирования (такой протокол был разработан – RSVP http://datatracker.ietf.org/doc/rfc2205) и модификации протоколов внутри- и межсетевой маршрутизации.
Далее, прежде чем сеанс связи сможет состояться, приложение должно «заключить контракт» с сетью, в соответствии с которым сеть будет обеспечивать передачу данных. Этот «контракт» предусматривает, что приложение не выйдет за рамки установленных параметров, а сеть обеспечит входной контроль. Более того, этот «контракт» должен быть заключен со всеми независимыми сетями на пути от отправителя к получателю.
Схематично архитектура IntServ показана на Рис.1.
Даже не вдаваясь в подробности, можно заметить, что уже на техническом уровне внедрение IntServ означало существенное усложнение архитектуры Сети. В экономическом смысле это означало существенное удорожание инфраструктуры для поддержки новой функциональности. Бизнес-отношения и систему взаиморасчетов между сетевыми операторами необходимо было коренным образом пересмотреть.
Наконец, технологии IntServ должны были быть внедрены и поддерживаться глобально, во всем Интернете. В чем ценность островков качества в океане услуг «best effort»?! Как и в случае многих других глобальных технологий, преимущества от их внедрения становятся ощутимыми, только когда они получают значительное распространение – своего рода замкнутый круг, который нелегко разорвать.
Другими словами, даже одной из перечисленных проблем было достаточно, чтобы поставить под сомнение будущее предлагаемого решения. В случае с IntServ решение осталось в основном на бумаге.
DiffServ – почувствуйте разницу
Однако идея поддержки качества в глобальной инфраструктуре Интернета была слишком заманчивой – и IETF сделал вторую попытку и взялся за разработку другого подхода, целью которого было обеспечение относительного, а не абсолютного, как в случае с IntServ, качества передачи. Другими словами, приложениям реального времени гарантируется определенная емкость, в рамках которой различные потоки конкурируют между собой. Эта архитектура была названа Differentiated Services, или DiffServ.
Вместо резервирования на уровне потока/приложения, в DiffServ контроль производится на уровне достаточно статичных агрегированных «профилей» трафика. Классификация пакетов и принадлежность их к тому или иному профилю определяется по полю IP Type of Service (TOS), исторически оставшемуся в заголовке IP-пакета.
Соответственно, соглашение между различными сетями должно включать договоренность о параметрах ограниченного числа профилей. При этом на входе в сеть производится контроль и возможное кондиционирование трафика для каждого профиля, которое включает буферизацию или даже отброс пакетов, если агрегированный поток превышает договоренные параметры.
Масштабируемость данного подхода, безусловно, лучше по сравнению с IntServ. Еще важнее, что DiffServ не требует динамического резервирования и сохранения состояния для каждого узла сети и каждого потока, проходящего через нее. Однако неразрешимым вопросом остается проблема предоставления определенного качества индивидуальному приложению, включая сигнализацию и гарантии. Трудно представить, что динамические требования многообразных приложений Интернета можно уложить в прокрустово ложе статической конфигурации нескольких профилей.
Другими словами, и это решение не вызвало большого энтузиазма среди операторов. Ресурсы и инвестиции, требуемые для внедрения «качественных» решений, нашли лучшее применение в увеличении канальной емкости, благо и стоимость этих каналов к концу 90-х значительно упала.
Замечу, что концепции DiffServ используются для оптимизации трафика во внутренней инфраструктуре сети оператора, и здесь производители оборудования всегда рады помочь с широким набором возможностей, однако задача обеспечения сквозного качества в Интернете остается иллюзией. О полезных применениях DiffServ мы поговорим чуть позже.
DetNet – сетевой детерминизм
Но если обеспечение качества передачи в Интернете, а точнее, в интердоменном пространстве, представляется сложным, «качественная» передача данных в отдельно взятой сети является вполне достойной и реальной задачей. Ведь, в конце концов, проблема глобального качества не в технологии, а в отсутствии экономических мотивов усложнённых межсетевых отношений.
Основная цель DetNet – обеспечить конвергенцию чувствительных не-IP-сетей в общую сетевую инфраструктуру. Это требует точной эмуляции развернутых в настоящее время специализированных сетей, которые, например, используют аналоговые (например, с модуляцией 4-20 мА) и последовательные цифровые соединения точка-точка для обеспечения связи с высокой надежностью, синхронизацией и отсутствием джиттера. Хотя задержка аналоговой передачи – это, по существу, скорость света, традиционные последовательные каналы обычно медленные (порядка кбит/с) по сравнению, скажем, с Gigabit Ethernet, и некоторая задержка обычно приемлема. Что неприемлемо, так это введение чрезмерного джиттера, который может, например, повлиять на стабильность систем управления.
Особенностью DetNet является то, что она занимается исключительно значениями наихудшего случая для сквозной задержки, джиттера и неупорядоченности пакетов. Средние или типичные значения не представляют особого интереса, поскольку они не влияют на способность системы реального времени выполнять свои задачи. В общем случае тривиальная схема организации очередей на основе приоритетов даст лучшую среднюю задержку для потока данных, чем DetNet, однако это может быть неподходящим вариантом для DetNet из-за показателей задержки в наихудшем случае.
DetNet обеспечивает выполнение таких строгих требований по передаче данных с помощью трех основных методов: размещение и резервирование ресурсов, защита сервиса и использование статических предопределенных маршрутов.
Конечно, существуют более простые методы, доступные (и используемые сегодня) для достижения уровней задержки и потери пакетов, приемлемых для многих приложений. Приоритизация и избыточное выделение ресурсов – один из таких методов. Однако эти методы обычно работают лучше всего в отсутствие какого-либо значительного объема некритического трафика в сети (если такой трафик поддерживается). Они также могут работать только в том случае, если критический трафик составляет лишь небольшую часть теоретической емкости сети, если все системы работают должным образом или если действия конечных систем, нарушающие работу сети, отсутствуют.
DetNet использует три метода для обеспечения такого качества обслуживания:
- Распределение ресурсов
Обеспечение гарантий QoS DetNet осуществляется за счет устранении потери пакетов из-за конкуренции потоков. Это может быть достигнуто только путем предоставления достаточного буферного пространства на каждом узле по сети, чтобы гарантировать, что никакие пакеты не будут отброшены из-за нехватки буферов. При этом каждый из узлов DetNet должен внимательно следить за соблюдением зарезервированных параметров передачи, например, предотвращая отправку пакета раньше времени. Дело в том, что такой пакет потребует дополнительного буферного пространства на следующем узле и может таким образом превысить зарезервированные параметры.
DetNet обеспечивает ограниченную задержку передачи за счет резервирования полосы пропускания и ресурсов буфера на каждом узле DetNet на пути потока DetNet. В настоящее время рассматриваются три возможных класса архитектур плоскости управления DetNet (https://tools.ietf.org/id/draft-malis-detnet-controller-plane-framework-04.html): полностью распределенная система управления, использующая протоколы динамической сигнализации, как, например RSVP-TE; полностью централизованная система управления, подобная SDN; и система управления, объединяющая эти два класса.
- Защита сервиса
Защита сервиса направлена на устранение потери пакетов из-за отказов оборудования, включая случайные сбои носителей и/или памяти. Эти типы потерь пакетов могут быть значительно уменьшены за счет репликации потока данных и последующего их распределения по нескольким непересекающимся путям пересылки. Функции защиты сервиса также следят за упорядоченным получением пакетов. Принцип работы этих функций представлен на Рис. 3.
- Явные маршруты
Чтобы получить преимущества небольшого количества переходов и при этом обеспечить защиту даже от очень кратковременных потерь связи, DetNet использует явные маршруты, где путь, выбранный данным потоком DetNet, не изменяется, по крайней мере, не сразу и, вероятно, вообще не изменяется в ответ событиям сетевой топологии. Защита услуг (см. разделы 3.2.2 и 3.2.2.3) по явным маршрутам обеспечивает высокую вероятность непрерывного соединения. Явные маршруты могут быть установлены различными способами, например, с помощью RSVP-TE [RFC3209], с помощью сегментной маршрутизации (SR) [RFC8402], с помощью подхода SDN [RFC8453], с помощью IS-IS [RFC7813] и т.д. обычно используется в путях коммутации меток (LSP) MPLS TE (Traffic Engineering).
Архитектура DetNet
Функциональность DetNet реализована на двух смежных подуровнях в стеке протоколов: подуровне сервиса DetNet и подуровне передачи. Подуровень сервиса DetNet обеспечивает защиту сервиса для более высоких уровней стека протоколов и приложений. Подуровень передачи обеспечивает функциональность DetNet в базовой сети, например, путем предоставления явных маршрутов и распределения ресурсов для потоков DetNet. Упрощенная схема сети DetNet представлена на рис. 4.
Оконечные системы с поддержкой DetNet и узлы DetNet могут быть связаны между собой подсетями, то есть технологиями «уровня 2». Для поддержки трафика DetNet эти подсети должны предоставлять совместимые услуги. Примеры сетевых технологий «уровня 2» включают MPLS TE, TSN (Time Sensitive Networking, IEEE, Time-Sensitive Networking (TSN) Task Group, https://1.ieee802.org/tsn/) и каналы OTN (Optical Transport Network) точка-точка. Конечно, возможны и многоуровневые системы DetNet, где одна DetNet выступает в качестве подсети и предоставляет услуги более высокоуровневой системе DetNet.
DetNet может также использоваться для предоставления услуг «уровня 2», например, для приложений TSN. В случае использования DetNet как сети «уровня 3» сквозной услугой является соединение IP. Концептуально это напоминает услуги типа L3VPN или IP поверх MPLS.
Важным вопросом для успешного применения этой технологии является вопрос масштабирования. Для резервирования отдельных потоков DetNet требуется значительная информация о состоянии в каждом узле сети, особенно когда требуется адекватное устранение неисправностей. Для возможности эффективной поддержки большого количества потоков необходима их агрегация. Такие агрегированные потоки могут рассматриваться узлами DetNet в основном как отдельные потоки DetNet.
Технология DetNet находится в процессе разработки. Одноименная рабочая группа в IETF (https://datatracker.ietf.org/group/detnet) стандартизовала основные архитектурные аспекты технологии, но многое еще предстоит сделать.
Несколько лет назад Джефф Хьюстон проанализировал проблемы внедрения «качества обслуживания» в Интернете и пришел к выводу, что под этой маркой производители оборудования продают не что иное, как «новое платье короля» https://www.potaroo.net/ispcol/2012-06/noqos.html.
Но задачи перевода существующих приложений на унифицированную технологию и приложения будущего – индустриальные приложения автоматизации и контроля, телемедицины – ставят вопросы QoS на повестку дня острее, чем когда либо. И хотя QoS как гарантия точных параметров качества – пропускной способности, максимальной задержки, джиттера – в глобальном Интернете вряд ли будет внедрена по причинам, которые Джефф точно описал, обеспечение заданных параметров в рамках единого административного домена «специализированных» сетей вполне реально. Причем с использованием протоколов и архитектуры Интернета.