<div dir="ltr">Привет,<br><br>>
может ходить разными путями или балансироваться ..<br>Я думаю этот вопрос как раз к контроллеру и телеметрии.<br><br><a href="https://p4.org/p4-spec/docs/INT_v2_1.pdf">https://p4.org/p4-spec/docs/INT_v2_1.pdf</a><br> What To Monitor: <br> 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)
<br><br> </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 4 Jan 2022 at 14:41, Volodymyr Litovka <<a href="mailto:doka@funlab.cc">doka@funlab.cc</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Привет,</p>
<p>перенаправление на другой dst ip/port - это задача app layer.
Этим действием, теоретически, может являться как раз попытка
использования другого маршрута (маршрутизатора, коммутатора и/или
линейной карты) с целью использовать другой пакетный буфер. Но мне
тяжело себе представить, как может абстрактный "нетфликс"
рассчитывать, что где-то по дороге до абстрактного "бердичева"
что-то может ходить разными путями или балансироваться по разным
линейным картам / port groups.</p>
<p>Вопрос заключается в том, что независимо от выбора устройства, в
нем присутствует shared buffer для какой-то группы портов (все
порты; сгруппированные внутри одного ASIC/FPGA; разобранные по
отдельным линейным картам) и какова должна быть стратегия
определения оптимального размера пакетного буфера, чтобы соблюсти
компромисс между количеством требуемой памяти (читай - ценой
устройства) и эффективностью доставки данных в условиях всплесков
нагрузки.<br>
</p>
<div>On 04.01.2022 15:31, Yevgen Ionov
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Приветствую,<br>
<br>
В данном контексте ключевой фактор использование P4 для
программирования каких-то unusual tasks.. <br>
Использование FPGA архитектуры "на вырост" может быть не
оправданным, ввиду высокой стоимости отдельного свитча. <br>
Cisco в качестве примера unusual task демонстрирует
перенаправление video stream каждые 20 sec на новый DST IP/Port,
т.е. video-frame после каждой 20 сек идет по новому path и это
уже даже не TCP fields. <br>
<a href="https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKDCN-2694.pdf" target="_blank">https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKDCN-2694.pdf</a><br>
<div><br>
</div>
<div>Экстраполируя это на текущую дискуссию, возможно проблемы с
буферизацией на FGPA можно попытаться решить другими способами
и логику принятия решений можно переписать в отличие от ASIC
& pre-programmed logic in OS. <br>
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.<br>
<br>
Но возникнут множество других вопросов, методология измерения,
управление потоками по всей топологии (потребуется контроллер,
например ONOS) и интеграция в с традиционными STP сетями.<br>
Для меня все это теория и стало интересно обсуждается ли
использование P4 на практическом уровне или может кто-то
пытался оценить в качестве проекта для подобных задач.</div>
<div><br>
Спасибо.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 4 Jan 2022 at 13:09,
Alexander V Soroka <<a href="mailto:alex@euro.net.ua" target="_blank">alex@euro.net.ua</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Привет
!<br>
<br>
частично ответыт тут есть:<br>
ASIC vs. FPGA: What’s the difference?<br>
<a href="https://www.sondrel.com/blog/asic-vs.-fpga:-what%27s-the-difference" rel="noreferrer" target="_blank">https://www.sondrel.com/blog/asic-vs.-fpga:-what%27s-the-difference</a><br>
<br>
Цитаты:<br>
...Термин ASIC является аббревиатурой от Application
Specific<br>
Integrated Circuit. Как следует из названия, ASIC - это
интегральная<br>
схема, разработанная для конкретного использования или
приложения,<br>
которую нельзя перепрограммировать или изменить после того,
как она<br>
будет произведена. ASIC разработан в соответствии со
спецификациями<br>
продукта и не предназначен для общего
использования. Более<br>
распространенным термином является SoC (система на кристалле),
который<br>
представляет собой ASIC, который действует как целая
подсистема,<br>
включая ЦП, память и периферийные устройства.<br>
<br>
... FPGA (или всем знакомое ПЛИС) расшифровывается
как<br>
Field Programmable Gate Array. FPGA производится для общего
использования с<br>
использованием настраиваемых логических блоков и
программируемых<br>
межсоединений. Это означает, что FPGA может быть
запрограммирована и<br>
перепрограммирована (в зависимости от типа FPGA) для
выполнения многих<br>
функций после ее изготовления.<br>
<br>
Типы ПЛИС<br>
ПЛИС можно классифицировать двумя способами. Либо по их
внутренней<br>
архитектуре, либо по типу программируемой технологии. В
рамках этих<br>
двух классификаций существует несколько типов ПЛИС.<br>
...<br>
<br>
ЧТО Я могу сказать: с точки зрения "на вырост" я бы всегда
выбирал<br>
FPGA. Потому что технологии меняются, а ПО всегда можно
переписать. У<br>
майнеров есть несколько видео про то как FPGA делает
некоторые виды<br>
видеокарт, просто потому что можно "выпилить" внутри
архитектуру<br>
работы именно под то что вам нужно, и получить И аппартно
заточенное И<br>
программно заточенное решение. Оно по-любому будет
быстрее чем<br>
"примерно подходящее", но может проиграть "очень
острозаточенному для<br>
1 операции".<br>
<br>
Я бы в проектах использовал только FPGA.<br>
<br>
<br>
Tuesday, January 4, 2022, 1:59:15 PM, Yevgen Ionov <a href="mailto:yevgen.ionov@gmail.com" target="_blank">yevgen.ionov@gmail.com</a>
you wrote:<br>
YI> Привет Максим,<br>
<br>
>> Из грустного: сколько нужно академиков, чтобы
написать доклад на 2<br>
YI> страницы <a href="http://buffer-workshop.stanford.edu/papers/paper18.pdf" rel="noreferrer" target="_blank">http://buffer-workshop.stanford.edu/papers/paper18.pdf</a><br>
<br>
YI> Беглый просмотр документа указывает на наличие
инструментов для<br>
YI> программируемых сетей (P4 Toolkit) & P4
programmable switches, которые по<br>
YI> своей архитектуре отличается от традиционных.<br>
YI> И если я правильно понимаю данное обсуждение, речь идет
о традиционных<br>
YI> ASIC-based свитчах с фиксированными размерами buffers.<br>
<br>
YI> Мне лично интересно понять:<br>
YI> 1. Обсуждается ли тема в среде операторов
использования programmable<br>
YI> switches & P4?<br>
YI> С точки зрения управления flows, congestions, etc
использование P4 сильно<br>
YI> отличаться от традиционного подхода и протоколов.<br>
YI> На различных Telco презентациях об этом достаточно
много разговоров, но<br>
YI> есть ли практическое развитие?<br>
<br>
YI> 2. Корректно ли сравнивать в данном случае выводы для
программируемой<br>
YI> архитектуры FPGA vs традиционную ASIC-based
архитектуру?<br>
<br>
<br>
YI> Спасибо.<br>
<br>
<br>
YI> On Thu, 30 Dec 2021 at 11:57, Maksym Tulyuk <<a href="mailto:maksym@tulyuk.com" target="_blank">maksym@tulyuk.com</a>>
wrote:<br>
<br>
>> Привет!<br>
>><br>
>> У меня совсем другие выводы:<br>
>> 1) из последнего доклада "We still know very little
about buffer size” и<br>
>> ИМХО это лучший вывод/совет<br>
>> 2) все академики продолжают обсуждать TCP tuning и не
хотят видеть, что<br>
>> уже в 2019 у Deutsche Telekom он составлял всего
84.4% (все остальное - UDP<br>
>> с быстрым ростом QUIC)<br>
>> 3) все доклады рассказывают про MTU size 1500, хотя в
реальном мире такого<br>
>> трафика 50% максимум <a href="https://stats.ams-ix.net/sflow/size.html" rel="noreferrer" target="_blank">https://stats.ams-ix.net/sflow/size.html</a>
и как видно<br>
>> из графика 35% - это пакеты размером 64-127 bytes<br>
>><br>
>> Из интересного:<br>
>><br>
>> - Understanding switch buffer utilization in CLOS
data center fabric<br>
>> (Verizon)<br>
>> <a href="http://buffer-workshop.stanford.edu/slides/Understanding%20switch%20buffer%20utilization%20in%20CLOS%20data%20center%20fabric.pptx" rel="noreferrer" target="_blank">http://buffer-workshop.stanford.edu/slides/Understanding%20switch%20buffer%20utilization%20in%20CLOS%20data%20center%20fabric.pptx</a><br>
>> - Buffer sizing and Video QoE Measurements at
Netflix<br>
>> <a href="http://buffer-workshop.stanford.edu/slides/netflix%20buffer%20sizing.pdf" rel="noreferrer" target="_blank">http://buffer-workshop.stanford.edu/slides/netflix%20buffer%20sizing.pdf</a><br>
>> - Queueing at the Telco Service Edge (Deutsche
Telekom)<br>
>> <a href="http://buffer-workshop.stanford.edu/slides/BS_QueueingEdge_2019_12_03.pdf" rel="noreferrer" target="_blank">http://buffer-workshop.stanford.edu/slides/BS_QueueingEdge_2019_12_03.pdf</a><br>
>> - Buffer Sizing Experiments at Facebook<br>
>> <a href="http://buffer-workshop.stanford.edu/papers/paper30.pdf" rel="noreferrer" target="_blank">http://buffer-workshop.stanford.edu/papers/paper30.pdf</a><br>
>><br>
>> Из грустного: сколько нужно академиков, чтобы
написать доклад на 2<br>
>> страницы <a href="http://buffer-workshop.stanford.edu/papers/paper18.pdf" rel="noreferrer" target="_blank">http://buffer-workshop.stanford.edu/papers/paper18.pdf</a><br>
>><br>
>> НО это все было в 2019, а сейчас кажется что Гугл был
прав и будущее это<br>
>> UDP+QUIC и все исследования на тему буферов нужно
начинать с нуля.<br>
>><br>
>> Максим<br>
>> On 28 Dec 2021, 10:02 +0100, Volodymyr Litovka <<a href="mailto:doka@funlab.cc" target="_blank">doka@funlab.cc</a>>,
wrote:<br>
>><br>
>> Привет,<br>
>><br>
>> для любителей лонгридов, есть прекрасная статья про
стратегии буферизации<br>
>> и обработки очередей по результатам воркшопа в
Стэнфордском университете в<br>
>> 2019 году - "*It hosted 98 attendees from 12
economies with 26 from<br>
>> academia and 72 from industry.*" --<br>
>> <a href="https://blog.apnic.net/2019/12/12/sizing-the-buffer/" rel="noreferrer" target="_blank">https://blog.apnic.net/2019/12/12/sizing-the-buffer/</a><br>
>><br>
>> Для совсем уж любителей копать - материалы этого
воркшопа доступны тут:<br>
>> <a href="http://buffer-workshop.stanford.edu/program/" rel="noreferrer" target="_blank">http://buffer-workshop.stanford.edu/program/</a><br>
>><br>
>> [ ... ] buffers also add additional lag to a packet’s
transit through the<br>
>> network. If you want to implement a low jitter
service, then deep buffers<br>
>> are decidedly unfriendly! The result is the rather
enigmatic observation<br>
>> that network buffers have to be as big as they need
to be, but no bigger!<br>
>><br>
>> Так какими же? :) Главные выводы из статьи:<br>
>><br>
>> === 1. утверждение "буфер 40MB - отстой" не
выдерживает проверки<br>
>> академическими исследованиями ===<br>
>><br>
>> A study by a Stanford TCP research group in 2004<br>
>> <<a href="http://doi.acm.org/10.1145/1030194.1015499" rel="noreferrer" target="_blank">http://doi.acm.org/10.1145/1030194.1015499</a>>
used the central limit<br>
>> theorem to point to a radically smaller model of
buffer size. Link<br>
>> efficiency can be maintained for N desynchronized
flows with a buffer that<br>
>> 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<br>
>> network. The consequences on router design are
enormous:<br>
>><br>
>> “For example, a 1 Tb/s ISP router carrying one TCP
flow with an RTTmin of<br>
>> 100ms would require 12.5 GB of buffer and off-chip
buffering. *If it<br>
>> carries 100,000 flows, then the buffer can be safely
reduced to less than<br>
>> 40MB, reducing the buffering and worst-case latency
by 99.7%*. With small<br>
>> buffers, the buffer would comfortably fit on a single
chip switch ASIC.”<br>
>> Nick McKeown et. al. Sizing Router Buffers (Redux)<br>
>> <<a href="https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/" rel="noreferrer" target="_blank">https://ccronline.sigcomm.org/2019/ccr-october-2019/sizing-router-buffers-redux/</a>><br>
>><br>
>> иными словами, совершенно не случайно большинство
коммутаторов из списка<br>
>> <a href="https://people.ucsc.edu/~warner/buffer.html" rel="noreferrer" target="_blank">https://people.ucsc.edu/~warner/buffer.html</a>
в портовом диапазоне 48x10/25<br>
>> + 6-8/100 укомплектованы размером буфера 32-40MB -
этого достаточно. А если<br>
>> учесть, что операторские реалии - это 1/10G агрегация
(даже не 25), то<br>
>> можно предположить, что оператор is absolutely safe с
буфером такого<br>
>> размера в своих коммутаторах.<br>
>><br>
>> === 2. использование inline notification улучшает
качество передачи<br>
>> трафика ===<br>
>><br>
>> The advantage of ECN is that the sender is not placed
in the position of<br>
>> being informed of a congestion condition well after
the condition has<br>
>> occurred. Explicit notification allows the sender to
be informed of a<br>
>> condition as it is forming so that it can take action
while there is still<br>
>> a coherent ack pacing signal coming back from the
receiver (that is before<br>
>> packet loss occurs).<br>
>><br>
>> However, ECN is only a single bit marking. Is this
enough? [ ... ] The<br>
>> conclusion from one presentation is that the
single-bit marking, while<br>
>> coarse and non-specific is probably sufficient to
moderate self-clocking<br>
>> TCP flows such that they do not place pressure on
network buffers, leaving<br>
>> the buffers to deal with short term bursts from
unconstrained sources.<br>
>><br>
>> [ ... ]<br>
>><br>
>> And if we want to reduce buffer size and maintain
efficient and fair<br>
>> performance how can we achieve it? One view is that
sender pacing can<br>
>> remove much of the pressure on buffers, and
self-clocking flows can<br>
>> stabilise without emitting transient bursts that need
to be absorbed by<br>
>> buffers. Another view, and one that does not
necessarily contradict the<br>
>> first, is that the self-clocking algorithm can
operate with higher<br>
>> precision if there was some form of feedback from the
network on the state<br>
>> of the network path. This can be as simple as a
single bit (ECN) or a<br>
>> complete trace of path element queue state (HPCC).<br>
>><br>
>><br>
>> всё же имеет смысл хотеть поддержки ECN<br>
>><br>
>> === 3. flow-aware traffic management не является
однозначной заявкой на<br>
>> успех ===<br>
>><br>
>> If the network was in a position to be able to
classify all currently<br>
>> active flows into either elephants or mice, then the
network could be able<br>
>> to use different queuing regimes for each traffic
class. This sorting adds<br>
>> to the cost and complexity of packet switches, and if
scaling pressures are<br>
>> a factor in switch design then it’s not clear that
the additional cost of<br>
>> switch complexity would be offset by a far superior
efficiency outcome in<br>
>> the switching function.<br>
>><br>
>><br>
>> === 4. и если вдруг вендора начинают говорить про
гигантские (напр 100ms)<br>
>> буфера ===<br>
>><br>
>> Further analysis reveals an estimate of packet drop
rates if the network’s<br>
>> buffers were reduced in size, and for this particular
case, the analysis<br>
>> revealed that an 18msec buffer would be able to
sustain a packet drop rate<br>
>> of less than 0.005%.<br>
>><br>
>><br>
>> Спасибо.<br>
>><br>
>><br>
>> On 15.10.2021 14:48, Volodymyr Litovka wrote:<br>
>><br>
>> Привіт,<br>
>><br>
>> а ось тут мене запитали, а я не знаю як відповісти :)
Я розумію, що<br>
>> питання може звучати трішки дивно, але тим не менш -<br>
>><br>
>> за вашим досвідом, скільки буферу (на порт або
shared) достатньо для<br>
>> уникнення або зниження до непомітного рівня втрат
пакетів при появі traffic<br>
>> bursts? Ну тобто цікавлять не теоретичні розрахунки
після відповідей на<br>
>> питання на кшталт "а який час барста?", "а скільки
складає барст у<br>
>> відсотках до нормального" та таке інше, а по
робітничо-селянському -<br>
>> поточний досвід в живій мережі в поточних умовах
поточного Інтернету? Ну,<br>
>> наприклад, на будинковому комутаторі 24x1G + 2x10G з
підключеними<br>
>> середньостатистичними абонентами?<br>
>><br>
>> Хтось взагалі цим питанням париться? :)<br>
>><br>
>> Дякую.<br>
>><br>
>> --<br>
>> Volodymyr Litovka<br>
>> "Vision without Execution is Hallucination." --
Thomas Edison<br>
>><br>
>> --<br>
>> Volodymyr Litovka<br>
>> "Vision without Execution is Hallucination." --
Thomas Edison<br>
>><br>
>> _______________________________________________<br>
>> uanog mailing list<br>
>> <a href="mailto:uanog@uanog.kiev.ua" target="_blank">uanog@uanog.kiev.ua</a><br>
>> <a href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog" rel="noreferrer" target="_blank">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a><br>
>><br>
>> _______________________________________________<br>
>> uanog mailing list<br>
>> <a href="mailto:uanog@uanog.kiev.ua" target="_blank">uanog@uanog.kiev.ua</a><br>
>> <a href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog" rel="noreferrer" target="_blank">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a><br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Best regards,<br>
Alexander V Soroka <a href="http://www.svr.ua/" rel="noreferrer" target="_blank">http://www.svr.ua/</a><br>
AS106-RIPE<br>
mailto:<a href="mailto:alex@euro.net.ua" target="_blank">alex@euro.net.ua</a><br>
<br>
_______________________________________________<br>
uanog mailing list<br>
<a href="mailto:uanog@uanog.kiev.ua" target="_blank">uanog@uanog.kiev.ua</a><br>
<a href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog" rel="noreferrer" target="_blank">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a></blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">Best regards,<br>
<br>
Yevgen Ionov</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
uanog mailing list
<a href="mailto:uanog@uanog.kiev.ua" target="_blank">uanog@uanog.kiev.ua</a>
<a href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog" target="_blank">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a></pre>
</blockquote>
<pre cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Best regards,<br><br>Yevgen Ionov</div>