[uanog] switch's port buffers

Tue Jan 4 15:31:26 EET 2022

Приветствую,

В данном контексте ключевой фактор использование 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20220104/ec326746/attachment-0001.html>