[uanog] switch's port buffers

Tue Dec 28 12:00:07 EET 2021

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

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

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
> 