[uanog] switch's port buffers
Volodymyr Litovka
doka at funlab.cc
Tue Dec 28 11:36:39 EET 2021
Привет,
могу предположить, что это из-за отсутствия обратной связи на уровень
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20211228/2510bf93/attachment-0001.html>
More information about the uanog
mailing list