[uanog] switch's port buffers

Tue Jan 11 09:40:20 EET 2022

Привет.

Я знаю как минимум 3 попытки использовать P4:
1) построить IX без MPLS stack и как следствие использовать свитчи, а не раутеры
2) дублировать трафик в другой порт для анализа
3) дублировать трафик и передавать его через 2 независимых канала для “надежности”

Из того, что я знаю до промышленных масштабов дело не дошло.

Максим
On 4 Jan 2022, 12:59 +0100, Yevgen Ionov <yevgen.ionov at gmail.com>, wrote:
> Привет Максим,
>
> >   Из грустного: сколько нужно академиков, чтобы написать доклад на 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 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://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/20220111/d8a9253d/attachment-0001.html>