WRED и глубина очереди

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:13 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:10:13 GMT

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

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:12 GMT

M02@rt37 — Sat, 14 Feb 2026 22:10:12 GMT

Вы абсолютно правы в том, что задним числом часто упрощается сложная и итеративная природа технологического развития. Многое из того, что мы сегодня считаем само собой разумеющимся в технологии, — например, протоколы, архитектура и принципы проектирования — родилось из необходимости, а не из заранее обдуманной элегантности. Ранние инженеры и разработчики не имели в своем распоряжении современных инструментов, обильных ресурсов или отточенных теорий. Они часто работали в жестких условиях, используя доступные в то время инструменты и знания для решения насущных проблем. Сделанный выбор был связан не столько с реализацией грандиозных планов, сколько с «достижением результата». В процессе они заложили основы, которые были усовершенствованы последующими поколениями, иногда сохраняя оригинальные конструкции просто потому, что они работали достаточно хорошо или получили широкое распространение... Ваша аналогия с путешествием к Южному полюсу особенно уместна. Первые экспедиции были не о эффективности или оптимизации — они были о выживании и открытиях. Точно так же ранние пионеры вычислительной техники исследовали неизведанную территорию, экспериментируя с подходами, которые иногда работали скорее по случайности, чем по замыслу. Итеративный характер прогресса означает, что сегодняшние «лучшие практики» часто являются вчерашними ситуативными решениями, отточенными и контекстуализированными задним числом. Когда я в своем предыдущем ответе упомянул такие аспекты, как простота, производительность и соответствие протоколам, это отражало отполированное представление о том, как мы анализируем и преподаем технологии сегодня. Но вы правы — эти концепции часто появляются после того, как что-то было построено и доказало свою функциональность. Ясность, которую мы приписываем историческим решениям, часто является ретроспективным описанием того, что в то время было серией прагматичных шагов, основанных на методе проб и ошибок. Понимание технологии требует не только технических знаний, но и признания человеческой изобретательности, ограничений и решимости, которые ее сформировали. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:11 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:10:11 GMT

[M02@rt37]
(действительно) очень вдумчивый и хорошо обоснованный ответ, который, по моему мнению, в основном неверный, когда речь заходит о «причинах», по которым многое было сделано именно так. Сегодня у нас есть умные наручные часы, которые могут иметь аппаратные ресурсы, намного превосходящие многомиллионные (в долларах того времени) мэйнфреймы, на которых я программировал, когда пришел в эту отрасль. Когда я пришел в эту отрасль, люди, с которыми я работал, использовали компьютеры еще в 60-х, а некоторые — в 50-х и, возможно, даже в 40-х годах, и, как и сегодня я слушаю таких людей, как я, я слышал из первых рук, насколько примитивными были компьютерные системы в предыдущие годы или десятилетия по сравнению с передовыми технологиями 70-х годов. Почему, например, мы можем вводить данные с перфокарт на терминалах CRT. Пойми это, чувак! Я считаю, что задним числом очень трудно оценить, как развивается технология, когда ты еще не нашел способ достичь чего-то и у тебя есть несколько возможностей. Черт, даже IP был лишь одним из возможных подходов к созданию сети. По моему мнению, в основном многие технологии создаются не на основе грандиозных планов, основанных на таких концепциях, как простота, производительность, согласование протоколов, а на основе возможного подхода, в значительной степени основанного на необходимости. Что-то работает, что-то нет, а что-то работает не очень хорошо. Улучшения приходят вместе с приобретенными знаниями, и улучшение может быть просто доработкой того, что уже эффективно используется, или совершенно другим подходом. Другими словами, рассмотрим разницу между личным путешествием из точки А в точку Б, между ежедневными поездками на работу и первой поездкой. В случае ежедневных поездок на работу можно довольно легко обдумать улучшения, такие как простота, сокращение времени и т. д., но в случае первой поездки основное внимание уделяется тому, как вообще добраться до места назначения, особенно если никто раньше этого не делал. Сегодня у нас есть научная база на Южном полюсе, куда мы доставляем людей и грузы. Но представьте, что вы хотели бы попасть на Южный полюс более ста лет назад, как бы вы туда добрались? (Смех, как вы вообще узнаете, что вы там?). Десятилетия назад я прочитал очень интересную книгу, в которой подробно описывались две первые экспедиции, достигшие Южного полюса, и, если вы не знаете, вторая из них не вернулась обратно. Я не уверен, что вышесказанное вообще отражает мою проблему или даже какую-либо из проблем, которые у меня есть с ответом
[M02@rt37]
, потому что на первый взгляд это отличный ответ, основанный на личном опыте, а также на очень небольшой части технического развития за полвека, и такое развитие не так однозначно, как его часто видят в ретроспективе.

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:10 GMT

M02@rt37 — Sat, 14 Feb 2026 22:10:10 GMT

Здравствуйте
[, @Mitrixsen] Спасибо, что открыли этот пост с таким вопросом. Причина, по которой глубина очереди измеряется в пакетах, а не в пропускной способности, заключается, на мой взгляд, в простоте и согласованности с тем, как TCP и другие транспортные протоколы обрабатывают перегрузку. Подсчет пакетов прост для сетевых устройств, поскольку позволяет избежать вычислительных затрат на отслеживание и суммирование пакетов разного размера в режиме реального времени. В высокоскоростных сетях, где очереди управляются в большом масштабе, эта простота обеспечивает эффективную обработку без ненужных задержек. Еще одним важным фактором является то, что алгоритмы управления перегрузкой TCP, такие как Additive Increase - Multiplicative Decrease, называемые «AIMD» [
https://www.geeksforgeeks.org/aimd-algorithm/
], работают на уровне пакетов. TCP реагирует на потерю пакетов или подтверждения, а не напрямую на использование пропускной способности. Измерение глубины очереди в пакетах позволяет WRED согласовываться с поведением TCP, обеспечивая эффективную сигнализацию перегрузки отправителям и помогая поддерживать стабильную производительность сети. Кроме того, использование пакетов в качестве метрики обеспечивает предсказуемый способ управления использованием очереди. Хотя размеры пакетов могут значительно варьироваться, модели трафика в большинстве сетей имеют тенденцию уравновешиваться с течением времени, с сочетанием небольших контрольных пакетов и больших пакетов данных. Этот эффект усреднения делает измерение на основе пакетов надежным приближением для глубины очереди в типичных сценариях... Напротив, измерения на основе пропускной способности могут быть более изменчивыми и приводить к нестабильности в управлении перегрузкой. Наконец, измерение пропускной способности создает практические проблемы. Использование пропускной способности в реальном времени может быстро колебаться, что затрудняет реализацию стабильных и оперативных механизмов предотвращения перегрузки. Метрики на основе пакетов предлагают более простую и последовательную альтернативу. В случаях, когда необходимо управление пропускной способностью, механизмы, такие как формирование трафика или контроль, используются вместе с WRED для обеспечения комплексного управления трафиком. В совокупности эти подходы обеспечивают баланс между простотой, производительностью и согласованностью с поведением протокола. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:09 GMT

MHM Cisco World — Sat, 14 Feb 2026 22:10:09 GMT

правильный queue-limit 5000 bytes/packets <<- this command change between two modes

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:08 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:10:08 GMT

«Допустим, мы резервируем 20 % пропускной способности нашего канала для определенного класса. Учитывая, что некоторые платформы используют глубину очереди в пакетах, не означает ли это, что если достаточное количество небольших пакетов заполнит очередь, произойдет тайлдроп, несмотря на то, что, возможно, определенный процент пропускной способности все еще доступен?» Конечно! В принципе, ничего (значительного) не должно произойти, если этот класс не превышает выделенные 20 %. Помните, что для передачи небольших пакетов требуется меньше времени, поэтому с помощью скользящего среднего RED не «видит» кратковременный всплеск небольших пакетов, а видит количество пакетов на основе среднего объема, независимо от размера пакетов. Я помню, что это основная причина использования скользящего среднего. На самом деле, это очень эффективный способ поддерживать высокую загрузку при попытке максимизировать пропускную способность. Что не совсем идеально подходит, так это различные гарантии уровня обслуживания, кроме долгосрочных средних значений. Например, предположим, что у нас есть VoIP и FTP, которые делят одну очередь, и с WRED вы обеспечиваете очень высокую вероятность отбрасывания для FTP. Как вы думаете, VoIP всегда будет работать хорошо? Если нет, то почему? Кроме того, каково влияние на трафик FTP, даже когда нет трафика VoIP? Хорошее, плохое, ни то ни другое? Почему? Вы затронули важную область QoS (статистические вероятности), которая часто игнорируется при преподавании QoS, а ее непонимание может привести к множеству неожиданных и нежелательных результатов. Мне всегда нравилась цитата: «Есть ложь, есть грязная ложь, а есть статистика». Это кажется правдой, когда вы не понимаете статистику. Сеть с максимальными усилиями можно сравнить с игрой в рулетку, но то, как вы играете, может в значительной степени «зависеть» от того, как вы делаете ставки и сколько раз подряд вы играете. (Как и в рулетке, мы можем «подстроить» игру [QoS], чтобы улучшить шансы или даже гарантировать желаемый результат).

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:07 GMT

Mitrixsen — Sat, 14 Feb 2026 22:10:07 GMT

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

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:06 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:10:06 GMT

Да, и опять же, я помню, что некоторые платформы для некоторых очередей также предлагают опцию задержки в миллисекундах. Почему эти опции появились сейчас, а не тогда? Благодаря прогрессу в области аппаратного обеспечения. Даже сегодня на многих программных маршрутизаторах часто наблюдается снижение пропускной способности при использовании функций QoS. Кстати, хороший способ узнать больше о сетевой топологии, не связанной с конкретным поставщиком, — это поискать информацию по этой теме в Интернете и/или Wiki. Часто Wiki достаточно хорошо объясняет сетевые технологии, но особенно полезны его внешние ссылки «см. также», «ссылки», «внешние ссылки» и т. д. Например, вы задаетесь вопросом о влиянии пакетов разного размера на RED, и, возможно, вы не первый, кто задается этим вопросом. Используя Wiki, быстро нашли:
Влияние пакетов разного размера на производительность RED
.

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:05 GMT

Mitrixsen — Sat, 14 Feb 2026 22:10:05 GMT

Я также случайно нашел это https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/qos/b-quality-of-service/m_qos-queue_management_and_congestion_avoidance.html ![Mitrixsen_0-1736017129680.png] Поэтому я полагаю, что
глубина очереди может быть измеряемая в байтах или в пакетах, в зависимости от платформы.

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:04 GMT

David Ruess — Sat, 14 Feb 2026 22:10:04 GMT

Здравствуйте, Ознакомьтесь с этим документом от Cisco: https://www.cisco.com/c/en/us/td/docs/ios/qos/configuration/guide/queue_depth.html#wp1054046 Особенно часть, где упоминается, что глубина очереди измеряется в пакетах. Я полагаю, что это связано с тем, что количество пакетов является окончательным, в то время как вы упоминаете, что пакет может иметь бесконечное количество размеров. Это может быть способом установления стандарта. Разумно понимать пакеты в вашей сети, так как это поможет вам разработать политики QoS. Это и настраиваемые значения, такие как MTU, помогают определить максимальный размер пакетов, проходящих по каналам связи. Надеюсь, это поможет -Дэвид

Reply to WRED и глубина очереди on Sat, 14 Feb 2026 22:10:03 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:10:03 GMT

Вероятно, потому что в то время, когда доктор Флойд опубликовал RED, пакеты было легко подсчитать, и они уже были поставлены в очередь как «элементы». Традиционно, даже базовая очередь FIFO подсчитывает что? В более поздних версиях IOS теперь есть опции для определения емкости очереди по байтам или максимальной задержке в миллисекундах. Я также могу упомянуть, что глубина очереди RED является скользящим средним, поэтому более мелкие пакеты будут быстрее увеличивать/уменьшать глубину очереди, т. е. RED может не «видеть» более высокие мгновенные глубины очереди и не отбрасывать эти более мелкие пакеты, как это было бы с более крупными пакетами. (NB: есть и другие проблемы, связанные с использованием скользящего среднего, на которых я не буду здесь останавливаться, но, опять же, действительно эффективное использование RED более сложно, чем это часто представляется.)