Достаточно часто для повышения эффективности функционирования сети при мультимедийной нагрузке с высоким коэффициентом пачечности используются функции «сглаживания профиля трафика» или «сглаживания скорости трафика» (traffic или rate shaping). Функция «сглаживания профиля трафика», как и функции «политики управления нагрузкой» (policing) и «маркировки», используется для максимально возможного исключения вероятноетной составляющей из профиля трафика. Кроме того, реализация сглаживания профиля может быть очень полезной с точки зрения оконечного пользователя, когда нарушаются значения параметров качества обслуживания. Например, если функция маркировки пакета пришла к выводу, что для используемой услуги текущий пакет «вис профиля», то его приоритет должен быть понижен или, в некоторых случаях, например, для потоковых услуг реального времени, пакет должен быть сброшен.

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

При реализации нескольких уровней приоритетов с возможностью маркировки пакетов в более низкие, принятие решения о необходимости сглаживания является достаточно сложной задачей, ибо возникает вопрос - будет ли пакет, подвергнутый сглаживанию, доставлен быстрее, чем если бы ему был назначен более низкий, по сравнению с изначальным, приоритет? С точки зрения прикладного уровня реализация сглаживания может быть полезна для интерактивных приложений типа WWW, FTP, e-mail и т.п.

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

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

Рассмотрим пример. Пусть некоторое приложение генерирует трафик с интенсивностью 10 Кбит/с. В сеть подобная нагрузка может поступать с различной интенсивностью, рассмотрим несколько возможных вариантов (см. рис. 2.25):

• 10 Кбит/с в течение всего времени передачи;

• 50 Кбит/с в течение 0.2 секунды и не передавать ничего в течение 0.8 последующих секунд;

• 100 Кбит/с в течение 0.1 секунды и не передавать ничего в течение 0.9 последующих секунд.

С точки зрения сети, оптимальным является трафик, профиль которого представлен на верхнем из рис. 2.25 - чем же могут быть объяснены остальные представленные профили, почему необходимо передавать

Рис. 2.25. Возможные профили сетевого трафика для одинаковой нагрузки на прикладном уровне нагрузку с заведомо неоптимальными параметрами? В рассматриваемом случае не все зависит от источника, возможно приемник не желает ждать прихода данных в течение 1 секунды, если существует возможность доставить их быстрее, например, за 0.1 секунды.

Эффективность применения сглаживания зависит от коэффициента пачечности сглаживаемого трафика. Например, для трафика, генерируемого видеокодеком М РЕО, профиль которого представлен на рис. 2.26.а, сглаживание является очевидным [КоисИОЗ]. В данном случае сглаживание регулярных пиков на фоне низкой интенсивности остальной нагрузки позволяет добиваться, с одной стороны, существенного уменьшения максимальной скорости передачи (оригинальный профиль по сравнению со сглаженным) и, с другой стороны, сравнительно низкой добавочной задержки для информации, содержащейся в пиках. Для трафика, представленного на рис. 2.26.6, характерна высокая дисперсия средней моментальной скорости, поэтому он не столь регулярен, как трафик МРЕв. Из рисунка видно, что для подобного трафика сглаживание может быть как эффективно (левая часть графика), так и неэффективно (правая часть графика). На основе представленных примеров очевидно сделать вывод, что, чем меньше дисперсия профиля трафика, тем ниже эффективность сглаживания.

Рис. 2.26. Сглаживание профиля для: а) трафика МРЕв; б) трафика с высокой дисперсией средней скорости 2.4.3.5.1. Сглаживание при помощи Leaky Bucket

Реализация сглаживания на базе алгоритма Leaky Bucket достаточно проста и может быть выполнена на базе буфера, содержимое которого считывается с определенной постоянной скоростью, как представлено на рис. 2.27. В отличие от процедуры «политики управления», реализованной также при помощи Leaky Bucket и заключающейся только лишь в мониторинге проходящего трафика, т.е. в подсчете количества пакетов, в данном случае осуществляется управление нагрузкой - контролируется максимальное количество трафика, которое может быть послано в сеть в данной точке. Кроме того, за счет очевидной разницы в моментальных скоростях поступающей и исходящей нагрузки и буферизации достигается эффект снижения значения коэффициента пачечности до нуля. Таким образом, нагрузка, прошедшая процедуру сглаживания, реализованная при помощи Leaky Bucket, является предсказуемой и, в случае наличия для данной нагрузки определенной САС и реализации некоторых дополнительных условий, заданный «профиль» соблюдается.

Отметим, что для каждой описанной системы возможно задать значение параметра «пачки максимального размера» MBS, т.е. при поступлении пачки размером меньше или равным MBS, все пакеты будут с определенной вероятностью, зависящей от текущей занятости очереди, помещены в очередь и не будут потеряны. Как известно, сетевой трафик, как правило, является пачечным, поэтому с достаточно высокой вероятностью можно утверждать, что даже при поступлении мультиплексированного трафика, в некоторой пачке будут находиться достаточное количество пакетов одного и того же потока. Таким образом, сброс одного пакета из пачки может привести к существенным потерям, как в качестве обслуживания (например, при использовании приложений реального времени через протокол UDP), так и в скорости функционирования услуги (например, при использовании протокола TCP, где потеря пакета приводит к повторной передаче и даже к снижению размера окна - последнее зависит от конкретной реализации протокола TCP). Именно поэтому, алгоритмы обработки и управления транзитной нагрузкой должны быть ориентированы на работу с пачечной нагрузкой.

⇐Для архитектуры diffserv: алгоритм trtcm | Управление трафиком и качество обслужевания в сети | Сглаживание при помощи token bucket⇒