[uanog] switch's port buffers

Tue Dec 28 11:26:31 EET 2021

Привет!

Очень познавательно, спасибо!

Только один вопрос: почему на практике 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