<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Привет,<br>
</p>
<p>могу предположить, что это из-за отсутствия обратной связи на
уровень IP. Отправитель продолжает херачить данные, ничего не зная
о состоянии underlay сети. Упомянутый в статье ECN - это уровень
IP и транзитный коммутатор модифицирует именно IP-заголовок,
обеспечивая таким образом обратную связь на уровень выше. Действия
без обратной связи приводят к рассинхронизации и соответствующим
последствиям.<br>
</p>
<div class="moz-cite-prefix">On 28.12.2021 11:26, Max Tulyev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7c8d121e-64a9-9be0-5ba3-c9a2c3632f75@netassist.kiev.ua">Привет!
<br>
<br>
Очень познавательно, спасибо!
<br>
<br>
Только один вопрос: почему на практике ethernet flow control
приходится везде отключать? Иначе имеем дикие задержки и потери
пакетов.
<br>
<br>
28.12.21 11:01, Volodymyr Litovka пише:
<br>
<blockquote type="cite">Привет,
<br>
<br>
для любителей лонгридов, есть прекрасная статья про стратегии
буферизации и обработки очередей по результатам воркшопа в
Стэнфордском университете в 2019 году - "*It hosted 98 attendees
from 12 economies with 26 from academia and 72 from industry.*"
-- <a class="moz-txt-link-freetext" href="https://blog.apnic.net/2019/12/12/sizing-the-buffer/">https://blog.apnic.net/2019/12/12/sizing-the-buffer/</a>
<br>
<br>
Для совсем уж любителей копать - материалы этого воркшопа
доступны тут: <a class="moz-txt-link-freetext" href="http://buffer-workshop.stanford.edu/program/">http://buffer-workshop.stanford.edu/program/</a>
<br>
<br>
<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!
<br>
</blockquote>
<br>
Так какими же? :) Главные выводы из статьи:
<br>
<br>
=== 1. утверждение "буфер 40MB - отстой" не выдерживает проверки
академическими исследованиями ===
<br>
<br>
<blockquote type="cite">A study by a Stanford TCP research group
in 2004 <a class="moz-txt-link-rfc2396E" href="http://doi.acm.org/10.1145/1030194.1015499"><http://doi.acm.org/10.1145/1030194.1015499></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:
<br>
<br>
*Size* = (*/BW/* ∙ */RTT/*) / √*/N/*
<br>
<br>
This is a radical result for high-speed extended latency links
in a 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 class="moz-txt-link-rfc2396E" href="https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/"><https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/></a><br>
<br>
</blockquote>
иными словами, совершенно не случайно большинство коммутаторов
из списка <a class="moz-txt-link-freetext" href="https://people.ucsc.edu/~warner/buffer.html">https://people.ucsc.edu/~warner/buffer.html</a> в портовом
диапазоне 48x10/25 + 6-8/100 укомплектованы размером буфера
32-40MB - этого достаточно. А если учесть, что операторские
реалии - это 1/10G агрегация (даже не 25), то можно
предположить, что оператор is absolutely safe с буфером такого
размера в своих коммутаторах.
<br>
<br>
=== 2. использование inline notification улучшает качество
передачи трафика ===
<br>
<br>
<blockquote type="cite">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).
<br>
<br>
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.
<br>
<br>
</blockquote>
[ ... ]
<br>
<blockquote type="cite">
<br>
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).
<br>
<br>
</blockquote>
<br>
всё же имеет смысл хотеть поддержки ECN
<br>
<br>
=== 3. flow-aware traffic management не является однозначной
заявкой на успех ===
<br>
<br>
<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.
<br>
</blockquote>
<br>
=== 4. и если вдруг вендора начинают говорить про гигантские
(напр 100ms) буфера ===
<br>
<br>
<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%.
<br>
</blockquote>
<br>
Спасибо.
<br>
<br>
<br>
On 15.10.2021 14:48, Volodymyr Litovka wrote:
<br>
<blockquote type="cite">
<br>
Привіт,
<br>
<br>
а ось тут мене запитали, а я не знаю як відповісти :) Я
розумію, що питання може звучати трішки дивно, але тим не менш
-
<br>
<br>
за вашим досвідом, скільки буферу (на порт або shared)
достатньо для уникнення або зниження до непомітного рівня
втрат пакетів при появі traffic bursts? Ну тобто цікавлять не
теоретичні розрахунки після відповідей на питання на кшталт "а
який час барста?", "а скільки складає барст у відсотках до
нормального" та таке інше, а по робітничо-селянському -
поточний досвід в живій мережі в поточних умовах поточного
Інтернету? Ну, наприклад, на будинковому комутаторі 24x1G +
2x10G з підключеними середньостатистичними абонентами?
<br>
<br>
Хтось взагалі цим питанням париться? :)
<br>
<br>
Дякую.
<br>
<br>
-- <br>
Volodymyr Litovka
<br>
"Vision without Execution is Hallucination." -- Thomas
Edison
<br>
</blockquote>
<br>
-- <br>
Volodymyr Litovka
<br>
"Vision without Execution is Hallucination." -- Thomas Edison
<br>
<br>
<br>
_______________________________________________
<br>
uanog mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:uanog@uanog.kiev.ua">uanog@uanog.kiev.ua</a>
<br>
<a class="moz-txt-link-freetext" href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a>
<br>
</blockquote>
_______________________________________________
<br>
uanog mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:uanog@uanog.kiev.ua">uanog@uanog.kiev.ua</a>
<br>
<a class="moz-txt-link-freetext" href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a><br>
</blockquote>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</body>
</html>