[uanog] switch's port buffers

Tue Jan 4 13:59:15 EET 2022

Привет Максим,

>   Из грустного: сколько нужно академиков, чтобы написать доклад на 2
страницы http://buffer-workshop.stanford.edu/papers/paper18.pdf

Беглый просмотр документа указывает на наличие инструментов для
программируемых сетей (P4 Toolkit) & P4 programmable switches, которые по
своей архитектуре отличается от традиционных.
И если я правильно понимаю данное обсуждение, речь идет о традиционных
ASIC-based свитчах с фиксированными размерами buffers.

Мне лично интересно понять:
1. Обсуждается ли тема в среде операторов  использования programmable
switches & P4?
С точки зрения управления flows, congestions, etc использование P4 сильно
отличаться от традиционного подхода и протоколов.
На различных Telco презентациях об этом достаточно много разговоров, но
есть ли практическое развитие?

2. Корректно ли сравнивать в данном случае выводы для программируемой
архитектуры FPGA vs традиционную ASIC-based архитектуру?

Спасибо.

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,

Yevgen Ionov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20220104/6c21d982/attachment-0001.html>