[uanog] switch's port buffers

[Maksym Tulyuk]

Из личного опыта: покупать и использовать разные типы коммутаторов в ДС - дорого и неудобно. Поэтому, можно купить с большими буферами, а для голоса включать QoS ;)

P.S. Теоретически в QUIC все похоже на существующие решения, но практический эксперимент всегда лучше

we concluded that integrating QUIC in our apps would reduce the tail-end latencies compared to TCP. We witnessed a reduction of 10-30 percent in tail-end latencies for HTTPS traffic at scale in our rider and driver apps. In addition to improving the performance of our apps in low connectivity networks, QUIC gives us end-to-end control over the flow of packets in the user space (c) Uber devs

Our tests have shown that QUIC offers improvements on several metrics. People on Facebook experienced a 6 percent reduction in request errors, a 20 percent tail latency reduction, and a 5 percent reduction in response header size relative to HTTP/2. This had cascading effects on other metrics as well, indicating that peoples’ experience was greatly enhanced by QUIC (c) Facebook devs

The experiments showed that QUIC had a transformative effect on video metrics in the Facebook app. Mean time between rebuffering (MTBR), a measure of the time between buffering events, improved in aggregate by up to 22 percent, depending on the platform. The overall error count on video requests was reduced by 8 percent. The rate of video stalls was reduced by 20 percent. (C) ) Facebook devs

И при этом никто на буфера не жалуется.

Максим
On 30 Dec 2021, 12:43 +0100, Volodymyr Litovka <doka at funlab.cc>, wrote:

On 30.12.2021 12:56, Maksym Tulyuk wrote:

	У меня совсем другие выводы:
[ ... ]
2) все академики продолжают обсуждать TCP tuning и не хотят видеть, что уже в 2019 у Deutsche Telekom он составлял всего 84.4% (все остальное - UDP с быстрым ростом QUIC)
КМК, могу ошибаться

• выбор underlaying UDP для QUIC обсуловил появление у него своего собственного flow control, который точно так же может опираться на ECN bit в IP-заголовке и давать обратную связь в рамках QUIC flow control
• понятие "flow" применимо как к TCP-трафику (здесь оно натурально мапится на TCP session), так и к UDP-трафику (src/dst ip/port), потому, я полагаю, когда академики говорят про "100,000 flows", то речь идет именно об автономных/асинхронных потоках данных, а не о TCP sessions

	3) все доклады рассказывают про MTU size 1500, хотя в реальном мире такого трафика 50% максимум https://stats.ams-ix.net/sflow/size.html и как видно из графика 35% - это пакеты размером 64-127 bytes
полагаю, что это не имеет большого значения для конечного результата. Для простоты тестирования выбрали 1500, но правила управления трафиком in general не драматически зависят от величины контейнера.
	НО это все было в 2019, а сейчас кажется что Гугл был прав и будущее это UDP+QUIC и все исследования на тему буферов нужно начинать с нуля.
С учетом "КМК" выше, still КМК, не придется - (1) QUIC может использовать ECN и (2) характер сервисов (требования к пропускной полосе и джиттеру) не поменяются в зависимости от underlying protocol - голос всё так же будет страдать от глубоких буферов, а bigdata всё также будет плевать на время доставки, требуя взамен deep buffers для гарантированной доставки :)
Собственно, продуктовый перечень коммутаторов у вендоров подчеркивает это - есть линейные карты и коммуаторы с 40-80MB shared buffer, а есть - модульные с разными типами карт - 40-80MB и 4-8GB буферами. С соответствующим ценником: для массового применения - первые, для отдельных случаев (дорого) - вторые.
Спасибо
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20211230/13b940f7/attachment-0001.html>