Техническая осуществимость QoS в нисходящем потоке

Я работаю для VoIP-провайдера, и одним из самых больших проблем, с которыми я имею дело, является управление потоком трафика.

Нашим флагманским продуктом являются QoS-совместимые пакеты T1 или SHDSL, настроенные для поддержки нашего собственного VoIP-сервиса. Мы строим политики QoS на нашем пограничном маршрутизаторе, которые сортируют наш голосовой трафик в очередь с наивысшим приоритетом, и этот продукт очень эффективен. Когда схема построена правильно, клиент ничего не может сделать, чтобы помешать их качеству звука.

Что меня беспокоит, так это то, что я получил много средств от других сетевых инженеров, ИТ-техников и т. д., которые считают, что можно сделать такой сервис, как эта работа, без кросс-маршрутизатора QoS. Я не чувствую, что это практично. Я хотел бы объяснить свое понимание, и я надеюсь, что у кого-то есть время совать дыры в нем, если они есть. Прошу прощения за длительный вопрос.

Возьмем схему Comcast. Я не работаю для Comcast, поэтому я размышляю над их построением сети, но я думаю, что это что-то вроде этого:

Фирмы Comcast поддерживают до кросс-маршрутизатора Cisco, а оттуда подключаются к их головной станции. Каждый клиентский IP-адрес построен на граничном маршрутизаторе с заданной пропускной способностью ниже 30 мбит /с, что выделяет им очередь в 30 мегабит плюс некоторый процент накладных расходов (я не знаю, насколько это типично).

Предположим, что подписчик загружает 40-мегабайтный файл с большого корпоративного сервера. Они нажимают на загрузку, TCP-соединение устанавливает и запускает процесс медленного запуска, но через несколько секунд сервер проталкивает более 30 миллионов данных. Это заполняет очередь на пограничном маршрутизаторе и начинает отбрасывать пакеты.

В этот момент уклонение от переполнения TCP запускается и начинает замедлять передачу в соответствии с доступной полосой пропускания, но, очевидно, голос уже разрушен.

Теперь мне сказали, что маршрутизаторы с входящими QoS-политиками могут использовать механизм предотвращения переполнения TCP, отбрасывая ACK для того, чтобы получить входящий трафик. Я никогда не видел этого на практике или, по крайней мере, никогда не видел, чтобы он работал; это реальная вещь? Если да, то это эффективно? Разве это не приведет к запуску упавших пакетов каждый раз, когда новое соединение увеличится до скорости, прежде чем алгоритм перегрузки может начать замедлять работу?

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

В частности, вы когда-нибудь лично видели метод QoS, который позволял VoIP работать без постоянных проблем с качеством на часто насыщенном интернет-соединении без QoS, предоставляемого провайдером? Вы когда-нибудь слышали о провайдере DSL или кабельного провайдера, использующем QoS пограничного маршрутизатора для такого приложения? Я только когда-либо слышал о том, что предлагалось как часть продуктов MPLS, является ли это в значительной степени необходимостью, если кто-то хочет вниз QoS?

4 голоса | спросил Daniel Thompson 11 22014vEurope/Moscow11bEurope/MoscowTue, 11 Nov 2014 04:12:56 +0300 2014, 04:12:56

1 ответ


4
  

Теперь мне сказали, что маршрутизаторы с входящими QoS-политиками могут использовать механизм предотвращения переполнения TCP, отбрасывая ACK для того, чтобы получить входящий трафик. Я никогда не видел этого на практике или, по крайней мере, никогда не видел, чтобы он работал; это реальная вещь? Если да, то это эффективно? Разве это не приведет к запуску упавших пакетов каждый раз, когда новое соединение увеличится до скорости, прежде чем алгоритм перегрузки может начать замедлять работу?

Я сомневаюсь в этом, конечно, для очередей, поскольку они относительно дружественны к TCP. Некоторые маршрутизаторы могли бы попробовать эту стратегию для создания дружественных tcp-политиков, но я сомневаюсь, что это было бы достойным решением. Прежде всего, ACK может сопровождаться данными, поэтому вы не можете просто отказаться от «ACK». Во-вторых, даже если это верно для некоторых потоков, почему бы вам отказаться только от обратного пути? Для потока TCP так же просто просто удалить исходные данные, и таким образом вы не тратите трафик и ресурсы обработки между вашим пограничным маршрутизатором и получателем.

Скорее всего, будет иметь H-QoS с очередью /планировщиком 30 Мбит /с на уровне схемы /пользователя, а затем в нее будут входить несколько очередей меньшего уровня. Простой настройкой может быть предоставление как TCP, так и UDP-каналов в две разные очереди в 25 Мбит /с, поэтому TCP все же может оставить 5 Мбит /с для UDP и наоборот. Конечно, существуют более сложные варианты.

Также учтите, что ssthresh обычно адаптируется довольно быстро к вашей доступной полосе пропускания (здесь 30 Мбит /с - ваш голос BW). Хотя TCP не перестает увеличивать cwnd в ssthresh, это будет только медленно возрастать и нарушать поток голоса только незначительно, когда будет достигнуто скопление. Тем не менее, в начале TCP-соединения, прежде чем ssthresh адаптирован к реалистичному значению, это, вероятно, значительно нарушит ваш поток голоса (хотя и скоро). Наконец, хотя он может работать нормально только с несколькими потоками TCP, когда кто-то запускает 100-е TCP-соединения (например, приложение P2P), становится все труднее. Вряд ли все значения ssthresh и cwnd стабилизироваться (быстро), чтобы гарантировать справедливость, даже больше, если эти соединения довольно изменчивы (как это часто бывает с P2P).

Кроме того, рядом с капли отмечают, что насыщенное соединение также негативно влияет на ваш дрожание, иногда это может быть проблематично (или даже хуже), чем несколько падений пакетов.

  

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

Вы на 100% правильны, UDP не обладает честностью. Многие мультимедийные приложения реального времени (voip, видеоконференции, ...) все еще используют UDP. Туннели (например, для VPN) также обычно используют UDP, чтобы избежать конфликтов таймера повторной передачи TCP-in-TCP. Так что да, конечно, у вас наверняка будет довольно высокий высокоскоростной UDP-трафик на соединение.

  

В частности, вы когда-нибудь лично видели метод QoS, который позволял VoIP работать без постоянных проблем с качеством на часто насыщенном интернет-соединении без QoS, предоставляемого провайдером? Вы когда-нибудь слышали о провайдере DSL или кабельного провайдера, использующем QoS пограничного маршрутизатора для такого приложения? Я только когда-либо слышал о том, что предлагалось как часть продуктов MPLS, является ли это в значительной степени необходимостью, если кто-то хочет вниз QoS?

Ну, вот вопрос, конечно, если многие современные интернет-соединения часто насыщаются. По моему опыту, доступный BW для фиксированного соединения часто превышает среднее использование. Всегда есть исключения, но, как правило, основная масса людей имеет множество BW, она все равно может быть насыщена где-то, но нечто часто в вашей схеме прямого доступа. Тем не менее, вы можете столкнуться с этим чаще в мобильном доступе, так как это низкоуровневая среда с низкой пропускной способностью. В настоящее время 4G помогает много, но это будет продолжаться так долго, пока мобильное использование BW все еще сильно растет.

Да, я слышал, что провайдеры внедряют QoS для мультимедийных приложений. Для каких приложений, которые могут сильно отличаться от поставщика к провайдеру. Предположим, что они просто квалифицируют трафик как BE, если нет веских оснований для этого. Но некоторые могут безразлично расставлять приоритеты SIP /RTP.

MPLS, безусловно, не является необходимостью для QoS, любой приличный BNG сегодня также включает в себя довольно значительные варианты QoS.

ответил KillianDS 12 Jpm1000000pmMon, 12 Jan 2015 16:06:02 +030015 2015, 16:06:02

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132