<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Привет,</p>
<p>для любителей лонгридов, есть прекрасная статья про стратегии
буферизации и обработки очередей по результатам воркшопа в
Стэнфордском университете в 2019 году - "<b>It hosted 98 attendees
from 12 economies with 26 from academia and 72 from industry.</b>"
-- <font color="#000000"><a
href="https://blog.apnic.net/2019/12/12/sizing-the-buffer/"
class="moz-txt-link-freetext">https://blog.apnic.net/2019/12/12/sizing-the-buffer/</a></font></p>
<p>Для совсем уж любителей копать - материалы этого воркшопа
доступны тут: <font color="#000000"><a
href="http://buffer-workshop.stanford.edu/program/"
class="moz-txt-link-freetext">http://buffer-workshop.stanford.edu/program/</a><br>
</font> </p>
<p> </p>
<blockquote type="cite">[ ... ] 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!</blockquote>
<p>Так какими же? :) Главные выводы из статьи: </p>
<p>=== 1. утверждение "буфер 40MB - отстой" не выдерживает проверки
академическими исследованиями ===<br>
</p>
<blockquote type="cite">
<p>A <a href="http://doi.acm.org/10.1145/1030194.1015499"
target="_blank" rel="noreferrer noopener" aria-label="study by
a Stanford TCP research group in 2004 (opens in a new tab)">study
by a Stanford TCP research group in 2004</a> 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:</p>
<p class="has-medium-font-size"><strong>Size</strong> = (<strong><em>BW</em></strong> ∙ <strong><em>RTT</em></strong>)
/ √<strong><em>N</em></strong></p>
<p>This is a radical result for high-speed extended latency links
in a busy network. The consequences on router design are
enormous: </p>
<blockquote class="wp-block-quote">
<p>“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. <b>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%</b>. With small
buffers, the buffer would comfortably fit on a single chip
switch ASIC.”</p>
<cite>Nick McKeown et. al. <a rel="noreferrer noopener"
aria-label="Sizing Router Buffers (Redux) (opens in a new
tab)"
href="https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/"
target="_blank">Sizing Router Buffers (Redux)</a></cite></blockquote>
</blockquote>
<p>иными словами, совершенно не случайно большинство коммутаторов из
списка <font color="#000000"><a
href="https://people.ucsc.edu/~warner/buffer.html"
class="moz-txt-link-freetext">https://people.ucsc.edu/~warner/buffer.html</a>
в портовом диапазоне 48x10/25 + 6-8/100 укомплектованы размером
буфера 32-40MB - этого достаточно. А если учесть, что
операторские реалии - это 1/10G агрегация (даже не 25), то можно
предположить, что оператор is absolutely safe с буфером такого
размера в своих коммутаторах.<br>
</font> </p>
<p>=== 2. использование inline notification улучшает качество
передачи трафика ===<br>
</p>
<blockquote type="cite">
<p>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).</p>
<p>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.</p>
</blockquote>
[ ... ]<br>
<blockquote type="cite">
<p>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).</p>
</blockquote>
<br>
всё же имеет смысл хотеть поддержки ECN<br>
<p>=== 3. flow-aware traffic management не является однозначной
заявкой на успех ===</p>
<p> </p>
<blockquote type="cite">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.</blockquote>
<br>
<p>=== 4. и если вдруг вендора начинают говорить про гигантские
(напр 100ms) буфера ===</p>
<p> </p>
<blockquote type="cite">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%.</blockquote>
<br>
<p> Спасибо.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 15.10.2021 14:48, Volodymyr Litovka
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c86569cc-7f5b-4826-643c-6c44c5519da1@funlab.cc">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Привіт,</p>
<p>а ось тут мене запитали, а я не знаю як відповісти :) Я
розумію, що питання може звучати трішки дивно, але тим не менш -<br>
</p>
<p>за вашим досвідом, скільки буферу (на порт або shared)
достатньо для уникнення або зниження до непомітного рівня втрат
пакетів при появі traffic bursts? Ну тобто цікавлять не
теоретичні розрахунки після відповідей на питання на кшталт "а
який час барста?", "а скільки складає барст у відсотках до
нормального" та таке інше, а по робітничо-селянському - поточний
досвід в живій мережі в поточних умовах поточного Інтернету? Ну,
наприклад, на будинковому комутаторі 24x1G + 2x10G з
підключеними середньостатистичними абонентами?</p>
<p>Хтось взагалі цим питанням париться? :)<br>
</p>
<p>Дякую.<br>
</p>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</body>
</html>