Методы организации и обработки очередей

11.10. Алгоритмы RED и WRED

Одним из возможных подходов при решении проблемы перегрузки является алгоритм RED (Random Early Detection). RED позволяет маршрутизатору отбрасывать пакеты, даже когда в очереди еще имеется место.

Алгоритм WRED использует взвешенное значение длины очереди в качестве фактора, определяющего вероятность отбрасывания пакета. По мере роста средней длины очереди растет вероятность отбрасывания пакетов. Если средняя длина очереди меньше определенного порога, вероятность отбрасывания пакета равна нулю. Небольшие кластеры пакетов могут успешно пройти через фильтр RED. Более крупные кластеры могут понести потери. Это приводит к тому, что ТСР-сессии с большими открытыми окнами имеют большую вероятность отбрасывания пакетов.

Главной целью алгоритма RED является исключение ситуации, когда несколько ТСР-потоков перегружаются почти одновременно и затем синхронно начинают процедуру восстановления.

Интересное предложение относительно выборочного (приоритетного) отбрасывания пакетов содержится в работе [11.1] в отношении мультимедиа-потоков.

Алгоритм RED позволяет организовать очереди таким образом, что их размер отслеживает осцилляции величины RTT.

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

Существует модификация алгоритма обработки очередей WRED (Weighted Random Early Detection), широко используемая в маршрутизаторах. Этот алгоритм применяется и при реализации DiffServ и гарантированной переадресации ( AF ), когда решение об обработке пакета принимается в каждом транзитном узле независимо ( PHB — Per Hop Behavior). При этом может учитываться код DSCP (Differential Service Code Point) IP-заголовка.

Алгоритм WRED удобен для адаптивного трафика, который формируется протоколом ТСР, так как здесь потеря пакетов приводит к снижению темпа их посылки отправителем. Алгоритм WRED присваивает пакетам не IP-типа нулевой приоритет, повышая вероятность их потери. Имеется возможность конфигурации WRED и WFQ для одного и того же интерфейса.

WRED полезен для любого выходного интерфейса, где ожидается перегрузка. Когда приходит пакет, вычисляется среднее значение длины очереди. Если вычисленное значение меньше минимального порога очереди (Т1), приходящий пакет ставится в очередь. Если вычисленное значение лежит между минимальным порогом очереди для данного типа трафика и максимальным порогом для интерфейса (Т2), пакет ставится в очередь или отбрасывается в зависимости от вероятности отброса, установленной для данного типа трафика. И, наконец, если усредненный размер очереди больше максимального порога, пакет безальтернативно отбрасывается (см. рис. 11.2).

WRED статистически отбрасывает больше пакетов для сессий с большими потоками. По этой причине ТСР-отправители больших потоков будут вынуждены в большей степени понизить поток, чем отправители малого трафика.

Рис. 11.2.

Ни АТМ-интерфейсы маршрутизаторов, ни АТМ-коммутаторы не предоставляют гарантий QoS для UBR виртуальных каналов. Маршрутизатор CISCO может специфицировать только пиковую скорость передачи ( PCR ) для UBR-канала.

Маршрутизатор автоматически задает параметры, которые нужно использовать в вычислениях WRED. Среднее значение длины очереди определяется на основе предыдущего значения и текущего размера очереди, согласно

Среднее = (old_evarage * (1-2^-n)) + (current_queue_size * 2^-n),

где n — экспоненциальный весовой фактор, конфигурируемый пользователем.

Большое значение этого фактора сглаживает пики и провалы значения длины очереди. Средняя длина очереди не будет меняться быстро. Процесс WRED не сразу начнет отбрасывать пакеты при перегрузке, зато продолжит отбрасывание, даже когда перегрузки уже нет (очередь уже сократилась ниже минимального порога). См. рис. 11.3 (кривая с ромбиками соответствует реальной длине очереди, вторая, более гладкая кривая отображает вариацию усредненной длины очереди).

Рис. 11.3. Осцилляция длины очереди (результат моделирования с помощью NS-2)

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

Когда n становится слишком большим, WRED не будет реагировать на перегрузку. Пакеты будут посылаться или отбрасываться так, как если бы WRED не работал.

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

Вероятность отбрасывания пакета зависит от минимального порога ( Т1 ), максимального порога ( Т2 ) и маркерного деноминатора вероятности P_C. Когда средняя длина очереди выше T1, RED начинает отбрасывать пакеты. Частота отбрасываний увеличивается линейно по мере роста длины очереди до тех пор, пока усредненный размер очереди не достигнет максимального порога ( Т2 ).

Маркерный деноминатор вероятности P_C равен доле теряемых пакетов, когда средняя длина очереди равна максимальному порогу. Например, если P_C равен 1/512, один из 512 пакетов отбрасывается, когда средняя длина очереди достигает максимального порога (см. рис. 11.2). Когда усредненная длина очереди превышает T2, отбрасываются все пакеты. Минимальный порог T1 следует выбрать достаточно высоким, чтобы максимизировать использование канала. Значение P_C можно задать и больше 1, но в этом случае длина очереди никогда не достигнет T2.

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

Рис. 11.4. Выбор маршрута нового виртуального канала при наличии перегрузки

На рис. 11.4 (верх) показан пример сети с двумя узлами, характеризующимися перегрузкой (помечены черным цветом). Предположим, что необходимо проложить виртуальный канал из узла А в узел Б. Из графа маршрутов удаляются перегруженные узлы, после чего осуществляется прокладка пути. В нижней части рисунка жирными линиями показан новый виртуальный канал.

Еще более универсальным решением, пригодным для работы с установлением соединения и без, является посылка пакетов блокировки (choke Packets). Маршрутизатор обычно контролирует загруженность всех своих внешних каналов L, которая может принимать значения от 0 до 1. Когда L достигает некоторого порогового значения, отправителю посылается пакет блокировки. При вычислении L следует использовать какую-либо методику усреднения, чтобы избежать слишком частых блокировок.

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

ЭВМ может понижать трафик, корректируя свои параметры, например ширину окна или темп передачи, на выходе устройства типа "дырявое ведро". Обычно первый блокирующий пакет уменьшает поток вдвое, следующий на — 0,25 и т.д. Увеличение потока также производится аналогичными шагами. Существует большое число вариантов алгоритма управления потоком с использованием пакетов блокировки. Параметром, который контролируется и определяет условие отправки пакета блокировки, может служить длина очереди или степень заполнения буфера.

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

Ситуация перегрузки не всегда управляется однозначно. Например, при поступлении на вход пакетов от трех источников возможна ситуация, когда приемник посылает блокирующие пакеты всем отправителям, а откликнется сокращением потока только один. В результате этот узел, который "играет по правилам" (как это часто бывает и в жизни), оказывается в проигрыше. В 1987 году Нагле был предложен алгоритм fair queuing (справедливая очередь, см. соответствующий раздел WFQ выше). В этом алгоритме маршрутизатор организует независимые очереди для пакетов, поступающих от разных источников. Когда выходной канал маршрутизатора оказывается свободным, он просматривает очереди циклически и отправляет очередной пакет. В результате при n очередях по завершении такого цикла просмотров-посылок будет послано по одному пакету из каждой очереди. Этот алгоритм используется в некоторых ATM-переключателях. Следует заметить, что этот алгоритм дает преимущества тем узлам, которые посылают более длинные пакеты. Демерс (Demers) и др. в 1990 году предложили усовершенствование алгоритма. В данном варианте организуется циклический просмотр очередей не попакетно, а побайтно. Система последовательно сканирует очереди и определяет положение концов пакетов. Первыми отправляются более короткие пакеты. Для иллюстрации предлагается рассмотреть рис. 11.5.

Рис. 11.5. Маршрутизатор с 4 входными каналами, в каждом из которых ждет очереди передачи по одному пакету. В правой части рисунка представлен порядок посылки этих пакетов

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

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

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

При серьезных перегрузках, когда потери становятся значительными, нарушается механизм вычисления значений RTT и тайм-аутов, что может приводить к труднопредсказуемым последствиям.

Следует обратить внимание, что в протоколе UDP какого-либо механизма управления трафиком не предусмотрено. По этой причине для мультимедийных задач, следует предусматривать другие, например ICMP-способы подавления перегрузки (хотя это часто неприемлемо и решение следует искать в привлечении методов резервирования или DiffServ).

Если другие способы испробованы, а перегрузка не исчезла, маршрутизатор начинает отбрасывать приходящие пакеты, которые уже не может обработать. Самое простое — это предоставить случаю выбор отбрасываемых пакетов. Но это не лучшая тактика. В случае пересылки мультимедийных данных предпочтение следует отдавать последним полученным пакетам, а "старые" пакеты выбрасывать. При передаче файлов, наоборот, "старый" пакет имеет приоритет, ведь если его отбросить, придется повторно передавать не только его, но и все последующие пакеты. Некоторые методы передачи изображения требуют передачи время от времени всего кадра с последующей пересылкой только фрагментов, где произошли изменения. В таких условиях потеря пакета, составляющего базовый кадр, менее желательна. Сходные обстоятельства могут возникать и в других приложениях. Можно помечать пакеты, присваивая им определенные уровни приоритетов, что позволит осознанно принимать решение об отбрасывании того или иного пакета в условиях перегрузки. В перспективе проблема может быть решена на чисто коммерческой основе: компонента трафика, помеченная как высокоприоритетная, будет оплачиваться по более высокому тарифу. В некоторых сетях определенное количество пакетов объединяется в группы, образующие сообщение. Если одна ячейка такого сообщения выброшена, все сообщение будет повторно переслано (смотри, например, адаптационные уровни сетей ATM).