какие способы работы с очередью ты знаешь
Уничтожаем очередь обращений. Часть 1
В начале декабря, глядя на статистику продаж, Николай потирал руки: заказов было в два раза больше, чем в ноябре, и месяц обещал январский отпуск в Красной поляне. К 20 числу продажи начали падать. Почтовый ящик поддержки превратился в горшочек из сказки, который варил без остановки и никакие волшебные слова не помогали. Пришлось самому сесть за письма, но поддержка все равно не справлялась: отвечали долго, клиенты злились и заказывали в другом магазине. Что помешало команде Николая выдержать наплыв обращений перед новым годом? Николай не учел нагрузку. В университете он прогуливал Теорию массового обслуживания и теперь не рассчитал, сколько сотрудников ему понадобится во время пика обращений. Кроме того, команда хаотично обрабатывала заявки без четкого плана и не смогла удержать очередь за хвост.
Формулами ТМО мучить вас не будем, а сегодня расскажем о втором: стратегии управления очередью е-мейлов. По каким принципам формировать и обрабатывать очереди, как и в каком порядке отвечать клиентам, чтобы они не психовали и были счастливы. Подкинем Николаю и вам три полезные идеи.
0. И сразу нате лайфхак
Отрежьте часть очереди, создав базу знаний на сайте. Расположите ее там, где клиенты увидят. Соберите ЧАВО в специальном разделе или оставьте ответы на каждой странице, где у клиентов чаще возникают вопросы. Скажем, клиенты закидали Николая письмами про сроки и стоимость доставки. Если бы он разместил эту информацию на странице оформления заказа, то сэкономил бы время и клиентам, и службе поддержки. Помните, что лучший сервис – отсутствие сервиса. Сперва подумайте, как кардинально сократить количество обращений. Потом поехали дальше.
1. Первый пришел-первый обработан vs сортировка и приоритет
Не все обращения одинаково срочные. Задача – найти самое срочное.
Поэтому суть работы с очередью сводится к двум действиям:
Отсортировать — то есть разделить одну большую очередь на несколько маленьких по параметрам. По времени, по теме, по ценности, по сложности, по первой букве имени клиента, по цвету глаз.
Присвоить приоритет — определить, кто в этой маленькой очереди подождет, а кто получит ответ первым: зеленоглазые или голубоглазые?
Давайте разбираться на деле. У Николая три письма: 
По времени в приоритете самое старое письмо.
Если смотреть на тип клиента, то випу он должен ответить первому.
А тема “СРОЧНААА” как бы намекает.
Хм. По каждому из параметров оказался разный приоритет. Для решения задачи осталось отетить на вопрос:
что в письме клиента самое важное?
2. Кто последний? vs cвободная касса!
Эти два способа распределения очереди обращений по ответственным агентам вам хорошо известны.
Вспомните, как в детстве в поликлинику мы приходили только по расписанию работы участкового врача и кричали “кто последний?”, вставая в очередь.Вот как-то так было:
Правило соблюдалось строго – попасть к другому участковому можно было, только если ты при смерти. Смысл схемы понятен: город разбит на участки, к участку прикреплен ответственный врач, участковый знает тебя с пеленок, у него хранится толстая карточка, где непонятным почерком записаны истории твоих болезней.
Если перевести в плоскость кастомер сервис, то вы здесь постоянный клиент, и врач — ваш персональный менеджер. Он в курсе событий в твоем организме и знает, как помочь. Звучит неплохо, но в реальности ты обречен на мучительное ожидание с температурой и соплями, когда перед тобой 10 человек забегают “только за справкой”.
Проблема “прикрепления” клиента к агенту в том, что в персональной очереди обращение клиента застревает, когда ответственный агент сосредоточен на другом клиенте.
А что если бы врачи работали как в Макдональдсе? Поток очереди делится на ручейки, которые протекают к свободной кассе.
Каждого нового клиента обслуживает первый освободившийся.
Представьте, что не пришлось ждать очереди к вашему участковому в кабинет 9, и вы спокойно пошли к другому врачу, потому что на его участке видно меньше болеют.
-Ой, она в соседнем кабинете!
Здесь мы столкнулись с разными принципами формирования очереди. В макдак люди приходят каждый раз с новым запросом. Поэтому любого клиента запросто обслуживает любая свободная касса. А врачу важна история болезни. Без карточки тут никуда. Вы уже догадались о решении – дать доступ к этой карточке каждому врачу. А в случае нашего Николая – показывать агентам историю обращений покупателя, чтобы даже випу смог помочь любой сотрудник.
С этим справится Usedesk, который хранит карточку клиента с актуальной информацией о взаимодействии и комментариям предыдущих сотрудников.
Так клиент не зависит от “занятости” персонального менеджера, и получает решение быстрее. Любой агент ответит за секунды, не тратя время на уточнение деталей.
3. Универсалы vs узкие специалисты
Если в вашей команде поголовно универсальные бойцы, вы распределяете запросы автоматически равномерно. Это гарантирует, что каждому есть с чем работать, без учета тематики вопроса и навыков сотрудника. Но чем больше команда, тем труднее поддерживать одинаковой набор скиллов у каждого агента. А сложные вопросы требуют задействовать и другие отделы. Поэтому зоны ответственности разделяют либо внутри команды поддержки, либо между отделами в компании. Одни отвечают за выбор размера и расцветки платья, другие за связь с курьером, третьи за возврат денег. Это следующий шаг после сортировки и определения приоритета – маршрутизировать вопрос к специалистам.
Посмотрим, как это сделать.
1. Предложить сформулировать вопрос и выбрать адресата самому клиенту. Размещаем на сайте адреса всех отделов компании, а клиент ломает голову, куда написать.
Со всех сторон вариант так себе. Клиент не угадает с направлением и состарится в ожидании ответа, а нам придется бесконечно пересылать письма из отдела в отдел в поисках ответственного.
2. Щадящий вариант с элементами элегантности: дать выбрать тему обращения из списка. Отличный способ отсортировать вопросы еще до того, как они попали в систему поддержки.
Тематика уже определена, поддержке не придется дополнительно просматривать содержание письма и вычленять суть, остается только адресовать ответственному. Это здорово упростит задачу в настройке процессов внутри саппорта и в дальнейшей аналитике. Но постарайтесь не утомить клиента выбором из 100500 вариантов тем. И не забудьте про универсальное “другое” — клиент обидится, если не найдет нужной тематики.
3. Пусть клиенты пишут на один адрес, не задумываясь о формулировке, сортировать будем уже на своей стороне. Для этого настраиваем в Юздеске правила, которые по условиям присваивают теги запросам и назначают на ответственного специалиста или группу. Все вопросы, содержащие “лабутены” сразу отправляем Николаю.
Мы перекладываем ответственность за сортировку и маршрутизацию на робота, поэтому с настройкой придется повозиться. Кому назначить письмо зависит не только от содержания, но от канала и времени обращения, приоритета, статуса, и тд. Загружаем сколько угодно сложную логику, а потом с наслаждаемся работой с назначенными письмами без путаницы. Даже если система ошиблась и запрос попал не туда, его легко переназначить вручную.
На этом прервемся, а в следующий раз углубимся в детали. Как делить команду, кого пропускать без очереди и для чего использовать разветвление задач. А пока гоу делиться в комментариях, как вы справляетесь с очередью.
Алгоритмы управления очередями
Механизмы очередей используются в любом сетевом устройстве, где применяется коммутация пакетов — маршрутизаторе, коммутаторе локальной или глобальной сети, конечном узле.
Необходимость в очереди возникает в периоды временных перегрузок, когда сетевое устройство не успевает передавать поступающие пакеты на выходной интерфейс. Если причиной перегрузки является процессорный блок сетевого устройства, то необработанные пакеты временно помещаются во входную очередь, т. е. в очередь на входном интерфейсе. В случае, когда причина перегрузки заключается в ограниченной скорости выходного интерфейса (а она не может превышать скорость поддерживаемого протокола), то пакеты временно хранятся в выходной очереди.
Оценка возможной длины очередей в сетевых устройствах позволила бы определить параметры качества обслуживания при известных характеристиках трафика. Однако изменение очередей представляет собой вероятностный процесс, на который влияет множество факторов, особенно при сложных алгоритмах обработки очередей в соответствии с заданными приоритетами или путем взвешенного обслуживания разных потоков. Анализом очередей занимается специальная область прикладной математики — теория массового обслуживания (queuing theory), однако получить с ее помощью количественные оценки можно только для очень простых ситуаций, не соответствующих реальным условиям работы сетевых устройств. Поэтому служба QoS использует для поддержания гарантированного уровня качества обслуживания достаточно сложную модель, решающую задачу комплексно. Это делается с помощью следующих методов:
АЛГОРИТМЫ ОБРАБОТКИ ОЧЕРЕДЕЙ
Чаще всего в маршрутизаторах и коммутаторах применяются следующие алгоритмы обработки очередей:
Каждый алгоритм разрабатывался для решения определённых задач и поэтому специфическим образом воздействует на качество обслуживания различных типов трафика в сети. Возможно комбинированное применение этих алгоритмов.
Принцип алгоритма FIFO состоит в следующем. В случае перегрузки пакеты помещаются в очередь, а если перегрузка устраняется или уменьшается, пакеты передаются на выход в том порядке, в котором поступили («первым пришел — первым ушел», First In — First Out). Этот алгоритм обработки очередей по умолчанию применяется во всех устройствах с коммутацией пакетов. Он отличается простотой реализации и отсутствием потребности в конфигурировании, однако имеет принципиальный недостаток — дифференцированная обработка пакетов различных потоков невозможна. Очереди FIFO необходимы для нормальной работы сетевых устройств, но они не справляются с поддержкой дифференцированного качества обслуживания.
Механизм приоритетной обработки трафика предусматривает разделение всего сетевого трафика на небольшое количество классов с назначением каждому классу некоторого числового признака — приоритета. Разделение на классы (классификация) может производиться разными способами.
Классификация трафика представляет собой отдельную задачу. Пакеты могут разбиваться на классы по приоритетам в соответствии с типом сетевого протокола, например, IP, IPX или DECnet (заметим, что такой способ подходит только для устройств, работающих на втором уровне), на основании адресов получателя и отправителя, номера порта TCP/UDP и любых других комбинаций признаков, содержащихся в пакетах. Правила классификации пакетов на приоритетные классы являются составной частью политики управления сетью.
Блок классификации трафика может размещаться как в самом устройстве (см. Рисунок 1), так и вне его. Размещение функций классификации трафика в одном или нескольких устройствах, расположенных на границе сети (например, в коммутаторах корпоративной сети, к которым подключаются компьютеры пользователей, или во входных маршрутизаторах сети провайдера), позволяет получить более масштабируемое решение.
Этот вариант классификации требует наличия в пакете специального поля, куда может заноситься заданное значение приоритета, чтобы им могли воспользоваться все последующие сетевые устройства для обработки трафика на пути его следования. Такое поле имеется в заголовке многих протоколов. Так, в пакете IP для этой цели предусмотрено трехразрядное подполе IP Precedence
в поле Type Of Service (TOS). Когда специального поля приоритета не предусмотрено, новый заголовок с таким полем вводится при помощи специально разработанного дополнительного протокола. В частности, для протокола Ethernet (и других протоколов семейства 802) были приняты спецификации IEEE 802.1Q/p, которые определяют дополнительное трехразрядное поле приоритета.
Приоритеты могут назначаться не только коммутатором или маршрутизатором, но и приложением на узле-отправителе. Необходимо также учитывать, что каждое сетевое устройство может не согласиться с приоритетом, назначенным данному пакету в другой точке сети. В этом случае оно изменяет значение приоритета в соответствии с локальной политикой, хранящейся непосредственно на данном устройстве. Во избежание таких прецедентов следует использовать централизованные способы применения политики в сети, дабы обеспечить скоординированное функционирование устройств.
Независимо от выбранного способа классификации трафика, в сетевом устройстве имеется несколько очередей, в соответствии с количеством классов. Поступивший в период перегрузки пакет помещается в очередь согласно его приоритету. На Рисунке 1 приведен пример использования четырех приоритетных очередей: с высоким, средним, нормальным и низким приоритетом. Приоритеты очередей имеют абсолютный характер предпочтения при обработке: пока из более приоритетной очереди не будут выбраны все пакеты, устройство не переходит к обработке следующей, менее приоритетной. Поэтому пакеты со средним приоритетом всегда обрабатываются только тогда, когда очередь пакетов с высоким приоритетом пуста, а пакеты с низким приоритетом — только когда пусты все вышестоящие очереди.
Конечный размер буферной памяти сетевого устройства предполагает некоторую предельную длину каждой очереди. Обычно по умолчанию всем приоритетным очередям отводятся буферы одинакового размера, но многие устройства разрешают администратору выделять каждой очереди индивидуальный буфер. Его максимальная длина определяет предельное количество пакетов, которые могут храниться в очереди данного приоритета. Пакет, поступивший в то время, когда буфер заполнен, просто отбрасывается.
Приоритетное обслуживание очередей обеспечивает высокое качество сервиса для пакетов из самой приоритетной очереди. Если средняя интенсивность их поступления в устройство не превосходит пропускной способности выходного интерфейса (и производительности внутренних блоков самого устройства, участвующих в продвижении пакетов), то пакеты с наивысшим приоритетом всегда получают ту пропускную способность, которая им необходима. Что же касается остальных классов приоритетов, то качество их обслуживания ниже, чем у пакетов с наивысшим приоритетом, причем предсказать уровень снижения затруднительно. Оно может быть довольно существенным, если высокоприоритетные данные передаются с большой интенсивностью.
Поэтому приоритетное обслуживание обычно применяется в том случае, когда в сети есть чувствительный к задержкам трафик, но его интенсивность невелика, так что его наличие не слишком ущемляет остальной трафик. Например, голосовой трафик чувствителен к задержкам, но его интенсивность обычно не превышает 8-16 Кбит/с, и, таким образом, при назначении ему наивысшего приоритета остальные классы трафика не пострадают. Однако в сети могут наблюдаться и другие ситуации. В частности, видеотрафик тоже требует первоочередного обслуживания, но имеет гораздо более высокую интенсивность. Для таких случаев разработаны алгоритмы управления очередями, дающие низкоприоритетному трафику некоторые гарантии даже в периоды повышения интенсивности высокоприоритетного трафика.
ВЗВЕШЕННЫЕ НАСТРАИВАЕМЫЕ ОЧЕРЕДИ
Алгоритм взвешенных очередей (Weighted Queuing) разработан для того, чтобы для всех классов трафика можно было предоставить определенный минимум пропускной способности или удовлетворить требования к задержкам. Под весом какого-либо класса понимается доля выделяемой данному виду трафика пропускной способности выходного интерфейса. Алгоритм, в котором вес классов трафика может назначаться администратором, называется «настраиваемой очередью» (Custom Queuing). Именно его мы и будем рассматривать. В случае, когда веса назначаются автоматически, на основании некоторой адаптивной стратегии, реализуется так называемый алгоритм «взвешенного справедливого обслуживания» (Weighted Fair Queuing, WFQ), ему будет посвящен следующий раздел.
Как при взвешенном, так и при приоритетном обслуживании, трафик делится на несколько классов, и для каждого вводится отдельная очередь пакетов. С каждой очередью связывается доля пропускной способности выходного интерфейса, гарантируемая данному классу трафика при перегрузках этого интерфейса. В примере, приведенном на Рисунке 2, устройство поддерживает пять очередей для пяти классов трафика. Этим очередям соответствует 10, 10, 30, 20 и 30% пропускной способности выходного интерфейса при перегрузках.
Поставленная цель достигается благодаря тому, что очереди обслуживаются последовательно и циклически, и в каждом цикле из каждой очереди забирается такое число байт, которое соответствует весу очереди. Например, если цикл просмотра очередей в рассматриваемом примере равен 1 сек, а скорость выходного интерфейса составляет 100 Мбит/с, то при перегрузках в каждом цикле из первой очереди забирается 10 Мбит данных, из второй тоже 10 Мбит, из третьей — 30 Мбит, из четвертой — 20 Мбит, из пятой —
30 Мбит. В результате каждому классу трафика достается гарантированный минимум пропускной способности, что во многих случаях является более желательным результатом, чем подавление низкоприоритетных классов высокоприоритетным.
Точные значения параметров QoS для алгоритма взвешенного обслуживания предсказать трудно. Они существенным образом зависят от динамически изменяющихся параметров нагрузки сетевого устройства — интенсивности пакетов всех классов и вариаций промежутков времени между прибытием пакетов. В общем случае взвешенное обслуживание приводит к большим задержкам и их отклонениям, чем первоочередное обслуживание для самого приоритетного класса, даже при значительном превышении выделенной пропускной способности над интенсивностью входного потока данного класса. Но для более низких приоритетных классов взвешенное справедливое обслуживание часто оказывается более приемлемым с точки зрения создания благоприятных условий обслуживания всех классов трафика.
ВЗВЕШЕННОЕ СПРАВЕДЛИВОЕ ОБСЛУЖИВАНИЕ
Взвешенное справедливое обслуживание (Weighted Fair Queuing, WFQ) — это комбинированный механизм обслуживания очередей, сочетающий приоритетное обслуживание со взвешенным. Производители сетевого оборудования предлагают многочисленные собственные реализации WFQ, отличающиеся способом назначения весов и поддержкой различных режимов работы, поэтому в каждом конкретном случае необходимо внимательно изучить все детали поддерживаемого WFQ.
Наиболее распространенная схема предусматривает существование одной особой очереди, которая обслуживается по приоритетной схеме — всегда в первую очередь и до тех пор, пока все заявки из неe не будут исполнены. Эта очередь предназначена для системных сообщений, сообщений управления сетью и, возможно, пакетов наиболее критических и требовательных приложений. Во всяком случае, предполагается, что её трафик имеет невысокую интенсивность, поэтому значительная часть пропускной способности выходного интерфейса остается другим классам трафика.
Остальные очереди устройство просматривает последовательно, в соответствии с алгоритмом взвешенного обслуживания (см. Рисунок 3). Администратор может задать вес для каждого класса трафика аналогично тому, как это делается в случае взвешенного обслуживания. Вариант работы по умолчанию предусматривает для всех остальных классов трафика равные доли пропускной способности выходного интерфейса (за вычетом оставшейся от приоритетного трафика).
Производители оборудования дополняют механизм WFQ некоторыми полезными режимами. Например, в маршрутизаторах компании Cisco предусмотрено несколько разновидностей WFQ:
Для варианта FWFQ на базе потоков в маршрутизаторе создается столько очередей, сколько потоков существует в трафике. Под потоком в данном случае понимаются пакеты с определенными значениями IP-адресов отправителя и получателя и/или портов TCP/UDP отправителя и получателя (типа протоколов транспортного уровня), а также одинаковыми значениями поля ToS. Иначе говоря, по-
ток — это последовательность пакетов от одного приложения с определенными параметрами качества обслуживания, заданными в поле ToS.
Каждому потоку соответствует отдельная выходная очередь, для которой в периоды перегрузок механизм WFQ выделяет равные доли пропускной способности порта. Поэтому иногда алгоритм FWFQ называют FQ (Fair Queuing) — справедливое обслуживание.
Вариант CWFQ на базе классов в маршрутизаторах Cisco имеет два подварианта:
Для варианта групп QoS администратор задает веса пропускной способности, выделяемой каждой группе QoS, а также (опционально) максимальную длину очереди. Пакеты, не отнесенные ни к одной из групп, включаются в группу 0. При назначении весов WFQ нужно принимать во внимание следующее:
В варианте классификации на основании значении ToS предусматриваются веса классов по умолчанию. Они вступают в силу, если администратор явно не задал их с помощью команды weight. Для классификации используется два младших бита трехразрядного подполя IP Precedence из поля ToS, так что в этом варианте имеется всего четыре класса трафика. По умолчанию, классу 0 выделяется 10% выходной пропускной способности, классу 1 — 20%, классу 2 — 30% и классу 3 — 40%. Чем выше класс, тем важнее трафик, поэтому выделение большей доли пропускной способности создает для него более привилегированные условия продвижения.
Во многих сетевых устройствах механизм WFQ является одним из основных для поддержки качества обслуживания, в том числе и в случае различных протоколов, использующих методы сигнализации для координированного поведения всех устройств сети, например, при применении протокола RSVP.
ОБЩАЯ ХАРАКТЕРИСТИКА ПРОТОКОЛОВ QOS IP
Протоколы и механизмы поддержки качества обслуживания в сетях IP делятся на две категории в зависимости от уровня гарантий предоставляемого сервиса:
Протоколы первой категории разрабатываются рабочей группой IETF по интегрированным сервисам (Integrated Services Working Group, IntServ). Базовая модель такого сервиса предполагает интегрированное взаимодействие всех устройств сети по обеспечению требуемого качества обслуживания вдоль всего пути потока.
IETF занимается разработкой IntServ достаточно давно — в рамках этого направления проблема обеспечения QoS в сетях TCP/IP впервые стала решаться систематически. Однако ввиду значительной сложности поддержки интегрированных сервисов в масштабах такой сети, как Internet, свое развитие получило и другое направление, которое в данный момент ведет рабочая группа по дифференцированным сервисам (Differentiated Services Working Group, DiffServ). Она специализируется на протоколах второй категории, которые не обеспечивают «настоящего» гарантированного качества обслуживания, но зато гораздо проще в реализации.
Сервисы DiffServ опираются на ту же обобщенную модель QoS, что и сервисы IntServ, однако для них резервирование ресурсов сетевых устройств не предусматривается. Вместо этого они сигнализируют о потребностях потока в обслуживании путем включения необходимой информации в каждый отдельный пакет — поле IP Precedence несет код, который интерпретируется каждым маршрутизатором сети для приоритетного или взвешенного обслуживания данного потока по отношению к другим.
Дифференцированные сервисы применяются главным образом на магистрали сетей, поскольку по магистрали обычно проходит столь большое количество микропотоков различных приложений, что гарантированная поддержка каждого из них в соответствии с принципами интегрированного обслуживания требует чрезмерных ресурсов маршрутизаторов ядра сети. Применение дифференцированных сервисов гораздо экономичнее, так как они работают с агрегированными потоками, состоящими из микропотоков со схожими требованиями к QoS.
Кроме протоколов категорий IntServ и DiffServ, в сетях IP применяется еще несколько протоколов, связанных с поддержкой качества обслуживания. Прежде всего, это протокол NPLS, который позволяет направлять поток по маршруту с необходимым качеством обслуживания.
К средствам поддержки QoS в сетях IP относятся также работающие на отдельных узлах механизмы обслуживания и формирования очередей, такие как WFQ и CQ. Они функционируют на маршрутизаторах как необходимые элементы реализации интегрированных и дифференцированных сервисов. Однако администратор сети может их использовать и для улучшения качества обслуживания на тех маршрутизаторах, где возникают заторы трафика, существенно влияющие на работу сети в целом.
ДИФФЕРЕНЦИРОВАННОЕ ОБСЛУЖИВАНИЕ DIFFSERV
Дифференцированные сервисы представляют собой весьма простой и «грубый» метод классификации требований к качеству обслуживания небольшого числа агрегированных потоков сети. Основная идея, положенная в основу этой группы сервисов QoS, состоит в том, что все маршрутизаторы сети должны единообразно понимать требования к качеству обслуживания, закодированные в пяти битах поля ToS протокола IPv4.
Дифференцированные сервисы не прибегают к резервированию ресурсов маршрутизаторов, поэтому они не могут дать гарантий на предоставляемое качество обслуживания, реализуя только «мягкую» поддержку QoS. Каждый маршрутизатор работает независимо от остальных и старается обеспечить предпочтительное качество обслуживания потоков в соответствии с правилами пошагового поведения (Per-Hop Behavior, PHB), которые определяются отдельными стандартами IETF. Выделение всего пяти бит для кодирования требований к качеству обслуживания означает, что в сети может существовать не более 32 агрегированных потоков, отличающихся предоставляемым качеством обслуживания.
Хотя маркировкой пакетов может заниматься любой маршрутизатор сети, модель дифференцированных сервисов в качестве основного варианта предусматривает классификацию пакетов во входной точке сети, поддерживающей протокол DiffServ и находящейся под административным контролем одной организации. Такая сеть называется доменом DiffServ. При выходе пакетов за пределы домена DiffServ маркировка снимается, и другой домен может назначить ее заново.
На сегодняшний день разработаны два стандарта пошагового продвижения пакетов PHB, которые представляют два различных сервиса:
Сервис EF описан в спецификации RFC 2598 «An Expedited Forwarding PHB», которая появилась летом 1999 г. Основное назначение сервиса EF — предоставление качества обслуживания на уровне выделенных каналов, поэтому он называется также сервисом «виртуальных выделенных каналов». Кроме того, он известен как премиальный (Premium Service), чем подчеркивается его способность предоставлять наивысшее качество обслуживания, возможное в сетях IP с дифференцированным
обслуживанием.
Сервис АF описан в спецификации RFC 2597 «Assured Forwarding PHB Group», опубликованной в июне 1999 г. Четыре его группы ориентированы на гарантированную доставку, но без минимизации уровня задержек пакетов, как это оговорено для более качественного сервиса EF. Гарантированная доставка выполняется в том случае, когда входная скорость трафика не превышает отведенной данному классу минимальной пропускной способности. Классы сервиса AF хорошо сочетаются с одним классом сервиса EF — трафик EF может обслуживаться по приоритетной схеме, но с ограничением интенсивности входного потока. Оставшаяся пропускная способность распределяется между классами трафика AF в соответствии с алгоритмом взвешенного обслуживания, который обеспечивает необходимую пропускную способность, но не минимизацию задержек.
Простота приоритезации трафика с помощью DiffServ определяет его гибкость и мощь.
Дмитрий Федодеев — инженер департамента системной интеграции компании «Инжиниринг+Электроникс». С ним можно связаться по адресу: Fedodeev_D@epulse.ru.
Поделитесь материалом с коллегами и друзьями