<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Категоричная чепуха. Весь этот тред посвящен не вопросу "как
купить дешевле", а вопросу "как сделать эффективно".</p>
<div class="moz-cite-prefix">On 04.01.2022 15:57, Alexander V Soroka
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:87546108.20220104155724@euro.net.ua">
<pre class="moz-quote-pre" wrap="">Привет !
Ваша всеобщая проблема сейчас в том, что вы "роетесь в мусоре" в
надежде найти там алмазы :-) а их там нет - есть только выбор между
плохим и совсем плохим.
Поясню о чем я.
1) Забугорные сетевые админы не станут вот это вот все (что мы сейчас)
обсуждать - они просто примерно посчитают или смоделируют "набросы
нагрузки" и выдадут запрос манагерам на "купить вот такойто свич".
Никто не будет выпиливать лобзиком, как привыкли мы(вы).
2) Мы тут и сейчас пытаемся "и рыбку и :-)". Причем за малые деньги...
А раз так, то меня надо слушать и смотреть именно в сторону FPGA
решений, даже мультичиповых, т.е. вплоть до разработки спец-печатной
платы с несколькими FPGA , и отдельной памятью для них, чтобы сделать
именно то что вы хотите сейчас, и спать спокойно что это все не
устареет завтра, и в случае чего нагибается под нечто новое по
сервисам-переделкам.
3) Главная проблема вас (тех кто сейчас в UANET ) админит, в том, что
вы не собираетесь ничего разрабатывать :-) вам нужно готовое
каличное(малобюджетное) решение на все сложные случаи.
А это там, на западе, никому не интересно, особенно в промышленных
коммерческих масштабах трафика - ПОТОМУ ЧТО там для коммерческого
просто считают деньги и покупают тот трактор который соответствует
огороду. И платит там Клиент не сущие копейки, так что "бюджет
развития" ненулевой.
Поэтому то что вы хотите найти как ГОТОВОЕ и кем-то поддерживаемое
решение, попросту НЕ СУЩЕСТВУЕТ, по причинам описанным мной выше.
Так что у вас есть очень хороший шанс стать первыми в этом пути, и
сделать то, что потом такие-же "слаборазвитые страны" у вас будут
покупать. Т.е. напрячься и родить коммерческий продукт.
Но это программисты нужны :-) а не Админы, которым лень писать код а
хочется только текст в конфигах ковырять :-)
Так что в итоге вся дискуссия превращается в "копание в сортах говна",
и повышения собственной эрудиции.
Извините за резкость, но со стороны (моей) это выглядит именно так...
Tuesday, January 4, 2022, 3:41:27 PM, Volodymyr Litovka <a class="moz-txt-link-abbreviated" href="mailto:doka@funlab.cc">doka@funlab.cc</a> you wrote:
VL> Привет,
VL> перенаправление на другой dst ip/port - это задача app layer.
VL> Этим действием, теоретически, может являться как раз попытка
VL> использования другого маршрута (маршрутизатора, коммутатора и/или
VL> линейной карты) с целью использовать другой пакетный буфер. Но мне
VL> тяжело себе представить, как может абстрактный "нетфликс"
VL> рассчитывать, что где-то по дороге до абстрактного "бердичева"
VL> что-то может ходить разными путями или балансироваться по разным линейным картам / port groups.
VL> Вопрос заключается в том, что независимо от выбора устройства, в
VL> нем присутствует shared buffer для какой-то группы портов (все
VL> порты; сгруппированные внутри одного ASIC/FPGA; разобранные по
VL> отдельным линейным картам) и какова должна быть стратегия
VL> определения оптимального размера пакетного буфера, чтобы соблюсти
VL> компромисс между количеством требуемой памяти (читай - ценой
VL> устройства) и эффективностью доставки данных в условиях всплесков нагрузки.
VL> On 04.01.2022 15:31, Yevgen Ionov wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Приветствую,
В данном контексте ключевой фактор использование P4 для > программирования каких-то unusual tasks..
Использование FPGA архитектуры "на вырост" может быть не > оправданным, ввиду высокой стоимости отдельного свитча.
Cisco в качестве примера unusual task демонстрирует перенаправление > video stream каждые 20 sec на новый DST IP/Port, т.е. video-frame > после каждой 20 сек идет по новому path и это уже даже не TCP fields.
<a class="moz-txt-link-freetext" href="https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKDCN-2694.pdf">https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKDCN-2694.pdf</a>
Экстраполируя это на текущую дискуссию, возможно проблемы с > буферизацией на 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 <a class="moz-txt-link-rfc2396E" href="mailto:alex@euro.net.ua"><alex@euro.net.ua></a> wrote:
Привет !
частично ответыт тут есть:
ASIC vs. FPGA: What’s the difference?
<a class="moz-txt-link-freetext" href="https://www.sondrel.com/blog/asic-vs.-fpga:-what%27s-the-difference">https://www.sondrel.com/blog/asic-vs.-fpga:-what%27s-the-difference</a>
Цитаты:
...Термин 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
<a class="moz-txt-link-abbreviated" href="mailto:yevgen.ionov@gmail.com">yevgen.ionov@gmail.com</a> you wrote:
YI> Привет Максим,
>> Из грустного: сколько нужно академиков, чтобы написать доклад
на 2
YI> страницы <a class="moz-txt-link-freetext" href="http://buffer-workshop.stanford.edu/papers/paper18.pdf">http://buffer-workshop.stanford.edu/papers/paper18.pdf</a>
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
<a class="moz-txt-link-rfc2396E" href="mailto:maksym@tulyuk.com"><maksym@tulyuk.com></a> 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% максимум <a class="moz-txt-link-freetext" href="https://stats.ams-ix.net/sflow/size.html">https://stats.ams-ix.net/sflow/size.html</a> и
как видно
>> из графика 35% - это пакеты размером 64-127 bytes
>>
>> Из интересного:
>>
>> - Understanding switch buffer utilization in CLOS data
center fabric
>> (Verizon)
>>
<a class="moz-txt-link-freetext" href="http://buffer-workshop.stanford.edu/slides/Understanding%20switch%20buffer%20utilization%20in%20CLOS%20data%20center%20fabric.pptx">http://buffer-workshop.stanford.edu/slides/Understanding%20switch%20buffer%20utilization%20in%20CLOS%20data%20center%20fabric.pptx</a>
>> - Buffer sizing and Video QoE Measurements at Netflix
>>
<a class="moz-txt-link-freetext" href="http://buffer-workshop.stanford.edu/slides/netflix%20buffer%20sizing.pdf">http://buffer-workshop.stanford.edu/slides/netflix%20buffer%20sizing.pdf</a>
>> - Queueing at the Telco Service Edge (Deutsche Telekom)
>>
<a class="moz-txt-link-freetext" href="http://buffer-workshop.stanford.edu/slides/BS_QueueingEdge_2019_12_03.pdf">http://buffer-workshop.stanford.edu/slides/BS_QueueingEdge_2019_12_03.pdf</a>
>> - Buffer Sizing Experiments at Facebook
>> <a class="moz-txt-link-freetext" href="http://buffer-workshop.stanford.edu/papers/paper30.pdf">http://buffer-workshop.stanford.edu/papers/paper30.pdf</a>
>>
>> Из грустного: сколько нужно академиков, чтобы написать доклад на 2
>> страницы <a class="moz-txt-link-freetext" href="http://buffer-workshop.stanford.edu/papers/paper18.pdf">http://buffer-workshop.stanford.edu/papers/paper18.pdf</a>
>>
>> НО это все было в 2019, а сейчас кажется что Гугл был прав и
будущее это
>> UDP+QUIC и все исследования на тему буферов нужно начинать с нуля.
>>
>> Максим
>> On 28 Dec 2021, 10:02 +0100, Volodymyr Litovka
<a class="moz-txt-link-rfc2396E" href="mailto:doka@funlab.cc"><doka@funlab.cc></a>, wrote:
>>
>> Привет,
>>
>> для любителей лонгридов, есть прекрасная статья про стратегии
буферизации
>> и обработки очередей по результатам воркшопа в Стэнфордском
университете в
>> 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>
>>
>> Для совсем уж любителей копать - материалы этого воркшопа
доступны тут:
>> <a class="moz-txt-link-freetext" href="http://buffer-workshop.stanford.edu/program/">http://buffer-workshop.stanford.edu/program/</a>
>>
>> [ ... ] 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
>> <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:
>>
>> *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)
>>
<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>
>>
>> иными словами, совершенно не случайно большинство коммутаторов
из списка
>> <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 с буфером
такого
>> размера в своих коммутаторах.
>>
>> === 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
>> <a class="moz-txt-link-abbreviated" href="mailto:uanog@uanog.kiev.ua">uanog@uanog.kiev.ua</a>
>> <a class="moz-txt-link-freetext" href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a>
>>
>> _______________________________________________
>> uanog mailing list
>> <a class="moz-txt-link-abbreviated" href="mailto:uanog@uanog.kiev.ua">uanog@uanog.kiev.ua</a>
>> <a class="moz-txt-link-freetext" href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a>
-- > Best regards,
Alexander V Soroka <a class="moz-txt-link-freetext" href="http://www.svr.ua/">http://www.svr.ua/</a>
AS106-RIPE
<a class="moz-txt-link-freetext" href="mailto:alex@euro.net.ua">mailto:alex@euro.net.ua</a>
_______________________________________________
uanog mailing list
<a class="moz-txt-link-abbreviated" href="mailto:uanog@uanog.kiev.ua">uanog@uanog.kiev.ua</a>
<a class="moz-txt-link-freetext" href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a>
-- > Best regards,
Yevgen Ionov
_______________________________________________
uanog mailing list
<a class="moz-txt-link-abbreviated" href="mailto:uanog@uanog.kiev.ua">uanog@uanog.kiev.ua</a>
<a class="moz-txt-link-freetext" href="https://mailman.uanog.kiev.ua/mailman/listinfo/uanog">https://mailman.uanog.kiev.ua/mailman/listinfo/uanog</a>
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</body>
</html>