[uanog] switch's port buffers
Volodymyr Litovka
doka at funlab.cc
Tue Dec 28 11:01:50 EET 2021
Привет,
для любителей лонгридов, есть прекрасная статья про стратегии
буферизации и обработки очередей по результатам воркшопа в Стэнфордском
университете в 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20211228/f34b22d4/attachment.html>
More information about the uanog
mailing list