<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 28.12.2021 12:00, Max Tulyev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5778237a-43b1-1c37-799c-1ad0079973e6@netassist.kiev.ua">Так
наоборот, фреймы pause и предназначены для того, чтобы Линукс
узнал о состоянии физической сети! Но оно не работает. Точнее, я
думаю, что там надо что-то ещё настроить, но что?
<br>
</blockquote>
<p>Это если у тебя отправитель и транзитный коммутатор находятся в
одной локальной сети. А если отправитель - Netflix, а получатель -
в Бердичеве?</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:5778237a-43b1-1c37-799c-1ad0079973e6@netassist.kiev.ua">
А вот когда свитч сам лезет в поля TCP - как по мне, источник
глюкодрома.
<br>
</blockquote>
<p>NAT вон тоже лезет в заголовки - и что? :)</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:5778237a-43b1-1c37-799c-1ad0079973e6@netassist.kiev.ua">
<br>
28.12.21 11:36, Volodymyr Litovka пише:
<br>
<blockquote type="cite">Привет,
<br>
<br>
могу предположить, что это из-за отсутствия обратной связи на
уровень IP. Отправитель продолжает херачить данные, ничего не
зная о состоянии underlay сети. Упомянутый в статье ECN - это
уровень IP и транзитный коммутатор модифицирует именно
IP-заголовок, обеспечивая таким образом обратную связь на
уровень выше. Действия без обратной связи приводят к
рассинхронизации и соответствующим последствиям.
<br>
<br>
On 28.12.2021 11:26, Max Tulyev wrote:
<br>
<blockquote type="cite">Привет!
<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>
<br>
-- <br>
Volodymyr Litovka
<br>
"Vision without Execution is Hallucination." -- Thomas Edison
<br>
<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>