[uanog] switch's port buffers
Vladimir Sharun
vladimir.sharun at ukr.net
Tue Jan 4 21:29:10 EET 2022
Александр Василич,
Внутри security appliance'ов (PA, F5, Checkpoint, Fortigate) < $100k стоит обычный писюк на линуксе. Когда Вам расскажут, что божественные секьюрити апплайенсы используют FPGA чтобы быть круче, попросите ПОКАЗАТЬ их и ЧТО они делают. Ото открытие будет, гарантирую.
Juniper'овские свичи (QFX) - говно и палки на FreeBSD в control plane.
Netflix раздаёт из говна и палок на FreeBSD 200Гбит с железки.
Можете привести пример FPGA, который был бы экономически целесообразен и широко использовался и/или свой опыт построения информационной системы с использованием FPGA, мы с удовольствием послушаем.
4 січня 2022, 21:15:56, від "Alexander V Soroka" <alex at euro.net.ua>:
Привет !
...вот все со мной спорят :-)...
Хеон? серьезно? с гирями на ногах ФрииБСД, с узкими местами общей шины
и контроллеров чипсетов? и это не решение из говна и палок? :-)
Шифрование на FPGA по любому будет лучше и быстрее чем прога на
стандартном проце, с довеском операционки и ее таймингов на
"многозадачность" и "паралельные вычисления" :-) на одном ядре
двух-трех потоков :).
Ну разве что 12 поколение Интела, новое, с 12 ядрами и ДДР5 памяти чем
то может поможет, но...
снова биться головой об эзернет контроллеры и шину данных...
Cisco не зря строит свои молотилки с распределенными мозгами на
обработку пакетов, а вы застряли в вчерашнем дне, когда писюк как
раутер был дешевле и проще чем покупать дорогую железяку :)
Нетфликс пусть и гики, но возможности железа не перепрыгнуть, да и
зачем? если можно сразу заложить то что будет лучше справляться с
этими задачами. Иначе никто ничего кроме писюковых серверов бы не
производил :)
задумайтесь...
Tuesday, January 4, 2022, 7:59:37 PM, Vladimir Sharun vladimir.sharun at ukr.net you wrote:
VS> Сорян всем,
VS> 200G - это не 2,5 гигабайта/с трафа, а 25 гигабайт/с.
VS> Возможности DDR4 где-то уже рядом c этими цифрами. А они их получили на Xeon Scalable.
VS> 4 січня 2022, 19:44:33, від "Vladimir Sharun" <vladimir.sharun at ukr.net>:
VS> Александр Василич,
VS> Netflix - это сборище гиков в хорошем смысле слова. Они из любви
VS> к искусству доводят до технологического совершенства почти всё, до чего дотягиваются.
VS> Т.е. нет, эти таки будут и моделировать и искать лучшие решения.
VS> Из хорошего, так это то, что Netflix свои наработки отдаёт в
VS> комьюнити (FreeBSD как минмиум в частности).
VS> Они сначала поставили себе цель 100G отдать с одного сервера
VS> (шифрованного, т.е. TLS), потом вышли на 200G (и тоже достигли).
VS> Это несколько отдельных задач: выдать столько трафа - это одна,
VS> сгенерить столько трафа - другая, пошифровать - третья. И всё это
VS> должно работать опережая сеть по скорости.
VS> Просто в цифрах: надо выдать два с половиной гигабайта в секунду пошифрованного трафа.
VS> Для справки можно заглянуть сколько стоят железки, которые могут
VS> сделать VPN на двести гиг, чтобы понять, через какой челленж они проходят.
VS> 4 січня 2022, 15:57:32, від "Alexander V Soroka" <alex at euro.net.ua>:
VS> Привет !
VS> Ваша всеобщая проблема сейчас в том, что вы "роетесь в мусоре" в
VS> надежде найти там алмазы :-) а их там нет - есть только выбор между
VS> плохим и совсем плохим.
VS> Поясню о чем я.
VS> 1) Забугорные сетевые админы не станут вот это вот все (что мы сейчас)
VS> обсуждать - они просто примерно посчитают или смоделируют "набросы
VS> нагрузки" и выдадут запрос манагерам на "купить вот такойто свич".
VS> Никто не будет выпиливать лобзиком, как привыкли мы(вы).
VS> 2) Мы тут и сейчас пытаемся "и рыбку и :-)". Причем за малые деньги...
VS> А раз так, то меня надо слушать и смотреть именно в сторону FPGA
VS> решений, даже мультичиповых, т.е. вплоть до разработки спец-печатной
VS> платы с несколькими FPGA , и отдельной памятью для них, чтобы сделать
VS> именно то что вы хотите сейчас, и спать спокойно что это все не
VS> устареет завтра, и в случае чего нагибается под нечто новое по
VS> сервисам-переделкам.
VS> 3) Главная проблема вас (тех кто сейчас в UANET ) админит, в том, что
VS> вы не собираетесь ничего разрабатывать :-) вам нужно готовое
VS> каличное(малобюджетное) решение на все сложные случаи.
VS> А это там, на западе, никому не интересно, особенно в промышленных
VS> коммерческих масштабах трафика - ПОТОМУ ЧТО там для коммерческого
VS> просто считают деньги и покупают тот трактор который соответствует
VS> огороду. И платит там Клиент не сущие копейки, так что "бюджет
VS> развития" ненулевой.
VS> Поэтому то что вы хотите найти как ГОТОВОЕ и кем-то поддерживаемое
VS> решение, попросту НЕ СУЩЕСТВУЕТ, по причинам описанным мной выше.
VS> Так что у вас есть очень хороший шанс стать первыми в этом пути, и
VS> сделать то, что потом такие-же "слаборазвитые страны" у вас будут
VS> покупать. Т.е. напрячься и родить коммерческий продукт.
VS> Но это программисты нужны :-) а не Админы, которым лень писать код а
VS> хочется только текст в конфигах ковырять :-)
VS> Так что в итоге вся дискуссия превращается в "копание в сортах говна",
VS> и повышения собственной эрудиции.
VS> Извините за резкость, но со стороны (моей) это выглядит именно так...
VS> Tuesday, January 4, 2022, 3:41:27 PM, Volodymyr Litovka doka at funlab.cc 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:
>>> Приветствую,
>>>
>>> В данном контексте ключевой фактор использование 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
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20220104/4eb172a3/attachment-0001.html>
More information about the uanog
mailing list