Рассмотрим пример функционирования алгоритма RED и сравним его с алгоритмом пассивного управления очередями TailDrop Chao02. Предположим, что существует простая сеть, состоящая из маршрутизатора, четырех источников нагрузки FTP и одного приемника (рис. 2.53). Скорость каналов между источниками FTP и маршрутизатором будет 100 Мбит/с, а задержка в этих каналах 1 мс, 4 мс, 5 мс и 8 мс, соответственно. Скорость выходного канала - 45 Мбит/с. а задержка в нем - 2 мс. Очередь в маршрутизаторе функционирует в соответствии с FIFO, также реализованы алгоритмы управления очередью TailDrop и RED. Пусть источники FTP всегда имеют данные для передачи и всегда передают пакеты только максимального размера 1000 байт. В источнике и приемнике реализован протокол TCP, поэтому функционирование происходит в соответствии с фазами «медленный старт», «предотвращение перегрузки» и «перегрузка».

Структура экспериментальной сети с маршрутизатором TailDrop/RED

Рис. 2.53. Структура экспериментальной сети с маршрутизатором TailDrop/RED

Проведем два эксперимента (имитационное моделирование): в первом, в качестве алгоритма управления очередью, будет функционировать TailDrop, во втором - RED, остальные же параметры сети будут одинаковыми. Рассмотрим график, представленный на рис. 2.54, отражающий зависимость средней задержки пакета от загрузки системы. Для случая TailDrop при моделировании использовался буфер размером от 15 до 140 пакетов. Для случая RED использовались следующие параметры: размер буфера - 100, значение min_th варьировалось от 3 до 50, значение max__th = 3*min_th, w = 0.002, Ртах = 1/50. Сравним полученные результаты. Результатом использования RED является существенно уменьшенное значение средней задержки пакета по сравнению с TailDrop, особенно при высокой загрузке системы. Это объясняется следующими причинами.

При использовании TailDrop и буфера малого размера сброс пакета может иметь место еще при фазе «медленный старт», с другой стороны, при использовании TailDrop и буфера большого размера, среднее значение задержки пакета становится слишком большим и даже может инициировать повторную передачу пакета, еще находящегося в буфере (по истечении таймера TCP). В свою очередь, RED позволяет избегать столь явных недостатков, которыми обладает TailDrop. За счет вероятностного сброса пакетов RED позволяет обеспечить пропорциональный сброс пакетов из разных соединений: вероятность того, что пакет будет сброшен, пропорциональна количеству ресурсов, занимаемых этим соединением (в соответствии с принципом «справедливого распределения ресурсов»). Другими словами, RED пенализирует некоторое соединение в соответствии с объемом трафика им переносимым.

Таким образом, можно утверждать, что реализация алгоритма RED в маршрутизаторах предпочтительнее, нежели реализация TailDrop. Однако на реальных сетях не все так просто, как может показаться на первый взгляд. Необходимо учитывать тот факт, что нагрузка в сети Интернет имеет очень сложную структуру, кроме того, нагрузка TCP также достаточно сложна и ее структура зависит от множества факторов, которые зачастую достаточно сложно учесть. Как известно, на магистральных каналах сети Интернет превалирует ТСР-тра-фик, однако следует заметить, что при оценке параметров функционирования RED необходимо учитывать тип соединений TCP.

При передаче файлов большого размера соединение TCP устанавливается на достаточно большой промежуток времени (long-lived), а при трафике HTTP, так называемые «короткие» соединения TCP, зачастую используются для передачи нескольких сегментов (shortlived). В [Thompson97] приведен анализ TCP-соединений в магистральных каналах сети компании MCI (http://www.mci.corr,), показавший, что до 95% передаваемых байтов принадлежат соединениям TCP, причем 50…70% от этого числа составляют сообщения протокола HTTP. Хотя в последнее время и существует достаточное количество причин для уменьшения представленных цифр, например, в связи с увеличением числа приложений, использующих протокол UDP, и в связи с внедрением протокола HTTP 1.1, приводящего к уменьшению сигнального трафика HTTP, соответственно, нагрузка, создаваемая соединениями TCP, все равно остается на высоком уровне.

Таким образом, используя представленную статистику, можно оправданно предположить, что большинство соединений TCP устанавливаются на достаточно короткий срок. Этот факт необходимо учитывать при настройке параметров алгоритма RED. Заинтересованному читателю автор рекомендует обратиться к работам [ChrisOl, DeCnodder99, DeCnodderOO], в которых проводятся фундаментальные исследования возможного поведения RED в реальных сетях. Кроме того, достаточно интересными с точки зрения реализации являются результаты, представленные в работе [KristoiDl], Автор использовал маршрутизатор Cisco 7206 с версией программного обеспечения IOS 12.0(11.6)S, в котором реализован алгоритм RED. В результате применения RED, по сравнению с TailDrop, автор констатировал существенное понижение вероятности потери пакета при пиковых нагрузках: регулярный сброс пакетов со средней скоростью 400 пакетов в секунду при использовании TailDrop, против достаточно редкого сброса пакетов со средней скоростью 100 пакетов в секунду при использовании RED.

Настройка параметров алгоритма red | Управление трафиком и качество обслужевания в сети | Реализация алгоритма red