Как именно WRED помогает избежать перегрузок?

[Joseph W. Doherty]

Кстати, для понимания может быть полезно узнать, для решения какой проблемы был разработан алгоритм RED, который, кстати, справляется с этой задачей довольно хорошо. В первые дни существования Интернета порты маршрутизаторов с одной FIFO-очередью часто переполнялись, что приводило к потере нескольких потоков. Это часто вызывало
глобальную синхронизацию скорости TCP
. RED также был разработан для обработки небольших объемов данных. Корпоративные сети обычно не передают такой же объем одновременных потоков, и мы можем использовать несколько очередей, например, сбрасывая пакеты сначала из менее важного трафика, чтобы избежать исчерпания ресурсов буфера. К сожалению, в большинстве учебных материалов по QoS это не рассматривается, и создается впечатление, что его стоит использовать без особого раздумья.

[Ramblin Tech]

Дополняя ссылку Джо на синхронизацию скоростей TCP... Теоретически, WRED может запускать отдельные потоки TCP для более плавного и постепенного снижения предлагаемой нагрузки, чем одновременное снижение нагрузки многих потоков, как в случае с tail-drop. Но это предположение основано на том, что большая часть интернет-трафика по-прежнему приходится на TCP. Это предположение было подтверждено многими исследованиями трафика несколько лет назад, но некоторые
исследования
сейчас показывают, что TCP больше не доминирует, как раньше. Вместо этого в будущем (или даже сейчас) преобладающим может стать трафик DNS и QUIC (оба на основе UDP). Что будет означать переход объема интернет-трафика с TCP на UDP для внедрения WRED, которое зависит от того, что потоки TCP взаимодействуют друг с другом справедливо (т. е. не захватывают больше, чем их справедливая доля пропускной способности)? Я не имею представления, но мне было бы очень интересно увидеть академические исследования о влиянии WRED на QUIC (я примерно на 4 года отстаю в просмотре журналов ACM и IEEE в этой области, поэтому они, возможно, уже опубликованы). Отказ от ответственности: я давно работаю в CSCO. Неправильные ответы — моя вина, так как они не генерируются ИИ.

[Joseph W. Doherty]

@Ramblin Tech
написал:
Теоретически, WRED может запускать отдельные TCP-потоки, чтобы сдерживать их предлагаемую нагрузку более постепенно и плавно, чем при одновременном сдерживании многих потоков, как в случае с tail-drop. Да, это теория. На самом деле, это возможно для потоков TCP. @Ramblin Tech
написал:
Что означало бы переход объема интернет-трафика с TCP на UDP для внедрения WRED, которое зависит от того, что TCP-потоки взаимодействуют друг с другом справедливо (т. е. не захватывают больше, чем их справедливая доля пропускной способности)? Ну, я действительно читал исследования по сравнению TCP и UDP, и TCP обычно проигрывает, но это очень изменчиво, потому что некоторые приложения, использующие UDP, имеют собственное управление потоком, а некоторые — нет. Использование сети без какого-либо управления потоком часто приводит к серьезным проблемам с производительностью. TCP делает все возможное, чтобы быть действительно справедливым. Кроме того, он решает многие другие проблемы, на которые рассчитывают сетевые приложения, такие как надежная доставка данных. То есть с UDP каждому приложению приходилось «изобретать велосипед», в то время как TCP обеспечивает обычно желаемую надежность сети как часть своего протокола. На протяжении многих лет я видел «специальные» приложения для передачи данных, которые могли передавать данные быстрее, чем TCP, но при этом они, как правило, не учитывали справедливость и поэтому могли также перегружать сеть. Кроме того, несколько лет (десятилетий) назад я участвовал в изучении некоторых пакетов данных, связанных с проблемами производительности сети, и обнаружил, что серверы Google не строго придерживались медленного запуска TCP. Я не изучал QUIC подробно, но он, похоже, имеет некую форму управления потоком, которая может учитывать потерянные пакеты при принятии решений о скорости потока. Неясно, насколько хорошо он обрабатывает действительно массовые/крупные передачи данных по сравнению с другим одновременным трафиком. (Я подозреваю, что не очень хорошо, но тогда, конечно, APP может использовать TCP — и, безусловно, будет использовать.) Я упомянул о том, что Google не соблюдает правильный медленный запуск TCP, чтобы сделать их серверы более «отзывчивыми», чем серверы других конкурентов. То есть справедливость к черту. QUIC может быть вполне приемлемым, если вы можете обеспечить его пропускной способностью. В Интернете, безусловно, продолжает расти использование прикладного трафика, чувствительного ко времени, не только для таких вещей, как VoIP, но даже для транзакционных приложений, таких как просмотр веб-страниц. Чтобы все работало «быстро», требуется как пропускная способность, так и низкая задержка. Я знаю, что многие интернет-провайдеры сосредоточены на пропускной способности, пропускной способности и еще раз пропускной способности, чтобы избежать любых очередей. Если очередей нет, то, как правило, нет необходимости в QoS. Если же очереди есть, что является проблемой, то для ее решения требуется либо большая пропускная способность, либо QoS.

[MHM Cisco World]

Опять же, ни один QoS не может предотвратить перегрузку, он только контролирует, какие пакеты будут отбрасываться. Tcp может обнаруживать отбрасываемые пакеты (по серийному номеру пакета), но udp не может, поэтому все QoS начинают отбрасывать tcp-пакеты. QoS может помочь до определенного момента, после чего вам необходимо подумать об увеличении пропускной способности, которую вы получаете от SP, или заменить маршрутизатор на маршрутизатор с высокой пропускной способностью. MHM

[Joseph W. Doherty]

@MHM Cisco World
написал:
Опять же, ни один QoS не может предотвратить перегрузку, он только контролирует, какие пакеты будут отбрасываться.
Tcp может обнаруживать отбрасываемые пакеты (по серийному номеру пакета), но udp не может, поэтому все QoS начинают отбрасывать пакеты tcp.
QoS может помочь до определенного момента, после чего вам нужно будет подумать об увеличении пропускной способности, которую вы получаете от SP, или заменить маршрутизатор на маршрутизатор с высокой пропускной способностью.
MHM Я не согласен со всем, что сказано выше, потому что это, по-моему, общие утверждения, которые не всегда верны. В первом абзаце необходимо точно уточнить, что означают термины «перегрузка» и «QoS». Например, цель RED — избежать переполнения очереди, что многие считают «перегрузкой». Во втором абзаце все на 100 % верно: UDP сам по себе не заботится о потерях, как TCP. Но различные приложения, использующие UDP, часто заботятся о потерях. Таким образом, значимость потери UDP зависит и от приложения UDP. Другими словами, вы не знаете, какое влияние на UDP окажет потеря пакета UDP. Что касается последнего абзаца, то хотя QoS не устраняет всю потребность в дополнительной пропускной способности, он часто может устранить потребность в дополнительной пропускной способности. И наоборот, он может быть совершенно бесполезным. Таким образом, это более сложно, чем просто избежать потребности в дополнительной пропускной способности до определенной степени. Опять же, ваша формулировка очень общая и категоричная, а также подразумевает, что QoS дает мало преимуществ. Конечно, есть случаи, когда все вышесказанное верно, но, по моему мнению, есть и другие случаи, когда это не так.

[MHM Cisco World]

Хорошо, кто использует QoS? 1. SP для контроля пропускной способности для клиентов 2- Инженер VoIP, который хочет, чтобы его VoIP имел хорошее качество В обоих случаях это не
предотвращает
перегрузку, а
контролирует
ее. Есть разница. Окончательное решение проблемы перегрузки заключается в следующем 1- увеличения памяти интерфейса и/или внутреннего буфера ЦП 2- ускорение маршрутизатора при пересылке трафика за счет увеличения пропускной способности Спасибо, и поправьте меня, если я ошибаюсь MHM

[Joseph W. Doherty]

(Ваше решение) № 1 часто (изучите теорию очередей) работает только в том случае, если средняя предлагаемая нагрузка составляет 100 % или менее, и по мере приближения к 100 % можно получить очень и очень глубокую очередь. Предположим, у меня есть файл размером 1 ТБ и канал 100 Гбит/с к маршрутизатору, который имеет канал выхода 64 Кбит/с. Итак, вы предлагаете, чтобы интерфейс 64k имел выделенный буфер размером 1 ТБ? Вы когда-нибудь видели что-то подобное в действии? Какова средняя скорость передачи данных по каналу 100 Гбит/с с использованием TCP? 100 Гбит/с или меньше, ближе к 64 Кбит/с? Если последнее, то почему? Могу ли я что-то сделать на маршрутизаторе, чтобы повлиять на скорость передачи данных TCP? Вы, похоже, говорите, что нет, верно? Предположим, я могу повлиять на скорость передачи данных отправителя, например, не принимая весь файл объемом 1 ТБ со скоростью 100 Гбит/с. Не контролирую ли я при этом перегрузку интерфейса 64 Кбит/с? Предположим, что одновременно с вышесказанным другой хост хочет отправить VoIP? Если у меня есть только одна очередь, и я могу поставить в очередь 1 ТБ вместе с VoIP, будет ли VoIP работать нормально? Надеюсь, вы согласитесь, что нет. Но если я действительно могу повлиять на скорость передачи данных отправителем, скажем, я заставляю отправителя данных отправлять только 8 Кбит/с, будет ли тогда работать VoIP? Что касается (вашего решения) № 2, то, конечно, если мы получим достаточную пропускную способность, т. е. не будет переподписки, все будет в порядке. Итак, да, давайте заменим наш частный межконтинентальный канал p2p 64 Кбит/с на 100 Гбит/с. Смеетесь, вы покроете небольшую разницу в стоимости? О, я упомянул, что у нас есть более одного межконтинентального канала, не говоря уже о каналах на одном континенте? Если у вас есть опыт работы в средах SP, DC или LAN, то часто пропускная способность и/или простое QoS для поддержки трафика RT, такого как VoIP, сводят на нет расширенное QoS. Однако WAN часто имеют гораздо более ограниченную пропускную способность, иногда из-за того, что она просто физически недоступна, а возможно, чаще из-за стоимости. При недостатке пропускной способности QoS может быть очень полезен не только для поддержки таких вещей, как VoIP. Несколько десятилетий назад я работал в международной компании, которая имела офисы по всему миру. Самые низкоскоростные WAN-соединения были 64 Кбит/с, самые высокоскоростные, с которыми мне приходилось работать, были DS3/E3. LAN-соединения были гигабитными. Скажем так, перегрузка WAN-соединений была не редкостью. Более десяти лет я посвятил разработке эффективного QoS. Мой QoS предшествовал приложениям RT, таким как VoIP (хотя он и VidConf, наряду со потоковым видео, были добавлены). Стоило ли это того? Похоже, что я сэкономил как минимум 100 000 долларов в месяц на расходах на передачу данных, избежав увеличения пропускной способности, а жалобы пользователей на медленную работу сети значительно уменьшились. Было ли все это просто моим желанием? Не совсем, так как два других глобальных региона считали, что QoS нужен только для VoIP, и использовали ваш второй вариант. Однако они постоянно жаловались на дополнительные расходы, особенно потому, что их пользователи продолжали жаловаться на медленную сеть. Но теперь я раскрою главный «секрет» эффективного QoS — не все должно быть быстрым, но предсказуемым/ожидаемым/разумным. Например, если я загружаю огромный файл с сервера, я не удивляюсь, что это занимает больше времени, чем отправка электронного письма с текстом «Обед в полдень?». Но когда последнее иногда занимает больше времени, чем первое, пользователи очень недовольны.

[Joseph W. Doherty]

@Mitrixsen
, как я уже отвечал ранее, WRED вряд ли будет использоваться для устранения перегрузки между двумя очередями. Однако при использовании WRED (а не RED) ситуация совершенно иная для очередей одного класса! Предположим, у вас есть VoIP и FTP, смешанные в одной очереди FIFO. Вероятно, VoIP сильно пострадает, если FTP попытается занять всю доступную пропускную способность. Нормальным и гораздо более эффективным подходом было бы разделить VoIP и FTP на отдельные очереди и установить приоритет для очереди VoIP. В этом случае для очереди VoIP не имеет значения, используется ли WRED в очереди FTP (хотя это может повлиять на FTP). Но опять же, по какой-то странной причине мы ограничены только одной очередью, и наш единственный инструмент — WRED, поэтому VoIP вообще невозможен, верно? Ну, не обязательно. Предположим, мы настроим WRED так, чтобы он начинал случайным образом отбрасывать FTP-пакеты, когда их количество достигает 2 или более, и отбрасывал все FTP-пакеты, когда их количество превышает 6? Таким образом, мы более или менее гарантируем, что VoIP будет иметь перед собой только от 2 до 6 пакетов, а не 40 или более. Будет ли теперь работать VoIP? Это зависит от таких факторов, как пропускная способность порта, т. е. от того, насколько может задерживаться пакет VoIP. Помните, что VoIP имеет некоторую толерантность к задержкам (запаздыванию), джиттеру и даже отбрасыванию пакетов. Ах да, и еще один факт (который сводил меня с ума в начале моих экспериментов с QoS, поскольку я сначала не знал): интерфейсы Cisco часто имеют аппаратную очередь FIFO, и только ее переполнение может обеспечить приоритетное извлечение из очереди по политике QoS. (NB: что сводило меня с ума, встроенная аппаратная очередь FIFO приводила к тому, что моя политика QoS работала не очень хорошо. Как только я узнал об этой аппаратной очереди, ах, это объяснило плохой эффект QoS. К счастью, размер этой аппаратной очереди можно значительно уменьшить по сравнению с ее размером по умолчанию, что позволяет политике QoS работать эффективно. [Также обратите внимание: этот небольшой факт, о котором часто не упоминается в литературе по Cisco QoS, возможно, во многом объясняет, почему QoS не ценится очень высоко — поскольку аппаратная очередь FIFO, если ее размер не уменьшить, значительно снижает эффективность политики QoS.]) Итак, вышеприведенный пример демонстрирует использование WRED для предотвращения перегрузки интерфейса. (Под «предотвращением» для TCP-приложения, такого как FTP, подразумевается, что отбрасывание пакетов заставит отправителя снизить скорость передачи. Если бы другое приложение было основано на UDP, которое не имеет контроля скорости потока приложения, вход в маршрутизатор не изменился бы, но глубина очереди выходного интерфейса все равно осталась бы небольшой. Что касается глубины очереди интерфейса, то в последнем случае в очереди, вероятно, будет поддерживаться в среднем 6 пакетов, не относящихся к VoIP, тогда как в случае с FTP она будет колебаться в зависимости от фактической скорости передачи FTP. Опять же, огромная разница будет наблюдаться в «предлагаемой» скорости.) Кстати, я полагаю, что
@MHM Cisco World
ценит, что в сценарии, описанном выше, QoS может «контролировать» перегрузку как для TCP, так и для UDP. Однако QoS также может предотвращать перегрузку, каким-то образом «сигнализируя» отправителю о необходимости снизить скорость передачи. Классический TCP делал это, считая все потерянные пакеты результатом перегрузки (хотя они могли быть потеряны по другим причинам). Современные варианты TCP теперь также отслеживают всплески RTT и предполагают, что они вызваны перегрузкой. В любом случае TCP снижает скорость передачи вдвое или возвращается к медленному запуску. Многие другие приложения, не относящиеся к TCP, имеют свои собственные способы обнаружения и устранения перегрузки, а также реагирования на нее. Например, некоторые потоковые приложения переключаются на более низкое качество и снижают пропускную способность, требуемую для потокового видео. Насколько хорошо WRED будет взаимодействовать с ними, во многом зависит от приложения. Как отметил
@Ramblin Tech
, цель RED заключалась в том, чтобы попытаться плавно снизить скорость одного или нескольких потоков, а не резко ограничить все одновременные потоки. Однако некоторые из этих потоков, не относящихся к TCP, могут рассматривать потерю всего одного пакета не как перегрузку, а как следствие других причин, таких как повреждение данных во время передачи или временная ошибка маршрутизации пакета. В таких случаях они не будут замедляться и могут (а могут и не могут) повторно передать данные потерянного пакета. Я часто говорил, что QoS на самом деле не слишком сложен, но для его эффективного использования требуется широкий спектр информации. Я уже почти 8 лет на пенсии. Сходу я не могу сказать, как какая-либо методология отбрасывания пакетов повлияет на QUIC Джима, но если бы я собирался внедрить QoS для QUIC, я бы выяснил это, прежде чем писать политику QoS, которая обрабатывает такой трафик.

[MHM Cisco World]

Извините за запоздалый ответ QoS может сигнализировать партнеру о перегрузке очереди. Это не совсем верно. QoS от конца до конца, такой как rsvp, используется для резервирования определенной пропускной способности канала для VoIP, а не для предотвращения перегрузки. Просто хочу прояснить этот момент. Спасибо MHM

[Joseph W. Doherty]

@MHM Cisco World
написал:
Извините за запоздалый ответ
QoS может сигнализировать партнеру о перегрузке очереди.
Это не совсем верно.
QoS от конечной точки до конечной точки, такой как rsvp, используется для резервирования определенной пропускной способности канала для VoIP, а не для предотвращения перегрузки.
Просто хочу прояснить этот момент.
Спасибо
MHM Извините, по крайней мере для меня, неясно, что вы пытаетесь прояснить. Если вы говорите, что QoS всегда «сигнализирует» отправителю о перегрузке очереди, и это не совсем верно, я полностью согласен. Я не хотел это подразумевать, не думаю, что я действительно так написал, но, опять же, я определенно не хотел это подразумевать. Я говорю, что при перегрузке очереди технологии QoS часто могут «повлиять» на отправителя, заставив его снизить скорость передачи. Поймите, однако, что у меня очень широкое определение QoS. Например, возьмем ситуацию с одной глобальной FIFO-очередью на выходе. Могут ли быть соображения QoS? Я считаю, что да, в отношении того, насколько глубокой вы позволяете быть очереди, т. е. предела очереди. @MHM Cisco World,
как вы определяете, каким должен быть предел одной глобальной FIFO-очереди выхода? Вы когда-нибудь задумываетесь об этом или принимаете то, что устройство использует по умолчанию? Даже если вы используете предел очереди по умолчанию устройства, хм, вы думаете, что его значение было выбрано просто случайно? Затем мы также можем обсудить, что действительно составляет «сигнал». Должно ли это всегда быть что-то явное, например ECN, или потеря пакетов может косвенно служить сигналом (о перегрузке)? Последнее имеет некоторое отношение к теме WRED, потому что он отбрасывает пакеты, чтобы достичь определенного результата. Вы думали, что за значениями минимального, максимального, процента отбрасывания и вычислений времени нет никакой «науки»? Если за WRED стоит некая наука, считаете ли вы, что это невозможно даже для ограничения очереди FIFO? Если вы не знаете об этой науке, это неудивительно, потому что обычно QoS преподается как необходимое для VoIP и видео, и WRED можно использовать для «лучшего» отбрасывания, а для всего, что выходит за эти рамки, «нужна большая пропускная способность». Опять же, поскольку у меня широкий взгляд на QoS, вот реальная проблема, с которой я сталкивался. В то время я работал в международной компании, которая занималась «клонированием» баз данных по выходным через Северную Атлантику и имела ограничения по времени: данные клонированной копии должны были быть запущены и завершены в течение выходных. Изначально у них было несколько трансатлантических каналов T1/E1, но, как и в случае с Etherchannel, для репликации использовался только один путь, и его пропускной способности было недостаточно. Поэтому они обменяли свои каналы T1/E1 на один канал T3/E3, который, по их расчетам, имел достаточную пропускную способность, чтобы репликация была завершена в требуемые сроки. Проблема заключалась в том, что репликация отказывалась использовать всю доступную пропускную способность! Они сходили с ума, пытаясь понять, в чем проблема, поскольку в сети все выглядело нормально. Когда я узнал об этой проблеме, я сразу заподозрил, в чем дело, и предложил несколько способов ее решения. Они приняли мой подход, хотя сначала были в ужасе от моего предложения, но все же решили его попробовать. Это действительно решило проблему. Есть ли какие-либо идеи о первопричине и возможных решениях? Основная причина: [Спойлер]
(Выделите, чтобы прочитать)
LFN (длинная толстая сеть) BDP (продукт задержки пропускной способности)
LFN (длинная широкая сеть) BDP (произведение пропускной способности и задержки) Рекомендация Aghast: [Спойлер]
(Выделите, чтобы прочитать)
увеличить TCP RWIN на принимающем хосте с 16 КБ (по умолчанию) до 64 КБ
увеличить TCP RWIN на принимающем хосте с 16 КБ (по умолчанию) до 64 КБ Что касается RSVP для предотвращения перегрузки, то это не обязательно. Все, что он действительно делает, это определяет, доступна ли определенная пропускная способность от конца до конца, и если да, то гарантирует ее запрашивающей стороне. Запрашивающая сторона, по-моему, по-прежнему может свободно переподписываться на запрашиваемую пропускную способность от конца до конца. Я никогда не использовал RSVP, хотя концептуально понимаю его преимущества. Что-то похожее можно было бы сделать статически (и динамически?) с помощью ATM, используя его PVC в определенных режимах для определенного трафика, например, PVC, предназначенный для VoIP. Однако, если бы у меня было полное управление пропускной способностью, я бы обнаружил, что поддержка Cisco QoS почти всегда достаточна для достижения моих целей в области обслуживания без использования того или другого.