[uanog] switch's port buffers
Yevgen Ionov
yevgen.ionov at gmail.com
Tue Jan 4 16:00:35 EET 2022
Привет,
> может ходить разными путями или балансироваться ..
Я думаю этот вопрос как раз к контроллеру и телеметрии.
https://p4.org/p4-spec/docs/INT_v2_1.pdf
What To Monitor:
The exact meaning of the following metadata (e.g., the unit of timestamp
values, the precise definition of hop latency, queue occupancy or buffer
occupancy)
On Tue, 4 Jan 2022 at 14:41, Volodymyr Litovka <doka at funlab.cc> wrote:
> Привет,
>
> перенаправление на другой dst ip/port - это задача app layer. Этим
> действием, теоретически, может являться как раз попытка использования
> другого маршрута (маршрутизатора, коммутатора и/или линейной карты) с целью
> использовать другой пакетный буфер. Но мне тяжело себе представить, как
> может абстрактный "нетфликс" рассчитывать, что где-то по дороге до
> абстрактного "бердичева" что-то может ходить разными путями или
> балансироваться по разным линейным картам / port groups.
>
> Вопрос заключается в том, что независимо от выбора устройства, в нем
> присутствует shared buffer для какой-то группы портов (все порты;
> сгруппированные внутри одного ASIC/FPGA; разобранные по отдельным линейным
> картам) и какова должна быть стратегия определения оптимального размера
> пакетного буфера, чтобы соблюсти компромисс между количеством требуемой
> памяти (читай - ценой устройства) и эффективностью доставки данных в
> условиях всплесков нагрузки.
> On 04.01.2022 15:31, Yevgen Ionov wrote:
>
> Приветствую,
>
> В данном контексте ключевой фактор использование P4 для программирования
> каких-то unusual tasks..
> Использование FPGA архитектуры "на вырост" может быть не
> оправданным, ввиду высокой стоимости отдельного свитча.
> Cisco в качестве примера unusual task демонстрирует перенаправление video
> stream каждые 20 sec на новый DST IP/Port, т.е. video-frame после каждой 20
> сек идет по новому path и это уже даже не TCP fields.
>
> https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKDCN-2694.pdf
>
> Экстраполируя это на текущую дискуссию, возможно проблемы с буферизацией
> на FGPA можно попытаться решить другими способами и логику принятия решений
> можно переписать в отличие от ASIC & pre-programmed logic in OS.
> The behavior of the programmable blocks is specified using P4. The Packet
> buffer and Replication Engine (PRE) and the Buffer Queuing Engine (BQE) are
> target dependent functional blocks that may be configured for a fixed set
> of operations.
>
> Но возникнут множество других вопросов, методология измерения, управление
> потоками по всей топологии (потребуется контроллер, например ONOS) и
> интеграция в с традиционными STP сетями.
> Для меня все это теория и стало интересно обсуждается ли использование
> P4 на практическом уровне или может кто-то пытался оценить в качестве
> проекта для подобных задач.
>
> Спасибо.
>
> On Tue, 4 Jan 2022 at 13:09, Alexander V Soroka <alex at euro.net.ua> wrote:
>
>> Привет !
>>
>> частично ответыт тут есть:
>> ASIC vs. FPGA: What’s the difference?
>> https://www.sondrel.com/blog/asic-vs.-fpga:-what%27s-the-difference
>>
>> Цитаты:
>> ...Термин ASIC является аббревиатурой от Application Specific
>> Integrated Circuit. Как следует из названия, ASIC - это интегральная
>> схема, разработанная для конкретного использования или приложения,
>> которую нельзя перепрограммировать или изменить после того, как она
>> будет произведена. ASIC разработан в соответствии со спецификациями
>> продукта и не предназначен для общего использования. Более
>> распространенным термином является SoC (система на кристалле), который
>> представляет собой ASIC, который действует как целая подсистема,
>> включая ЦП, память и периферийные устройства.
>>
>> ... FPGA (или всем знакомое ПЛИС) расшифровывается как
>> Field Programmable Gate Array. FPGA производится для общего
>> использования с
>> использованием настраиваемых логических блоков и программируемых
>> межсоединений. Это означает, что FPGA может быть запрограммирована и
>> перепрограммирована (в зависимости от типа FPGA) для выполнения многих
>> функций после ее изготовления.
>>
>> Типы ПЛИС
>> ПЛИС можно классифицировать двумя способами. Либо по их внутренней
>> архитектуре, либо по типу программируемой технологии. В рамках этих
>> двух классификаций существует несколько типов ПЛИС.
>> ...
>>
>> ЧТО Я могу сказать: с точки зрения "на вырост" я бы всегда выбирал
>> FPGA. Потому что технологии меняются, а ПО всегда можно переписать. У
>> майнеров есть несколько видео про то как FPGA делает некоторые виды
>> видеокарт, просто потому что можно "выпилить" внутри архитектуру
>> работы именно под то что вам нужно, и получить И аппартно заточенное И
>> программно заточенное решение. Оно по-любому будет быстрее чем
>> "примерно подходящее", но может проиграть "очень острозаточенному для
>> 1 операции".
>>
>> Я бы в проектах использовал только FPGA.
>>
>>
>> Tuesday, January 4, 2022, 1:59:15 PM, Yevgen Ionov yevgen.ionov at gmail.com
>> you wrote:
>> YI> Привет Максим,
>>
>> >> Из грустного: сколько нужно академиков, чтобы написать доклад на 2
>> YI> страницы http://buffer-workshop.stanford.edu/papers/paper18.pdf
>>
>> YI> Беглый просмотр документа указывает на наличие инструментов для
>> YI> программируемых сетей (P4 Toolkit) & P4 programmable switches,
>> которые по
>> YI> своей архитектуре отличается от традиционных.
>> YI> И если я правильно понимаю данное обсуждение, речь идет о традиционных
>> YI> ASIC-based свитчах с фиксированными размерами buffers.
>>
>> YI> Мне лично интересно понять:
>> YI> 1. Обсуждается ли тема в среде операторов использования programmable
>> YI> switches & P4?
>> YI> С точки зрения управления flows, congestions, etc использование P4
>> сильно
>> YI> отличаться от традиционного подхода и протоколов.
>> YI> На различных Telco презентациях об этом достаточно много разговоров,
>> но
>> YI> есть ли практическое развитие?
>>
>> YI> 2. Корректно ли сравнивать в данном случае выводы для программируемой
>> YI> архитектуры FPGA vs традиционную ASIC-based архитектуру?
>>
>>
>> YI> Спасибо.
>>
>>
>> YI> On Thu, 30 Dec 2021 at 11:57, Maksym Tulyuk <maksym at tulyuk.com>
>> wrote:
>>
>> >> Привет!
>> >>
>> >> У меня совсем другие выводы:
>> >> 1) из последнего доклада "We still know very little about buffer size”
>> и
>> >> ИМХО это лучший вывод/совет
>> >> 2) все академики продолжают обсуждать TCP tuning и не хотят видеть, что
>> >> уже в 2019 у Deutsche Telekom он составлял всего 84.4% (все остальное
>> - UDP
>> >> с быстрым ростом QUIC)
>> >> 3) все доклады рассказывают про MTU size 1500, хотя в реальном мире
>> такого
>> >> трафика 50% максимум https://stats.ams-ix.net/sflow/size.html и как
>> видно
>> >> из графика 35% - это пакеты размером 64-127 bytes
>> >>
>> >> Из интересного:
>> >>
>> >> - Understanding switch buffer utilization in CLOS data center fabric
>> >> (Verizon)
>> >>
>> http://buffer-workshop.stanford.edu/slides/Understanding%20switch%20buffer%20utilization%20in%20CLOS%20data%20center%20fabric.pptx
>> >> - Buffer sizing and Video QoE Measurements at Netflix
>> >>
>> http://buffer-workshop.stanford.edu/slides/netflix%20buffer%20sizing.pdf
>> >> - Queueing at the Telco Service Edge (Deutsche Telekom)
>> >>
>> http://buffer-workshop.stanford.edu/slides/BS_QueueingEdge_2019_12_03.pdf
>> >> - Buffer Sizing Experiments at Facebook
>> >> http://buffer-workshop.stanford.edu/papers/paper30.pdf
>> >>
>> >> Из грустного: сколько нужно академиков, чтобы написать доклад на 2
>> >> страницы http://buffer-workshop.stanford.edu/papers/paper18.pdf
>> >>
>> >> НО это все было в 2019, а сейчас кажется что Гугл был прав и будущее
>> это
>> >> UDP+QUIC и все исследования на тему буферов нужно начинать с нуля.
>> >>
>> >> Максим
>> >> On 28 Dec 2021, 10:02 +0100, Volodymyr Litovka <doka at funlab.cc>,
>> wrote:
>> >>
>> >> Привет,
>> >>
>> >> для любителей лонгридов, есть прекрасная статья про стратегии
>> буферизации
>> >> и обработки очередей по результатам воркшопа в Стэнфордском
>> университете в
>> >> 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
>> >>
>> >> _______________________________________________
>> >> uanog mailing list
>> >> uanog at uanog.kiev.ua
>> >> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>> >>
>> >> _______________________________________________
>> >> uanog mailing list
>> >> uanog at uanog.kiev.ua
>> >> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>>
>>
>>
>>
>>
>> --
>> Best regards,
>> Alexander V Soroka http://www.svr.ua/
>> AS106-RIPE
>> mailto:alex at euro.net.ua
>>
>> _______________________________________________
>> uanog mailing list
>> uanog at uanog.kiev.ua
>> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>
>
>
> --
> Best regards,
>
> Yevgen Ionov
>
> _______________________________________________
> uanog mailing listuanog at uanog.kiev.uahttps://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>
> --
> Volodymyr Litovka
> "Vision without Execution is Hallucination." -- Thomas Edison
>
>
--
Best regards,
Yevgen Ionov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20220104/51a39e38/attachment-0001.html>
More information about the uanog
mailing list