[uanog] switch's port buffers

Tue Dec 28 12:11:56 EET 2021

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

Это если у тебя отправитель и транзитный коммутатор находятся в одной 
локальной сети. А если отправитель - Netflix, а получатель - в Бердичеве?

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

NAT вон тоже лезет в заголовки - и что? :)

>
> 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

-- 
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/f7f98bdf/attachment-0001.html>