Обеспечение заданного уровня задержек

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

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

Каким же образом поставщик услуг может выполнить свои обязательства перед клиентами? Очень «просто» — он должен постоянно измерять фактические значения характеристик трафика в сети и гарантировать пользователям сети величины задержек в соответствии с наблюдаемыми результатами.

ПРИМЕР
Пусть сеть предоставляет три уровня качества обслуживания трафика: золотой для очень чувствительного к задержкам трафика, серебряный для трафика, чувствительного к задержкам и требующего гарантированной пропускной способности, и бронзовый для трафика, обслуживаемого по возможности. Оператор сети может различными способами добиться того, чтобы на золотом уровне обслуживания действительно гарантировались очень низкие величины задержек, вариаций задержек и потерь пакетов для трафика, на серебряном — достаточно низкие значения этих характеристик, но выше, чем у золотого, а на бронзовом гарантировались только определенные величины потерь пакетов и вовсе не гарантировались значения задержек. Для реализации такой стратегии обслуживания оператор может, например, организовать на всех коммутаторах сети приоритетную очередь для обслуживание золотого трафика и отвести ей 25 % пропускной способности на каждом выходном интерфейсе; взвешенную очередь с 50 % пропускной способности для серебряного трафика и взвешенную очередь с оставшимися 25 % для бронзового трафика. А далее он должен принимать на обслуживание потоки пользователей в каждый класс и выполнять постоянный мониторинг характеристик трафика каждого класса. И если, например, мониторинг показывает, что задержки у 95 % пакетов золотого трафика не превышают 15 мс, то оператор может гарантировать эту величину пользователям золотого уровня обслуживания. Но так как оператору нужно быть готовым к приему на обслуживание новых пользователей, то естественно было бы оставлять некоторый запас и гарантировать, скажем, задержку в 20 мс вместо фактического значения в 15 мс. Аналогичным образом нужно поступать с серебряным трафиком, а для бронзового достаточно измерять только долю потерь пакетов. В том случае, когда мониторинг показывает приближение фактических параметров трафика определенного уровня обслуживания к гарантируемым, можно либо добавить пропускную способность для очередей этого класса, либо прекратить прием новых пользователей в этот класс.

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