[uanog] switch's port buffers
Vladimir Sharun
vladimir.sharun at ukr.net
Tue Jan 4 19:44:24 EET 2022
Александр Василич,
Netflix - это сборище гиков в хорошем смысле слова. Они из любви к искусству доводят до технологического совершенства почти всё, до чего дотягиваются.
Т.е. нет, эти таки будут и моделировать и искать лучшие решения.
Из хорошего, так это то, что Netflix свои наработки отдаёт в комьюнити (FreeBSD как минмиум в частности).
Они сначала поставили себе цель 100G отдать с одного сервера (шифрованного, т.е. TLS), потом вышли на 200G (и тоже достигли). Это несколько отдельных задач: выдать столько трафа - это одна, сгенерить столько трафа - другая, пошифровать - третья. И всё это должно работать опережая сеть по скорости.
Просто в цифрах: надо выдать два с половиной гигабайта в секунду пошифрованного трафа.
Для справки можно заглянуть сколько стоят железки, которые могут сделать VPN на двести гиг, чтобы понять, через какой челленж они проходят.
4 січня 2022, 15:57:32, від "Alexander V Soroka" <alex at euro.net.ua>:
Привет !
Ваша всеобщая проблема сейчас в том, что вы "роетесь в мусоре" в
надежде найти там алмазы :-) а их там нет - есть только выбор между
плохим и совсем плохим.
Поясню о чем я.
1) Забугорные сетевые админы не станут вот это вот все (что мы сейчас)
обсуждать - они просто примерно посчитают или смоделируют "набросы
нагрузки" и выдадут запрос манагерам на "купить вот такойто свич".
Никто не будет выпиливать лобзиком, как привыкли мы(вы).
2) Мы тут и сейчас пытаемся "и рыбку и :-)". Причем за малые деньги...
А раз так, то меня надо слушать и смотреть именно в сторону FPGA
решений, даже мультичиповых, т.е. вплоть до разработки спец-печатной
платы с несколькими FPGA , и отдельной памятью для них, чтобы сделать
именно то что вы хотите сейчас, и спать спокойно что это все не
устареет завтра, и в случае чего нагибается под нечто новое по
сервисам-переделкам.
3) Главная проблема вас (тех кто сейчас в UANET ) админит, в том, что
вы не собираетесь ничего разрабатывать :-) вам нужно готовое
каличное(малобюджетное) решение на все сложные случаи.
А это там, на западе, никому не интересно, особенно в промышленных
коммерческих масштабах трафика - ПОТОМУ ЧТО там для коммерческого
просто считают деньги и покупают тот трактор который соответствует
огороду. И платит там Клиент не сущие копейки, так что "бюджет
развития" ненулевой.
Поэтому то что вы хотите найти как ГОТОВОЕ и кем-то поддерживаемое
решение, попросту НЕ СУЩЕСТВУЕТ, по причинам описанным мной выше.
Так что у вас есть очень хороший шанс стать первыми в этом пути, и
сделать то, что потом такие-же "слаборазвитые страны" у вас будут
покупать. Т.е. напрячься и родить коммерческий продукт.
Но это программисты нужны :-) а не Админы, которым лень писать код а
хочется только текст в конфигах ковырять :-)
Так что в итоге вся дискуссия превращается в "копание в сортах говна",
и повышения собственной эрудиции.
Извините за резкость, но со стороны (моей) это выглядит именно так...
Tuesday, January 4, 2022, 3:41:27 PM, Volodymyr Litovka doka at funlab.cc you wrote:
VL> Привет,
VL> перенаправление на другой dst ip/port - это задача app layer.
VL> Этим действием, теоретически, может являться как раз попытка
VL> использования другого маршрута (маршрутизатора, коммутатора и/или
VL> линейной карты) с целью использовать другой пакетный буфер. Но мне
VL> тяжело себе представить, как может абстрактный "нетфликс"
VL> рассчитывать, что где-то по дороге до абстрактного "бердичева"
VL> что-то может ходить разными путями или балансироваться по разным линейным картам / port groups.
VL> Вопрос заключается в том, что независимо от выбора устройства, в
VL> нем присутствует shared buffer для какой-то группы портов (все
VL> порты; сгруппированные внутри одного ASIC/FPGA; разобранные по
VL> отдельным линейным картам) и какова должна быть стратегия
VL> определения оптимального размера пакетного буфера, чтобы соблюсти
VL> компромисс между количеством требуемой памяти (читай - ценой
VL> устройства) и эффективностью доставки данных в условиях всплесков нагрузки.
VL> On 04.01.2022 15:31, Yevgen Ionov wrote:
>> Приветствую,
>>
>> В данном контексте ключевой фактор использование P4 для > программирования каких-то unusual tasks..
>> Использование FPGA архитектуры "на вырост" может быть не > оправданным, ввиду высокой стоимости отдельного свитча.
>> Cisco в качестве примера unusual task демонстрирует перенаправление > video stream каждые 20 sec на новый DST IP/Port, т.е. video-frame > после каждой 20 сек идет по новому path и это уже даже не TCP fields.
>> https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKDCN-2694.pdf
>>
>> Экстраполируя это на текущую дискуссию, возможно проблемы с > буферизацией на FGPA можно попытаться решить другими способами и > логику принятия решений можно переписать в отличие от ASIC & > pre-programmed logic in OS.
>> The behavior of the programmable blocks is specified using P4. The > Packet buffer and Replication Engine (PRE) and the Buffer Queuing > Engine (BQE) are target dependent functional blocks that may be > configured for a fixed set of operations.
>>
>> Но возникнут множество других вопросов, методология измерения, > управление потоками по всей топологии (потребуется контроллер, > например ONOS) и интеграция в с традиционными STP сетями.
>> Для меня все это теория и стало интересно обсуждается ли использование > P4 на практическом уровне или может кто-то пытался оценить в качестве > проекта для подобных задач.
>>
>> Спасибо.
>>
>> On Tue, 4 Jan 2022 at 13:09, Alexander V Soroka <alex at euro.net.ua> wrote:
>>
>> Привет !
>>
>> частично ответыт тут есть:
>> ASIC vs. FPGA: What’s the difference?
>> https://www.sondrel.com/blog/asic-vs.-fpga:-what%27s-the-difference
>>
>> Цитаты:
>> ...Термин ASIC является аббревиатурой от Application Specific
>> Integrated Circuit. Как следует из названия, ASIC - это интегральная
>> схема, разработанная для конкретного использования или приложения,
>> которую нельзя перепрограммировать или изменить после того, как она
>> будет произведена. ASIC разработан в соответствии со спецификациями
>> продукта и не предназначен для общего использования. Более
>> распространенным термином является SoC (система на кристалле), который
>> представляет собой ASIC, который действует как целая подсистема,
>> включая ЦП, память и периферийные устройства.
>>
>> ... FPGA (или всем знакомое ПЛИС) расшифровывается как
>> Field Programmable Gate Array. FPGA производится для общего
>> использования с
>> использованием настраиваемых логических блоков и программируемых
>> межсоединений. Это означает, что FPGA может быть запрограммирована и
>> перепрограммирована (в зависимости от типа FPGA) для выполнения многих
>> функций после ее изготовления.
>>
>> Типы ПЛИС
>> ПЛИС можно классифицировать двумя способами. Либо по их внутренней
>> архитектуре, либо по типу программируемой технологии. В рамках этих
>> двух классификаций существует несколько типов ПЛИС.
>> ...
>>
>> ЧТО Я могу сказать: с точки зрения "на вырост" я бы всегда выбирал
>> FPGA. Потому что технологии меняются, а ПО всегда можно переписать. У
>> майнеров есть несколько видео про то как FPGA делает некоторые виды
>> видеокарт, просто потому что можно "выпилить" внутри архитектуру
>> работы именно под то что вам нужно, и получить И аппартно заточенное И
>> программно заточенное решение. Оно по-любому будет быстрее чем
>> "примерно подходящее", но может проиграть "очень острозаточенному для
>> 1 операции".
>>
>> Я бы в проектах использовал только FPGA.
>>
>>
>> Tuesday, January 4, 2022, 1:59:15 PM, Yevgen Ionov
>> yevgen.ionov at gmail.com you wrote:
>> YI> Привет Максим,
>>
>> >> Из грустного: сколько нужно академиков, чтобы написать доклад
>> на 2
>> YI> страницы http://buffer-workshop.stanford.edu/papers/paper18.pdf
>>
>> YI> Беглый просмотр документа указывает на наличие инструментов для
>> YI> программируемых сетей (P4 Toolkit) & P4 programmable switches,
>> которые по
>> YI> своей архитектуре отличается от традиционных.
>> YI> И если я правильно понимаю данное обсуждение, речь идет о
>> традиционных
>> YI> ASIC-based свитчах с фиксированными размерами buffers.
>>
>> YI> Мне лично интересно понять:
>> YI> 1. Обсуждается ли тема в среде операторов использования
>> programmable
>> YI> switches & P4?
>> YI> С точки зрения управления flows, congestions, etc
>> использование P4 сильно
>> YI> отличаться от традиционного подхода и протоколов.
>> YI> На различных Telco презентациях об этом достаточно много
>> разговоров, но
>> YI> есть ли практическое развитие?
>>
>> YI> 2. Корректно ли сравнивать в данном случае выводы для
>> программируемой
>> YI> архитектуры FPGA vs традиционную ASIC-based архитектуру?
>>
>>
>> YI> Спасибо.
>>
>>
>> YI> On Thu, 30 Dec 2021 at 11:57, Maksym Tulyuk
>> <maksym at tulyuk.com> wrote:
>>
>> >> Привет!
>> >>
>> >> У меня совсем другие выводы:
>> >> 1) из последнего доклада "We still know very little about
>> buffer size” и
>> >> ИМХО это лучший вывод/совет
>> >> 2) все академики продолжают обсуждать TCP tuning и не хотят
>> видеть, что
>> >> уже в 2019 у Deutsche Telekom он составлял всего 84.4% (все
>> остальное - UDP
>> >> с быстрым ростом QUIC)
>> >> 3) все доклады рассказывают про MTU size 1500, хотя в реальном
>> мире такого
>> >> трафика 50% максимум https://stats.ams-ix.net/sflow/size.html и
>> как видно
>> >> из графика 35% - это пакеты размером 64-127 bytes
>> >>
>> >> Из интересного:
>> >>
>> >> - Understanding switch buffer utilization in CLOS data
>> center fabric
>> >> (Verizon)
>> >>
>> http://buffer-workshop.stanford.edu/slides/Understanding%20switch%20buffer%20utilization%20in%20CLOS%20data%20center%20fabric.pptx
>> >> - Buffer sizing and Video QoE Measurements at Netflix
>> >>
>> http://buffer-workshop.stanford.edu/slides/netflix%20buffer%20sizing.pdf
>> >> - Queueing at the Telco Service Edge (Deutsche Telekom)
>> >>
>> http://buffer-workshop.stanford.edu/slides/BS_QueueingEdge_2019_12_03.pdf
>> >> - Buffer Sizing Experiments at Facebook
>> >> http://buffer-workshop.stanford.edu/papers/paper30.pdf
>> >>
>> >> Из грустного: сколько нужно академиков, чтобы написать доклад на 2
>> >> страницы http://buffer-workshop.stanford.edu/papers/paper18.pdf
>> >>
>> >> НО это все было в 2019, а сейчас кажется что Гугл был прав и
>> будущее это
>> >> UDP+QUIC и все исследования на тему буферов нужно начинать с нуля.
>> >>
>> >> Максим
>> >> On 28 Dec 2021, 10:02 +0100, Volodymyr Litovka
>> <doka at funlab.cc>, wrote:
>> >>
>> >> Привет,
>> >>
>> >> для любителей лонгридов, есть прекрасная статья про стратегии
>> буферизации
>> >> и обработки очередей по результатам воркшопа в Стэнфордском
>> университете в
>> >> 2019 году - "*It hosted 98 attendees from 12 economies with 26 from
>> >> academia and 72 from industry.*" --
>> >> https://blog.apnic.net/2019/12/12/sizing-the-buffer/
>> >>
>> >> Для совсем уж любителей копать - материалы этого воркшопа
>> доступны тут:
>> >> http://buffer-workshop.stanford.edu/program/
>> >>
>> >> [ ... ] buffers also add additional lag to a packet’s transit
>> through the
>> >> network. If you want to implement a low jitter service, then
>> deep buffers
>> >> are decidedly unfriendly! The result is the rather enigmatic
>> observation
>> >> that network buffers have to be as big as they need to be, but
>> no bigger!
>> >>
>> >> Так какими же? :) Главные выводы из статьи:
>> >>
>> >> === 1. утверждение "буфер 40MB - отстой" не выдерживает проверки
>> >> академическими исследованиями ===
>> >>
>> >> A study by a Stanford TCP research group in 2004
>> >> <http://doi.acm.org/10.1145/1030194.1015499> used the central limit
>> >> theorem to point to a radically smaller model of buffer size. Link
>> >> efficiency can be maintained for N desynchronized flows with a
>> buffer that
>> >> is dimensioned to the size of:
>> >>
>> >> *Size* = (*BW* ∙ *RTT*) / √*N*
>> >>
>> >> This is a radical result for high-speed extended latency links
>> in a busy
>> >> network. The consequences on router design are enormous:
>> >>
>> >> “For example, a 1 Tb/s ISP router carrying one TCP flow with an
>> RTTmin of
>> >> 100ms would require 12.5 GB of buffer and off-chip buffering.
>> *If it
>> >> carries 100,000 flows, then the buffer can be safely reduced to
>> less than
>> >> 40MB, reducing the buffering and worst-case latency by 99.7%*.
>> With small
>> >> buffers, the buffer would comfortably fit on a single chip
>> switch ASIC.”
>> >> Nick McKeown et. al. Sizing Router Buffers (Redux)
>> >>
>> <https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/>
>> >>
>> >> иными словами, совершенно не случайно большинство коммутаторов
>> из списка
>> >> https://people.ucsc.edu/~warner/buffer.html в портовом
>> диапазоне 48x10/25
>> >> + 6-8/100 укомплектованы размером буфера 32-40MB - этого
>> достаточно. А если
>> >> учесть, что операторские реалии - это 1/10G агрегация (даже не
>> 25), то
>> >> можно предположить, что оператор is absolutely safe с буфером
>> такого
>> >> размера в своих коммутаторах.
>> >>
>> >> === 2. использование inline notification улучшает качество передачи
>> >> трафика ===
>> >>
>> >> The advantage of ECN is that the sender is not placed in the
>> position of
>> >> being informed of a congestion condition well after the
>> condition has
>> >> occurred. Explicit notification allows the sender to be
>> informed of a
>> >> condition as it is forming so that it can take action while
>> there is still
>> >> a coherent ack pacing signal coming back from the receiver
>> (that is before
>> >> packet loss occurs).
>> >>
>> >> However, ECN is only a single bit marking. Is this enough? [
>> ... ] The
>> >> conclusion from one presentation is that the single-bit
>> marking, while
>> >> coarse and non-specific is probably sufficient to moderate
>> self-clocking
>> >> TCP flows such that they do not place pressure on network
>> buffers, leaving
>> >> the buffers to deal with short term bursts from unconstrained
>> sources.
>> >>
>> >> [ ... ]
>> >>
>> >> And if we want to reduce buffer size and maintain efficient and
>> fair
>> >> performance how can we achieve it? One view is that sender
>> pacing can
>> >> remove much of the pressure on buffers, and self-clocking flows can
>> >> stabilise without emitting transient bursts that need to be
>> absorbed by
>> >> buffers. Another view, and one that does not necessarily
>> contradict the
>> >> first, is that the self-clocking algorithm can operate with higher
>> >> precision if there was some form of feedback from the network
>> on the state
>> >> of the network path. This can be as simple as a single bit
>> (ECN) or a
>> >> complete trace of path element queue state (HPCC).
>> >>
>> >>
>> >> всё же имеет смысл хотеть поддержки ECN
>> >>
>> >> === 3. flow-aware traffic management не является однозначной
>> заявкой на
>> >> успех ===
>> >>
>> >> If the network was in a position to be able to classify all
>> currently
>> >> active flows into either elephants or mice, then the network
>> could be able
>> >> to use different queuing regimes for each traffic class. This
>> sorting adds
>> >> to the cost and complexity of packet switches, and if scaling
>> pressures are
>> >> a factor in switch design then it’s not clear that the
>> additional cost of
>> >> switch complexity would be offset by a far superior efficiency
>> outcome in
>> >> the switching function.
>> >>
>> >>
>> >> === 4. и если вдруг вендора начинают говорить про гигантские
>> (напр 100ms)
>> >> буфера ===
>> >>
>> >> Further analysis reveals an estimate of packet drop rates if
>> the network’s
>> >> buffers were reduced in size, and for this particular case, the
>> analysis
>> >> revealed that an 18msec buffer would be able to sustain a
>> packet drop rate
>> >> of less than 0.005%.
>> >>
>> >>
>> >> Спасибо.
>> >>
>> >>
>> >> On 15.10.2021 14:48, Volodymyr Litovka wrote:
>> >>
>> >> Привіт,
>> >>
>> >> а ось тут мене запитали, а я не знаю як відповісти :) Я розумію, що
>> >> питання може звучати трішки дивно, але тим не менш -
>> >>
>> >> за вашим досвідом, скільки буферу (на порт або shared)
>> достатньо для
>> >> уникнення або зниження до непомітного рівня втрат пакетів при
>> появі traffic
>> >> bursts? Ну тобто цікавлять не теоретичні розрахунки після
>> відповідей на
>> >> питання на кшталт "а який час барста?", "а скільки складає барст у
>> >> відсотках до нормального" та таке інше, а по
>> робітничо-селянському -
>> >> поточний досвід в живій мережі в поточних умовах поточного
>> Інтернету? Ну,
>> >> наприклад, на будинковому комутаторі 24x1G + 2x10G з підключеними
>> >> середньостатистичними абонентами?
>> >>
>> >> Хтось взагалі цим питанням париться? :)
>> >>
>> >> Дякую.
>> >>
>> >> --
>> >> Volodymyr Litovka
>> >> "Vision without Execution is Hallucination." -- Thomas Edison
>> >>
>> >> --
>> >> Volodymyr Litovka
>> >> "Vision without Execution is Hallucination." -- Thomas Edison
>> >>
>> >> _______________________________________________
>> >> uanog mailing list
>> >> uanog at uanog.kiev.ua
>> >> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>> >>
>> >> _______________________________________________
>> >> uanog mailing list
>> >> uanog at uanog.kiev.ua
>> >> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>>
>>
>>
>>
>>
>> -- > Best regards,
>> Alexander V Soroka http://www.svr.ua/
>> AS106-RIPE
>> mailto:alex at euro.net.ua
>>
>> _______________________________________________
>> uanog mailing list
>> uanog at uanog.kiev.ua
>> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>>
>>
>>
>> -- > Best regards,
>>
>> Yevgen Ionov
>>
>> _______________________________________________
>> uanog mailing list
>> uanog at uanog.kiev.ua
>> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
--
Best regards,
Alexander V Soroka http://www.svr.ua/
AS106-RIPE
mailto:alex at euro.net.ua
_______________________________________________
uanog mailing list
uanog at uanog.kiev.ua
https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20220104/a411307a/attachment-0001.html>
More information about the uanog
mailing list