Как связаны взвешенная справедливая очередь и взвешенное случайное раннее обнаружение?

Я пытаюсь понять, как работают системы QoS, и я не уверен, как именно будут взаимодействовать WFQ и WRED.

Сначала я подумал, что WFQ - это механизм очередей, а WRED - механизм предотвращения перегрузок. WFQ должен планировать пакеты в очередях, а WRED должен отбрасывать их, когда очереди заполнены. Если бы я настраивал QoS, например, на коммутаторе L3, я бы настроил механизм организации очередей и механизм предотвращения перегрузок, поэтому теоретически я мог бы работать вместе с WFQ и WRD. Например, этот документ, по-видимому, подразумевает, что они будут созданы таким образом. В некоторых других документах Cisco упоминается, что я мог бы использовать их независимо.

Затем я хотел узнать больше о том, как они работают, и начал искать в Интернете. В результате теперь я понятия не имею, кто они и как работают.

Некоторые сайты (по крайней мере, насколько я понимаю содержание) утверждают, что алгоритмы планирования пакетов и алгоритмы предотвращения перегрузки в основном совпадают. Например, в этой статье в Википедии все они находятся в одной группе. В некоторых случайных статьях упоминалось, что я мог бы использовать WFQ XOR WRED.

Так что я хотел спросить, насколько связаны WFQ и WRED? Когда я буду использовать один или другой, и когда оба, если это вообще возможно?

Взвешенная справедливая очередь (WFQ), как следует из названия, подразумевает алгоритм очередей. Организация очередей используется при перегруженности интерфейса. Обычно это определяется тем, что кольцо передачи (TX-Ring) заполнено. Это означает, что интерфейс занят отправкой пакетов. Организация очереди не происходит, если на интерфейсе нет перегрузки. В некоторых случаях размером TX-кольца можно манипулировать. Небольшое TX-кольцо дает программной очереди больше возможностей относительно того, какие пакеты отправляются первыми, но это не очень эффективно. Слишком большое TX-кольцо сделает программную очередь практически бесполезной и приведет к более высокой задержке и дрожанию важных пакетов.

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

Весьма распространено, что клиент покупает услугу у интернет-провайдера (ISP) по субрейту. То есть клиент покупает услугу 50 Мбит / с, но физический интерфейс работает на скорости 100 Мбит / с. В этом случае не будет заторов, но интернет-провайдер будет ограничивать объем трафика от клиента. Для введения искусственного скопления в этих случаях можно использовать формирователь.

Так что теперь, когда есть перегрузка, алгоритм очередей может быть применен. Обратите внимание, что алгоритмы очередей не предоставляют никакой дополнительной полосы пропускания, они просто позволяют нам решать, какие пакеты более важны для нас. WFQ - это алгоритм, который принимает несколько параметров и на основании этого принимает решение. Алгоритм довольно сложен и использует вес (IP Precedence), размер пакета и время планирования в качестве параметров. Здесь есть очень подробное объяснение от INE . WFQ - хороший выбор, если вы не хотите слишком много возиться с очередями, поскольку он обеспечивает достаточную пропускную способность для потоков малого размера, таких как SSH, Telnet, голос, и это означает, что передача файлов не будет красть всю пропускную способность.

Взвешенное случайное раннее обнаружение (WRED) - это механизм предотвращения перегрузки. WRED измеряет размер очередей в зависимости от значения приоритета и начинает отбрасывать пакеты, когда очередь находится между минимальным порогом и максимальным порогом. Конфигурация решит, что 1 из каждых N пакетов отброшен. WRED помогает предотвратить синхронизацию TCP и голодание TCP. Когда TCP теряет пакеты, он медленно запускается, и если все сеансы TCP теряют пакеты одновременно, они могут стать синхронизированными, что дает график, подобный следующему:

Как можно видеть, если WRED не настроен, график становится полным, затем тихим, затем полным и так далее. WRED обеспечивает более среднюю скорость передачи. Важно отметить, что на UDP не влияет сбрасывание пакетов, потому что у него нет механизма подтверждения и скользящего окна, реализованного как TCP. Поэтому WRED не должен быть реализован на основе класса UDP, такого как класс, обрабатывающий протоколы SNMP, DNS или другие протоколы на основе UDP.

И WFQ, и WRED могут и должны быть развернуты вместе.

Прежде всего, не верьте всему, что читаете в Интернете ;-)

Иногда алгоритмы (или то, как они физически реализованы) не вписываются в теоретическую категорию. То, что вы называете, менее важно, чем понимание того, что оно делает.

Весь смысл WFQ (или любого другого алгоритма планирования) состоит в том, чтобы разделять ограниченную полосу пропускания канала между различными потоками. WFQ пытается распределить пропускную способность пропорционально каждому потоку. CBWFQ делает то же самое для каждого «класса». В идеальном мире с неограниченными очередями и неограниченной памятью это было бы все, что вам нужно - вы разделяете пропускную способность, и все счастливы.

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

Чтобы избежать переполнения очередей, я использую раннее раннее обнаружение. Этот алгоритм случайным образом отбрасывает пакеты из очереди в зависимости от того, насколько заполнена очередь (глубина) - чем полнее очередь, тем больше пакетов будет отброшено. Цель состоит в том, чтобы предотвратить переполнение очереди, чтобы алгоритм планирования мог работать.

Затем какой-то яркий инженер Cisco заметил, что можно использовать меньше очередей (более простое оборудование) и случайным образом отбрасывать разные типы трафика на разных глубинах очереди. WRED отбрасывает трафик из очереди на разной глубине в зависимости от типа трафика. Хотя вы можете назвать WRED механизмом предотвращения перегрузки, поскольку глубина отбрасывания трафика зависит от типа трафика, в результате разные типы получают меньше места в очереди и, следовательно, меньше пропускной способности. Так что это также действует как алгоритм планирования. Вы говорите по-тай-то, а я говорю по-та-то.

Еще одно отличие: FQ и WFQ работают со всеми типами трафика, так как они по существу считают байты. RED и WRED работают только с TCP, потому что они зависят от механизма управления потоками TCP, который замедляет трафик и предотвращает переполнение очереди.

(Примечание: ради объяснения я игнорирую очереди приоритетов и LLQ. Это еще один ответ).

Я согласен со всем, что сказал Майк тоже.

Вот пример CBWFQ и WRED:

политика-карта OUT

класс Голосовой
приоритет процентов 20

Класс видео
пропускной способности процентов 30

класс P1
пропускная способность в процентах 10
случайное обнаружение dscp на основе
случайного обнаружения dscp af31 26 40 10

класс P2
пропускная способность, процент 15,
случайное обнаружение, dscp,
случайное обнаружение, dscp af21 24 40 10

класс класс по умолчанию
справедливая очередь
случайное обнаружение на основе dscp