[uanog] switch's port buffers

Thu Dec 30 12:02:08 EET 2021

On Tue, Dec 28, 2021 at 11:00 AM Max Tulyev <maxtul at netassist.kiev.ua>
wrote:

> Так наоборот, фреймы pause и предназначены для того, чтобы Линукс узнал
> о состоянии физической сети! Но оно не работает. Точнее, я думаю, что
> там надо что-то ещё настроить, но что?
>

В топологии Linux--<10GE>---Switch и много Switch--<1GE>--Client pause
frames
(AKA Ethernet Flow Control) не помогут -  грунулярность Ethernet Flow
Control
per switchport of physical P2P link (например Switch-Linux). Если Switch
начал бы
слать pause к Linux из за congestion на одном Switch--<1GE>--Client порту
это
бы приостановило transmission на Linux ко всем IP destinations.

В текущих реалиях EPL (Ethernet Private Line) некоторые операторы отправляют
pause в клиентский порт в случае, например, если EPL bitrate > contracted
CIR.

А вот когда свитч сам лезет в поля TCP - как по мне, источник глюкодрома.
>

Так в случае с ECN свитч TCP поля не трогает, он модифицирует два начальных
бита Traffic Class в IP header (они рядом с DSCP и их разрешено менять
in-transit).

TCP client
- по получении IP пакета с ECN битами в CE (Congestion Encountered)
и
-  при условии что Server и Client при TCP setup negotiated ECN supports
отсылает TCP server ECN-Echo (ECE), получив которое Server узнает что на
TCP сессии к Client у него congestion.

> 28.12.21 11:36, Volodymyr Litovka пише:
> > Привет,
> >
> > могу предположить, что это из-за отсутствия обратной связи на уровень
> > IP. Отправитель продолжает херачить данные, ничего не зная о состоянии
> > underlay сети. Упомянутый в статье ECN - это уровень IP и транзитный
> > коммутатор модифицирует именно IP-заголовок, обеспечивая таким образом
> > обратную связь на уровень выше. Действия без обратной связи приводят к
> > рассинхронизации и соответствующим последствиям.
> >
> > On 28.12.2021 11:26, Max Tulyev wrote:
> >> Привет!
> >>
> >> Очень познавательно, спасибо!
> >>
> >> Только один вопрос: почему на практике ethernet flow control
> >> приходится везде отключать? Иначе имеем дикие задержки и потери пакетов.
> >>
> >> 28.12.21 11:01, Volodymyr Litovka пише:
> >>> Привет,
> >>>
> >>> для любителей лонгридов, есть прекрасная статья про стратегии
> >>> буферизации и обработки очередей по результатам воркшопа в
> >>> Стэнфордском университете в 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
> >
> > --
> > 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

-- 
Regards,
Volodymyr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20211230/c80ef651/attachment-0001.html>