вероятность падения WRED

[Mitrixsen]

Здравствуйте, все. У меня есть небольшой вопрос о том, как WRED отбрасывает трафик. Рассмотрим пример, который я нашел на сайте NetworkLessons.com ![Mitrixsen_0-1736165869113.png] IPP3 имеет следующие настроенные значения:
Минимальный порог
: 20 пакетов
Максимальный порог
: 45 пакетов
Знаменатель вероятности маркировки:
25% Я думал, что после достижения максимального порога мы будем отбрасывать только 1 из каждых 4 пакетов (25%). ![Mitrixsen_1-1736165894320.png] Так и происходит, если трафик не превышает максимальный порог, но если мы превышаем максимальный порог, мы просто отбрасываем все? Так логика в моем примере работает следующим образом? средняя глубина очереди < минимальный порог
— ничего не отбрасывать средняя глубина очереди > минимальный порог, но < максимальный порог
— случайная отбрасывание пакетов до настроенного знаменателя вероятности маркировки (так что, если глубина очереди постоянно увеличивается, вероятность отбрасывания повышается до 25% по мере приближения к максимальному порогу). средняя глубина очереди = максимальный порог

• вероятность отбрасывания составляет до настроенного MPD (25%) средняя глубина очереди > максимальный порог
  — все отбрасывается Спасибо. Дэвид

[Torbjørn]

Здравствуйте
[, @Mitrixsen]
, Это верно. Рады помочь! Пожалуйста, отметьте как полезное/решение, если применимо.
Свяжитесь с нами: https://torbjorn.dev

[David Ruess]

Здравствуйте, Да, MPD вступает в силу только между пороговыми значениями. Не имеет смысла отбрасывать 25 % пакетов, если очередь заполнена (максимальный порог), нам нужно отбрасывать все, что превышает это значение, чтобы уменьшить перегрузку. -Дэвид

[M02@rt37]

Здравствуйте
[, @Mitrixsen] Верно. WRED — это инструмент
для предотвращения перегрузки
, поэтому «
нам нужно отбросить все, что превышает этот показатель, чтобы уменьшить перегрузку
». С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[Joseph W. Doherty]

Ой, пропустил при первом чтении, но средняя глубина очереди > минимальный порог, но < максимальный порог Должно быть средняя глубина очереди => минимальный порог, но < максимальный порог и когда меньше максимального, вероятность сброса также не максимальна, хотя она может быть округлена до максимальной. Кроме того, при максимальном значении вероятность отбрасывания не достигает максимального значения, а составляет максимальный процент.

[Joseph W. Doherty]

Да, все выпадает за пределы максимума, и вы тоже правильно ответили на остальные вопросы. Кстати, вы можете легко рассчитать точную вероятность случайного отбрасывания для любой глубины очереди, используя уравнение наклона прямой линии, поскольку мы знаем x и y для минимального значения минус 1, нуля и максимального значения. Кстати, всегда имейте в виду, что для WRED глубина очереди является взвешенным скользящим средним. Теоретически, RED может даже отбросить все пакеты, когда фактическая глубина выходной очереди пуста, и, наоборот, отбросить ноль пакетов, когда фактическая глубина очереди превышает максимальное значение.

[Joseph W. Doherty]

WRED — это инструмент
для предотвращения перегрузок,
поэтому «
нам нужно отбросить все, что превышает этот показатель, чтобы уменьшить перегрузки
». Это может быть, но, как правило, очень, очень грубым способом достижения этой цели. То есть, с WRED, в идеале, вы хотите, чтобы все отбрасывания происходили в диапазоне случайных отбрасываний. Вероятно, чаще всего, в общем случае, отбрасывание хвоста используется только для того, чтобы избежать исчерпания буфера. Опять же, я не говорю, что отбрасывание хвоста не может использоваться для управления перегрузкой, потому что оно может, но с WRED это то, чего следует избегать. Однако с WRED, как показано в OP, вы можете отбрасывать трафик с более низким приоритетом раньше, что, как можно надеяться, обеспечит трафику с более высоким приоритетом дополнительную пропускную способность. Это также можно использовать для реализации подхода среднего WTD (установить минимальное и максимальное значение на одно и то же значение с процентом отбрасывания 100%). Кстати, реальная согласованная стратегия отбрасывания для управления перегрузкой, похоже, применяется редко. Еще одна причина для конкретной настройки значения tail drop может заключаться в установке границы задержки передачи в очереди.

[M02@rt37]

Насколько я знаю, WRED — это
в первую очередь
инструмент для предотвращения перегрузки, призванный предотвратить перегрузку до того, как она станет серьезной. В отличие от tail drop, который срабатывает только при заполнении буфера, WRED случайным образом отбрасывает пакеты по мере увеличения средней глубины очереди. Таким образом, он раньше сигнализирует о перегрузке потокам TCP, заставляя их корректировать скорость передачи. Такое поведение помогает предотвратить глобальную синхронизацию, при которой несколько потоков TCP одновременно снижают и увеличивают свою скорость, что приводит к нестабильности и неэффективности сети. Tail drop, напротив, действует как крайняя мера для предотвращения исчерпания буфера, но не обладает тонкостью проактивного управления перегрузкой WRED. Хотя Tail Drop обычно считается грубым методом управления перегрузкой, он имеет свои преимущества. Tail drop может установить жесткий предел глубины очереди, эффективно определяя
границу задержки передачи
. Это гарантирует, что пакеты, превышающие определенный порог задержки, будут отбрасываться, а не ставиться в очередь, что особенно полезно для приложений, чувствительных к задержкам. Однако использование только tail drop для управления перегрузкой часто приводит к резкой остановке трафика и синхронизации повторных передач TCP, что может усугубить перегрузку, а не уменьшить ее. Другим потенциальным применением WRED является реализация подхода
Weighted Tail Drop,
называемого «WTD», путем установки минимального и максимального пороговых значений на одно и то же значение с вероятностью отбрасывания 100%. Это создает детерминированную границу для отбрасывания пакетов, при этом работа все еще осуществляется в рамках WRED. Такие конфигурации могут быть полезны в конкретных сценариях, где требуется точное управление глубиной очереди. Несмотря на свои преимущества, потенциал WRED часто используется не в полной мере. Многие сети полагаются на конфигурации по умолчанию, которые могут не в полной мере удовлетворять потребности их моделей трафика. Однако хорошо продуманная стратегия WRED может эффективно управлять перегрузкой, избегать сценариев полного буфера и обеспечивать более справедливое распределение пропускной способности между конкурирующими потоками трафика. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.

[Joseph W. Doherty]

«TCP-потоки» Кстати, хотя TCP является «визитной карточкой» (W)RED, другие более поздние протоколы, которые также адаптируются к скорости потока, к падениям, также являются кандидатами для обработки типа RED. «... и обеспечивают более справедливое распределение пропускной способности между конкурирующими потоками трафика». Кстати, это довольно сложно реализовать с помощью WRED. Наконец, я написал, что WRED может быть очень сложен в использовании в идеальном варианте и имеет свои «причуды», что во многом является причиной появления всех лучших/улучшенных/(предположительно даже) исправленных вариантов. Одним из интересных вариантов, который Cisco предоставила в серии Catalyst 4k, был FRED (Flow based RED).

[M02@rt37]

TCP — классический пример протокола, хорошо подходящего для механизмов типа RED и WRED. Как протокол с адаптацией скорости потока, TCP реагирует на потерю пакетов снижением скорости передачи, что соответствует цели RED — упреждающе сигнализировать о перегрузке, вероятностно отбрасывая пакеты до переполнения очередей... Однако, хотя TCP является основным случаем использования, другие современные протоколы, такие как QUIC и SCTP, которые адаптируются к потерям аналогичным образом, также могут извлечь выгоду из управления перегрузкой, подобного RED. «Одной из целей WRED является содействие более справедливому распределению пропускной способности между конкурирующими потоками трафика путем выборочной потери пакетов из более агрессивных потоков при сохранении менее интенсивного трафика»... На практике достижение этой справедливости затруднено из-за различных факторов. WRED основывает вероятности отбрасывания на пороговых значениях очередей и объеме трафика, что означает, что он по своей сути предпочитает меньшие, менее агрессивные потоки. Однако справедливость все еще может быть нарушена различиями в RTT, размерах окон или алгоритмах управления перегрузкой, что может привести к ущемлению некоторых потоков, несмотря на намерения. WRED также известен своей сложностью в настройке и оптимизации. Установка правильных пороговых значений, весов и вероятностей для различных типов трафика является сложной задачей, и даже небольшие ошибки в настройке могут привести к неоптимальной производительности или непреднамеренным последствиям, таким как синхронизированные отбрасывания. Эти ограничения и особенности привели к разработке усовершенствованных или специализированных вариантов. Один из таких вариантов, Flow-based RED, был представлен на коммутаторах серии Catalyst 4K. С моей точки зрения, он использует более детальный подход, управляя перегрузкой на уровне потока, а не на уровне совокупной очереди, обеспечивая более тонкий контроль над отдельными потоками и потенциально решая некоторые проблемы справедливости WRED. Спасибо за обсуждение. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.