Три модели обеспечения QoS
𝔯𝔱_𝔣𝔞𝔫Все вышеуказанные характеристики (потери, задержка, джиттер) универсальны относительно природы сети. Однако существует три разных подхода к их обеспечению.
- Best Effort - никакой гарантии качества. Все равны.
- IntServ - гарантия качества для каждого потока. Резервирование ресурсов от источника до получателя.
- DiffServ - нет никакого резервирования. Каждый узел сам определяет, как обеспечить нужное качество.
Best Effort (BE).
Никаких гарантий.
Самый простой подход к реализации QoS, с которого начинались IP-сети и который практикуется и по сей день. Иногда потому что его достаточно, но чаще из-за того, что никто и не думал о QoS.
Кстати, когда вы отправляете трафик в Интернет, то он там будет обрабатываться как BestEffort. Поэтому через VPN, прокинутые поверх Интернета (в противовес VPN, предоставляемому провайдером), может не очень уверенно ходить важный трафик, вроде телефонного разговора.
В случае BE — все категории трафика равны, никакому не отдаётся предпочтение. Соответственно, нет гарантий ни задержки/джиттера, ни полосы.
Этот подход носит несколько контринтуитивное название — Best Effort, которое новичка вводит в заблуждение словом «лучший».
Однако фраза «I will do my best» означает, что говорящий постарается сделать всё, что может, но не гарантирует ничего.
Для реализации BE не требуется ничего — это поведение по умолчанию. Это дёшево в производстве, ведь персоналу не нужны глубокие специфические знания. QoS в этом случае не поддаётся никакой настройке.
Однако эта простота и статичность не приводят к тому, что подход Best Effort нигде не используется. Он находит применение в сетях с высокой пропускной способностью и отсутствием перегрузок и всплесков.
Например, на трансконтинентальных линиях или в сетях некоторых ЦОДов, где нет переподписки.
Иными словами в сетях без перегрузок и там, где нет необходимости особенным образом относиться к какому-либо трафику (например, телефонии), BE вполне уместен.
IntServ.
Заблаговременное резервирование ресурсов для потока на всём протяжении от источника до получателя.
В растущий бессистемно Интернет отцы сетей MIT, Xerox, ISI решили добавить элемент предсказуемости, сохранив его работоспособность и гибкость.
Так в ответ на стремительный рост реал-тайм трафика и развитие мультикаста в 1994 году родилась идея IntServ. Сокращалась она тогда до IS.
Название отражает стремление в одной сети одновременно предоставлять услуги для реал-тайм и не-реал-тайм типов трафика, предоставив первым приоритетное право использования ресурсов через резервирование полосы. Возможность переиспользования полосы, на которой все и зарабатывают (благодаря чему IP и выстрелил), при этом сохранялась.
Миссию по резервированию возложили на протокол RSVP, который для каждого потока резервирует полосу на каждом сетевом устройстве.
Грубо говоря, до установки TCP сессии или до начала обменом данными, конечные хосты отправляют RSVP Path с указанием требуемой полосы. И если обоим вернулся RSVP Resv — они могут начать коммуницировать. При этом, если доступных ресурсов нет, то RSVP возвращает ошибку, и хосты не смогут общаться или пойдут по BE.
Пусть теперь храбрейшие из читателей представят, что для любого потока в интернете сегодня будет сначала происходить обмен сигнальными сообщениями с требованиями выделить ресурс для потока. Учтём, что это требует ненулевых затрат CPU и памяти на каждом транзитном узле, а также откладывает фактическое взаимодействие на некоторое время. И нам становится понятно, почему IntServ оказался фактически мертворожденной идеей — нулевая масштабируемость.
В некотором смысле современная инкарнация IntServ — это MPLS TE с адаптированной под передачу меток версией RSVP — RSVP TE. Хотя здесь, конечно же не End-to-End и не per-flow.
DiffServ.
DiffServ сложный.
Когда в конце 90-х стало понятно, что End-to-End подход IntServ в IP провалился, в IETF созвали в 1997 рабочую группу «Differentiated Services», которая выработала следующие требования к новой модели QoS:
- Никакой сигнализации (Адьёс, RSVP!).
- Основана на агрегированной классификации трафика, вместо акцента на потоках, клиентах и тд.
- Имеет ограниченный и детерминированный набор действий по обработке трафика данных классов.
- В результате в 1998 родились эпохальные RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) и RFC 2475 (An Architecture for Differentiated Services).
- И дальше всю дорогу мы будем говорить только о DiffServ.
Стоит обратить внимание, что название DiffServ — это не антитеза IntServ. Оно отражает, что мы дифференцируем сервисы, предоставляемые различным типам трафика, иными словами разделяем/дифференцируем эти типы трафика.
IntServ делает то же самое — он различает типы трафика BE и Real-Time, передающиеся на одной сети. Оба: и IntServ и DiffServ — относятся к способам дифференциации сервисов.