<div dir="ltr"><div dir="ltr">On Tue, Dec 28, 2021 at 11:00 AM Max Tulyev <<a href="mailto:maxtul@netassist.kiev.ua">maxtul@netassist.kiev.ua</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Так наоборот, фреймы pause и предназначены для того, чтобы Линукс узнал <br>
о состоянии физической сети! Но оно не работает. Точнее, я думаю, что <br>
там надо что-то ещё настроить, но что?<br></blockquote><div><br></div><div>В топологии Linux--<10GE>---Switch и много Switch--<1GE>--Client pause frames</div><div>(AKA Ethernet Flow Control) не помогут -  грунулярность Ethernet Flow Control</div><div>per switchport of physical P2P link (например Switch-Linux). Если Switch начал бы</div><div>слать pause к Linux из за congestion на одном Switch--<1GE>--Client порту это</div><div>бы приостановило transmission на Linux ко всем IP destinations. </div><div> </div><div>В текущих реалиях EPL (Ethernet Private Line) некоторые операторы отправляют</div><div>pause в клиентский порт в случае, например, если EPL bitrate > contracted CIR.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
А вот когда свитч сам лезет в поля TCP - как по мне, источник глюкодрома.<br></blockquote><div><br></div><div>Так в случае с ECN свитч TCP поля не трогает, он модифицирует два начальных</div><div>бита Traffic Class в IP header (они рядом с DSCP и их разрешено менять in-transit).</div><div><br></div><div>TCP client</div><div>- по получении IP пакета с ECN битами в CE (Congestion Encountered) </div><div>и</div><div>-  при условии что Server и Client при TCP setup negotiated ECN supports</div><div>отсылает TCP server ECN-Echo (ECE), получив которое Server узнает что на TCP сессии к Client у него congestion.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
28.12.21 11:36, Volodymyr Litovka пише:<br>
> Привет,<br>
> <br>
> могу предположить, что это из-за отсутствия обратной связи на уровень <br>
> IP. Отправитель продолжает херачить данные, ничего не зная о состоянии <br>
> underlay сети. Упомянутый в статье ECN - это уровень IP и транзитный <br>
> коммутатор модифицирует именно IP-заголовок, обеспечивая таким образом <br>
> обратную связь на уровень выше. Действия без обратной связи приводят к <br>
> рассинхронизации и соответствующим последствиям.<br>
> <br>
> On 28.12.2021 11:26, Max Tulyev wrote:<br>
>> Привет!<br>
>><br>
>> Очень познавательно, спасибо!<br>
>><br>
>> Только один вопрос: почему на практике ethernet flow control <br>
>> приходится везде отключать? Иначе имеем дикие задержки и потери пакетов.<br>
>><br>
>> 28.12.21 11:01, Volodymyr Litovka пише:<br>
>>> Привет,<br>
>>><br>
>>> для любителей лонгридов, есть прекрасная статья про стратегии <br>
>>> буферизации и обработки очередей по результатам воркшопа в <br>
>>> Стэнфордском университете в 2019 году - "*It hosted 98 attendees from <br>
>>> 12 economies with 26 from academia and 72 from industry.*" -- <br>
>>> <a href="https://blog.apnic.net/2019/12/12/sizing-the-buffer/" rel="noreferrer" target="_blank">https://blog.apnic.net/2019/12/12/sizing-the-buffer/</a><br>
>>><br>
>>> Для совсем уж любителей копать - материалы этого воркшопа доступны <br>
>>> тут: <a href="http://buffer-workshop.stanford.edu/program/" rel="noreferrer" target="_blank">http://buffer-workshop.stanford.edu/program/</a><br>
>>><br>
>>>> [ ... ] buffers also add additional lag to a packet’s transit <br>
>>>> through the network. If you want to implement a low jitter service, <br>
>>>> then deep buffers are decidedly unfriendly! The result is the rather <br>
>>>> enigmatic observation that network buffers have to be as big as they <br>
>>>> need to be, but no bigger!<br>
>>><br>
>>> Так какими же? :) Главные выводы из статьи:<br>
>>><br>
>>> === 1. утверждение "буфер 40MB - отстой" не выдерживает проверки <br>
>>> академическими исследованиями ===<br>
>>><br>
>>>> A study by a Stanford TCP research group in 2004 <br>
>>>> <<a href="http://doi.acm.org/10.1145/1030194.1015499" rel="noreferrer" target="_blank">http://doi.acm.org/10.1145/1030194.1015499</a>> used the central limit <br>
>>>> theorem to point to a radically smaller model of buffer size. Link <br>
>>>> efficiency can be maintained for N desynchronized flows with a <br>
>>>> buffer that is dimensioned to the size of:<br>
>>>><br>
>>>> *Size* = (*/BW/* ∙ */RTT/*) / √*/N/*<br>
>>>><br>
>>>> This is a radical result for high-speed extended latency links in a <br>
>>>> busy network. The consequences on router design are enormous:<br>
>>>><br>
>>>>     “For example, a 1 Tb/s ISP router carrying one TCP flow with an<br>
>>>>     RTTmin of 100ms would require 12.5 GB of buffer and off-chip<br>
>>>>     buffering. *If it carries 100,000 flows, then the buffer can be<br>
>>>>     safely reduced to less than 40MB, reducing the buffering and<br>
>>>>     worst-case latency by 99.7%*. With small buffers, the buffer would<br>
>>>>     comfortably fit on a single chip switch ASIC.”<br>
>>>><br>
>>>>     Nick McKeown et. al. Sizing Router Buffers (Redux)<br>
>>>> <<a href="https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/" rel="noreferrer" target="_blank">https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/</a>><br>
>>>><br>
>>> иными словами, совершенно не случайно большинство коммутаторов из <br>
>>> списка <a href="https://people.ucsc.edu/~warner/buffer.html" rel="noreferrer" target="_blank">https://people.ucsc.edu/~warner/buffer.html</a> в портовом <br>
>>> диапазоне 48x10/25 + 6-8/100 укомплектованы размером буфера 32-40MB - <br>
>>> этого достаточно. А если учесть, что операторские реалии - это 1/10G <br>
>>> агрегация (даже не 25), то можно предположить, что оператор is <br>
>>> absolutely safe с буфером такого размера в своих коммутаторах.<br>
>>><br>
>>> === 2. использование inline notification улучшает качество передачи <br>
>>> трафика ===<br>
>>><br>
>>>> The advantage of ECN is that the sender is not placed in the <br>
>>>> position of being informed of a congestion condition well after the <br>
>>>> condition has occurred. Explicit notification allows the sender to <br>
>>>> be informed of a condition as it is forming so that it can take <br>
>>>> action while there is still a coherent ack pacing signal coming back <br>
>>>> from the receiver (that is before packet loss occurs).<br>
>>>><br>
>>>> However, ECN is only a single bit marking. Is this enough? [ ... ] <br>
>>>> The conclusion from one presentation is that the single-bit marking, <br>
>>>> while coarse and non-specific is probably sufficient to moderate <br>
>>>> self-clocking TCP flows such that they do not place pressure on <br>
>>>> network buffers, leaving the buffers to deal with short term bursts <br>
>>>> from unconstrained sources.<br>
>>>><br>
>>> [ ... ]<br>
>>>><br>
>>>> And if we want to reduce buffer size and maintain efficient and fair <br>
>>>> performance how can we achieve it? One view is that sender pacing <br>
>>>> can remove much of the pressure on buffers, and self-clocking flows <br>
>>>> can stabilise without emitting transient bursts that need to be <br>
>>>> absorbed by buffers. Another view, and one that does not necessarily <br>
>>>> contradict the first, is that the self-clocking algorithm can <br>
>>>> operate with higher precision if there was some form of feedback <br>
>>>> from the network on the state of the network path. This can be as <br>
>>>> simple as a single bit (ECN) or a complete trace of path element <br>
>>>> queue state (HPCC).<br>
>>>><br>
>>><br>
>>> всё же имеет смысл хотеть поддержки ECN<br>
>>><br>
>>> === 3. flow-aware traffic management не является однозначной заявкой <br>
>>> на успех ===<br>
>>><br>
>>>> If the network was in a position to be able to classify all <br>
>>>> currently active flows into either elephants or mice, then the <br>
>>>> network could be able to use different queuing regimes for each <br>
>>>> traffic class. This sorting adds to the cost and complexity of <br>
>>>> packet switches, and if scaling pressures are a factor in switch <br>
>>>> design then it’s not clear that the additional cost of switch <br>
>>>> complexity would be offset by a far superior efficiency outcome in <br>
>>>> the switching function.<br>
>>><br>
>>> === 4. и если вдруг вендора начинают говорить про гигантские (напр <br>
>>> 100ms) буфера ===<br>
>>><br>
>>>> Further analysis reveals an estimate of packet drop rates if the <br>
>>>> network’s buffers were reduced in size, and for this particular <br>
>>>> case, the analysis revealed that an 18msec buffer would be able to <br>
>>>> sustain a packet drop rate of less than 0.005%.<br>
>>><br>
>>> Спасибо.<br>
>>><br>
>>><br>
>>> On 15.10.2021 14:48, Volodymyr Litovka wrote:<br>
>>>><br>
>>>> Привіт,<br>
>>>><br>
>>>> а ось тут мене запитали, а я не знаю як відповісти :) Я розумію, що <br>
>>>> питання може звучати трішки дивно, але тим не менш -<br>
>>>><br>
>>>> за вашим досвідом, скільки буферу (на порт або shared) достатньо для <br>
>>>> уникнення або зниження до непомітного рівня втрат пакетів при появі <br>
>>>> traffic bursts? Ну тобто цікавлять не теоретичні розрахунки після <br>
>>>> відповідей на питання на кшталт "а який час барста?", "а скільки <br>
>>>> складає барст у відсотках до нормального" та таке інше, а по <br>
>>>> робітничо-селянському - поточний досвід в живій мережі в поточних <br>
>>>> умовах поточного Інтернету? Ну, наприклад, на будинковому комутаторі <br>
>>>> 24x1G + 2x10G з підключеними середньостатистичними абонентами?<br>
>>>><br>
>>>> Хтось взагалі цим питанням париться? :)<br>
>>>><br>
>>>> Дякую.<br>
>>>><br>
>>>> -- <br>
>>>> Volodymyr Litovka<br>
>>>>    "Vision without Execution is Hallucination." -- Thomas Edison<br>
>>><br>
>>> -- <br>
>>> Volodymyr Litovka<br>
>>>    "Vision without Execution is Hallucination." -- Thomas Edison<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> uanog mailing list<br>
>>> <a href="mailto:uanog@uanog.kiev.ua" target="_blank">uanog@uanog.kiev.ua</a><br>
>>> <a href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog" rel="noreferrer" target="_blank">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a><br>
>> _______________________________________________<br>
>> uanog mailing list<br>
>> <a href="mailto:uanog@uanog.kiev.ua" target="_blank">uanog@uanog.kiev.ua</a><br>
>> <a href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog" rel="noreferrer" target="_blank">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a><br>
> <br>
> -- <br>
> Volodymyr Litovka<br>
>    "Vision without Execution is Hallucination." -- Thomas Edison<br>
> <br>
_______________________________________________<br>
uanog mailing list<br>
<a href="mailto:uanog@uanog.kiev.ua" target="_blank">uanog@uanog.kiev.ua</a><br>
<a href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog" rel="noreferrer" target="_blank">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Regards,<br>Volodymyr.</div></div>