[uanog] switch's port buffers
Volodymyr Litovka
doka at funlab.cc
Tue Jan 4 15:41:27 EET 2022
Привет,
перенаправление на другой 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 list
> uanog at uanog.kiev.ua
> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
--
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/20220104/d036d127/attachment-0001.html>
More information about the uanog
mailing list