Миф о бесполезности QoS без перегрузки сети

По работе я несколько раз сталкивался с мнением, что настраивать QoS в не перегруженной ethernet сети не нужно для успешного функционирования таких сервисов, как IPTV и VoIP. Это мнение стоило мне и моим коллегам многих нервных клеток и часов на диагностику фантомных проблем, поэтом постараюсь как можно проще рассказать о том, почему это мнение неверно.

Меня зовут Владимир и я работаю сетевым инженером в одном из небольших ISP в Санкт-Петербурге.

Одним из оказываемых нами сервисов является L2VPN под транспорт IPTV потоков. На примере этого сервиса я буду вести рассказ.

Начинается всё с обращения в техподдержку от клиента-оператора с жалобой на качество IPTV — картинка сыпется («артефакты»), пропадает звук, в общем стандартный набор. IPTV у нас в сети классифицируется в очередь assured forwarding, поэтому диагностика заключается в том, чтобы пробежаться по железкам на маршруте и проверить, что в AF очереди на egress нет потерь, а на ingress нет физических ошибок. После этого мы бодро рапортуем клиенту, что в нашей зоне ответственности потерь не обнаружено, рекомендуем клиенту искать проблему у себя или поставщика IPTV, и идём пить чай с печеньем.

Но клиент давит и продолжает настаивать, что виноваты мы, а у него всё отлично. Мы проверяем всё ещё раз, смотрим корректность классификаторов и маркировку пакетов от клиента, завязывается диалог и на каком-то этапе задаём вопрос «а как у вас сконфигурирован QoS на сети?», на что получаем ответ «никак, у нас интерфейсы даже на 50% не загружены поэтому нам QoS не нужен». Тяжёлый вздох и поехали.

Обычно график загрузки на который все смотрят имеет интервал в 5 минут. Если «real time» — то несколько секунд, начиная от 1. К сожалению и к счастью, современное сетевое оборудование оперирует периодами не в 5 минут и не в 1 секунду даже, а пикосекундами. То, что в течении секунды интерфейс не был загружен на 100%, не значит, что он точно так же не был загружен и в течении нескольких миллисекунд.

Здесь мы приходим к концептуальному понятию — микробёрст(microburst). Это такой очень короткий период времени, когда количество принимаемых устройством данных становится больше чем интерфейс способен отправить.

Обычно первая реакция — как так?! Мы же живём в эпоху скоростных интерфейсов! 10Gb/s уже обыденность, 40 и 100Gb/s внедряется повсеместно, а мы ждём уже 1Tb/s интерфейсы.

На самом деле, чем выше скорость интерфейсов, тем жёстче становятся микробёрсты и их эффект на сеть.

Механизм возникновения очень прост, я его рассмотрю на примере трёх 1Gb/s интерфейсов, где трафик из двух из них уходит через третий.

image

Это единственное необходимое условие для возникновения микробёрста — чтобы скорость входящих (ingress) интерфейсов превышала скорость исходящего (egress) интерфейса. Ничего не напоминает? Это же традиционная схема уровня агрегации в ethernet сети — множество портов (ingress) сливают трафик в один аплинк (egress). Так строят сети абсолютно все — от операторов связи до дата-центров.

У каждого egress интерфейса есть очередь отправки tx-ring, которая представляет из себя кольцевой буфер. Туда складываются пакеты для отправки в сеть и конечно же этот буфер имеет конечный размер. Но у ingress интерфейсов на отправляющей стороне тоже есть такие же кольцевые буферы, которые обеспечивают такой-же line-rate. Что произойдёт, если они начнут отправлять трафик одновременно? У нашего egress интерфейса не хватит места в его tx-ring, так как заполняться он будет в два раза быстрее, чем он способен отправлять пакеты. Оставшиеся пакеты нужно где-то хранить. В общем случае это другой буфер, который мы называем очередью (queue). Пока в tx-ring нет места, пакет хранится в очереди и ждёт свободного места в tx-ring. Но вот беда — у очереди память тоже конечна. Что произойдёт, если ingress интерфейсы работают на line-rate достаточно долго? Память в очереди тоже закончится. В этом случае новому пакету уже негде храниться, и он будет отброшен — такая ситуация называется tail drop.

Сколько времени нужно, чтобы такой сценарий стал реальностью? Давайте посчитаем.

Самое сложное — это найти ёмкость буфера интерфейса. Вендоры не очень активно публикуют такую информацию. Но возьмём, для примера, период в 200ms — дольше держать пакет в очереди обычно смысла не имеет, да и это уже очень много.

Для 1Gb/s интерфейса нам потребуется (1000000000 * 0.2) / 8 = 25MB памяти. Сколько времени нужно работать на line-rate двум 1Gb/s интерфейсам, чтобы полностью забить буфер? 200ms. Это время за которое передаются 25MB со скоростью 1Gb/s. Да, ingress интерфейсов то у нас два, но egress интерфейс то тоже без дела не сидит и отправляет данные с той же скоростью, поэтому 200ms.

Это сравнительно много. А 10Gb/s ingress интерфейсу сколько времени понадобится чтобы перегрузить 200ms буфер 1Gb/s интерфейса? ~22ms. Это уже ощутимо меньше.

А сколько нужно памяти, чтобы хранить 200ms для 10Gb/s интерфейса? Уже 250MB. Это не то чтобы много по современным меркам, но ветер дует именно в эту сторону — скорости растут, и чтобы сохранять глубину буфера требуется всё больше и больше памяти, что выливается в инженерные и экономические проблемы, а чем меньше буфер тем быстрее микробёрст забьёт его.

Получается вечный вопрос для инженеров вендоров — сколько памяти давать интерфейсу в железе? Много — дорого и каждая следующая миллисекунда становится бессмысленнее и бессмысленнее. Мало — микробёрсты будут приводить к большим потерям пакетов и жалобам от клиентов.

Для других сценариев можете посчитать сами, но итог всегда один и тот же — полностью забитая очередь и tail drops, а на графике полкой интерфейса и близко не пахнет, причём на любом периоде — что в 5 минут, что в 1 секунду.

Эта ситуация в пакетных сетях неизбежна — интерфейс проработает на line-rate меньше секунды, а потери уже будут. Единственный способ её избежать — строить сеть так, чтобы ingress скорость никогда не превышала egress скорость, а это непрактично и нереально.

Дальнейшая логика уже прослеживается и достаточно очевидна. Потери пакетов есть, а QoS не настроен — приоритетный трафик никак не классифицируется и не отличается от другого трафика, и попадает в одну общую очередь, где он имеет равные шансы быть дропнутым.

Что делать? Настраивать QoS. Обязательно классифицировать приоритетный трафик и помещать его в отдельную очередь которой выделять бОльший объём памяти. Конфигурировать алгоритмы отправки пакетов так, чтобы приоритетные пакеты попадали в tx-ring раньше других — таким образом их очередь будет очищаться быстрее.

Например, мы в своей практике используем следующий подход к очередям:

Assured forwarding(AF) — «подержи но доставь». В AF очередь классифицируется трафик, который требует гарантированной доставки, но не чувствителен к задержкам. Этой очереди выделен большой объём памяти, но даётся сравнительно мало места в tx-ring, и пакеты туда попадают позже других. Яркий пример такого трафика это IPTV — он буферизиуется на клиенте(VLC или STB), поэтому его можно задержать, но потеря превратится в артефакт изображения.
Expedited forwarding(EF) — «доставь мгновенно или выброси». Этой очереди выделятся минимум(или вообще никакой) памяти для очереди, но выставляется высший приоритет для попадания в tx-ring, чтобы пакет был отправлен как можно быстрее. Пример трафика — VoIP. Голос нельзя доставить поздно, иначе и кодек телефонии не сможет его корректно собрать — абонент услышит кваканье. В то же время потери отдельных пакетов на общем качестве голоса сильно не сказываются — он у людей итак не идеальный.
Есть ещё network control(NC) и best effort(BE), для управления сетью и всего остального соответственно, а трафик бывает ещё, например, телеконференции, который представляет из себя гибрид между VoIP и IPTV, но это уже совершенно отдельная тема, и настраивать QoS для них следует отдельно в каждой сети, в зависимости от топологии и прочих факторов. Всё вместе в целом это выглядит примерно так(картинка с сайта Cisco):

image

Надеюсь теперь вы будете настраивать QoS в своей сети?
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 33

    0
    Мне кажется, сеть, в которой микробёрсты случаются постоянно, уже нельзя назвать на 100% не перегруженной.
    Поэтому рекомендуется не только включать QoS, но и не превышать oversubscription, который, если мне не изменяет память, составляет 1:20 для пользователей и 1:4 для аплинков.
      +1
      Что значит постоянно? В посте показаны очень большие цифры, если мы возьмём буфер, например, 4Мб, то он может быть отослан за 33ms.

      При этом если свитч не на два порта (как в примере в посте), а, например, на 24, то если половина портов утилизует одновременно треть доступной полосы (в интервале 33мс), то буфер будет заполнен за 8ms. А отправлять буфер можно за 33ms. То есть в течение 33-8=25мс пакеты будут дропаться.

      При этом если сами бёрсты мелкими и с большой скважностью (например, два микробёрста в секунду), при средней утилизации в 30%, то мы будем иметь два выпадающих квадратика в секунду при формальной утилизации в 30%.

      Заметим, изменение размера буфера с одной стороны ситуацию улучшает, с другой стороны на коммутаторах бывает и 48 портов, а в этом случае всё ещё хужее.
        0
        Так это и получается слишком большой коэффициент переподписки и его последствия.
          0
          Ну, 48, допустим, это много. Но, если у нас 24 порта и гигабитный аплинк — это ок?

          А если у нас 48 10G портов с аплинком в интернеты в 4х10Гб — это «слишком большой коэфицент переподписки»?
        +3
        Мне кажется, сеть, в которой микробёрсты случаются постоянно

        Они в любой сети случаются постоянно. Ну где есть TCP. У кого-то бывают и всплески на сотни тысяч pps сплошь из SYN пакетов, если сеть завирусованная.
        но и не превышать oversubscription, который, если мне не изменяет память, составляет 1:20 для пользователей и 1:4 для аплинков.

        Эти цифры условны. У меня в крупных офисах переподписка (сейчас посчитал) около 1:10000. Умирают ли они? Нет, всё прекрасно — утилизация боттлнеков небольшая и роутерный QoS отрабатывает хорошо.

        И в ЦОДе бывает 1:48. Опять же, надо к вопросу с умом подходить, исходить из задач. Где-то 1:1.3 будет вызывать проблемы.

        sherv, хорошая, годная статья, приятно читать. Добро пожаловать в писатели :)
        0
        Спасибо. Только 200ms задержки мне кажется сильно оптимистичная оценка. Я имею в виду, что большинство коммутаторов роняют пакеты много раньше.
          +2
          Именно так. 200ms было просто взято для примера.
          Реальные порядки куда менее радужные. Как пример для одного из вендоров — на 24 1G порта выделяется ~2.5MB памяти под буферы в сумме. Я не знаю в деталях как эта память делится между портами, но если предположить топорный сценарий с фиксированным выделением 100KB под каждый порт — для перегрузки и начала потерь хватит бёрста длительностью меньше 1ms.
            +1
            Я не знаю в деталях как эта память делится между портами

            Много вариантов. Например, может быть 24мб на всю коробку, shared buffer, динамически распределяющийся между портами.

            Где-то бывает ingress queueing, когда наполняются буфера на принимающих пакеты портах (если смотреть верхнюю картинку, то нижние два порта), а исходящий буфер на исходящем порту чисто символический и фактически не используется.
              0
              С моей точки зрения это более правильно. Если сеть быстрая, легче кадр перепослать (силами tcp), чем ждать 200мс внезапной задержки.
            –1
            Неужели нашелся в спб хоть один оператор знающий про microburst?
            Удивительное рядом…
              +4
              Наверное, тут стоит задуматься о качестве современного образования. У меня нет профильного образования, но то что я слышал от коллег и знакомых — людей учат старым технологиям, которые уже давно не актуальны, плюс преподавательский состав не имеет современной боевой практики. Вот и не может никто рассказать толком про такие тонкости.
                +2
                У меня тоже образование не из связи. Однако дорогу осилит идущий. И рассказать много кто может, были бы достойные слушатели.
                Но как показывает практика учиться никто не хочет. Ни связи, ни мэнеджменту, ни остальному. И это какой-то бич питерских телекомов.
                Инерция сознания…
                  –1
                  Ну-ну-ну… Не обобщайте все питерские телекомы.
                    +1
                    Пишу о том, что видел. У большинства кадры или выросшие на самоподготовке, или продукты Бонча. Второе — беспросветный 3.14zдец. Большинство вменяемых инженеров — понаехи, причем с образованием по типу бывшего СССР.
                  0
                  На мой взгляд старые технологии актуальны до сих пор. По сути, идеология создания процессорной техники не сильно меняется уже очень долгое время (закон Мура пока в действии). Современные воплощение, по сути, экстенсивно расширили это на сотни порядков, следуя классическим принципам — ускорения, распараллеливания, конвейеризации и специализации. Конечно спорить с фактом об общем падении уровня образования и оторванности институтов от реальных проектов, я не буду. То есть применить свои знания, если они вдруг есть, теории к практике очень сложно, потому что практика так и осталась основана на той же теории, но выглядит фантастически в её современном воплощении.
                  microburst это стык как раз связи и выч.техники и больше тут именно выч.техники, не имея профильного образования по связи, а именно по выч.технике, и некоторую часть обучения проведя за стендами с временными диаграммами, понимать что 1 секунда это как средняя температура по больнице, очень просто.
                  А связь, посмотрим что SDN принесёт в отрасль, возможно это будет тот самый качественный переход.
                +3
                А это сетевой нейтралитет не нарушает кстати?

                Так можно начать давать приоритет ssh на http/https, затем приоритет http над торрентами например.

                И ещё глупый вопрос, нужно ли заниматься настройкой QoS на WiFi-роутере конечному пользователю? (при условии что роутером пользуется один человек)
                  +3
                  В некотором смысле наверное можно сказать что нарушает, но в данной ситуации это происходит не для прямого извлечения выгоды, а просто для нормального оказания услуги — это техническое нарушение. Реальным нарушением духа понятия нейтралитета будет предпочтение трафику одного сервиса одного поставщика перед другими. То есть если у вас дата-центр где все хостят веб-приложения, и кому то из них вы за плату предоставляете приоритет. Кто-то скажет, что это нормальные рыночные отношения, и будет по своему прав, но это отдельная тема, и я бы не хотел растекаться мыслью по комментарию.
                  Подводя итог скажем так — нейтралитет понятие придуманное людьми, а мы живём в макромире. Оборудование работает в своём микромире, и там понятие нейтралитета из нашего макромира не имеет смысла.

                  WiFi в этом сценарии ничем не отличается от проводных сетей — потери происходят не в воздухе же, а конкретно в железе. Если у вас там есть условия для возникновения микробёрстов то для защиты от них QoS настраивать надо. Но с одним абонентом это сравнительно маловероятно, да и на качество WiFi в большей степени действуют другие факторы, например соседские эксперименты с разобранной микроволновкой.
                    0
                    Поддерживаю вопрос.
                    • UFO just landed and posted this here
                        0
                        нормальный там синтаксис, просто сам предмет мозголомный, и толком никем не понмаемый

                        А так, уверяю вас, многие семьи спасло бы от разрушения управление исходящим трафиком (что вполне доступно на openwrt на куче железа) в виде постановки раздаваемых торрентов в последнюю очередь, чтоб ютуб у других не тормозил из-за потеряных ackов.
                        • UFO just landed and posted this here
                      0
                      Столкнулся с этим в Ростелекоме (Реутов).
                      Когда раньше был в БилайнТВ, то всё работало через роутер даже без отдельного свитча.
                      В ростелекоме же даже на тарифе 50мбит стоит начать что-то качать, как IPTV начинает квадратить. Zyxel Keenetic Giga 2, IGMP proxy.
                      Техподдержка не может сказать, используется ли QoS, есть ли Vlan Id. Их рекомендация использовать IPTV на отдельном порту бессмысленна, так как 3 точки тв+интернет выливается уже в 6 портов.
                      • UFO just landed and posted this here
                          0
                          Очень зависит от схемы сети и района. В некоторых да, но вот представьте что у вас сеть на GEPON по FTTH, классический OLT на сегодня — это 4 аплинка (в лучшем случае, я обычно встречаю 1-2) по 1GB и 256 абонентов на ONUхах тоже гигабитных итого соотношение 1:64 а теперь представьте что время футбольного чемпионата и народ смотрит один и тот же канал в FullHD массово. Тут без калькулятора можно посчитать что будет с аплинком при использовании TCP-HTTP, его зальет под крышку и у всех все будет тупить, при использовании мультикаста провайдер даже не заметит особого роста трафика на аплинке, так что для разных сетей разные технологии.
                          • UFO just landed and posted this here
                              0
                              Рамок нет, мы например отдаем и так и так, в районы на волокне в отдельный порт ONU мультикастом, в районы на меди гоним через астру по http, при этом если у абонента вдруг проблемы с роутером за 300 рублей после ONU (отдельный вопрос нахрена он там), то отдаем и ему по http, этот вопрос решается по заявке, но таких абонов около 2% на волоконном секторе. С точки зрения инженера нет серебряной пули, очень зависит от района, типа подключения, типа железа и еще хреновой кучи факторов, если мы хотим давать именно качественный канал а не просто услугу для вида, так что и микроберсты считать приходится и размеры буферизации для http и кос крутить и затухания на волокне учитывать и еще около 40 параметров мониторить с каждого порта абонента. По поводу плееров, мы рекомендуем абонентам список конкретных моделей плееров, под которые есть своя прошивка и медиапортал, список можно как узнать по телефону техподдержки так и на сайте + в офисе компании их же продаем через офис, для тех кто не хочет заморачиваться с перепрошивкой так что модели гарантированно протестированы с мультикастом. Если абонент привез с али не понятный свисток за 5$ то ему ни один провайдер не гарантирует качественный IPTV по любой технологии, так как эти чудеса массовой промышленности вообще не тянут HD каналы и тут как не отдавай будет и картинка сыпаться и звук крякать. В общем не такое оно черно-белое как вам кажется.
                              • UFO just landed and posted this here
                                  0
                                  а чего у астры дурацкого в дефолтах и рекомендациях?
                                  • UFO just landed and posted this here
                                      0
                                      да, 256 килобайт это маловато. Может подойдет для старых приставок на локальной сети с гопом в 1 секунду.
                                      • UFO just landed and posted this here
                          +1
                          По поводу размеров и конфигурации буферов в различных коммутаторах есть вот такая таблица: http://people.ucsc.edu/~warner/buffer.html

                          Конечно, сделали её «по слухам», но на безрыбье и такие сведения могут оказаться полезны.
                            0
                            Очень интересная табличка, спасибо. Хорошо показывает тенденцию, что единого стандарта нет, и каждый вендор делает на своё усмотрение.

                          Only users with full accounts can post comments. Log in, please.