<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">Из личного опыта: покупать и использовать разные типы коммутаторов в ДС - дорого и неудобно. Поэтому, можно купить с большими буферами, а для голоса включать QoS ;)<br />
<br />
P.S. Теоретически в QUIC все похоже на существующие решения, но практический эксперимент всегда лучше<br />
<br />
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<br />
<br />
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<br />
<br />
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<br />
<br />
И при этом никто на буфера не жалуется.</div>
</div>
<div name="messageSignatureSection"><br />
<div class="matchFont">Максим</div>
</div>
<div name="messageReplySection">On 30 Dec 2021, 12:43 +0100, Volodymyr Litovka <doka@funlab.cc>, wrote:<br />
<blockquote type="cite" style="border-left-color:#1abc9c; margin:5px 5px; padding-left:10px; border-left-width:thin; border-left-style:solid;" class="spark_indent">
<p><br /></p>
<div class="moz-cite-prefix" dir="auto">On 30.12.2021 12:56, Maksym Tulyuk wrote:</div>
<div class="moz-cite-prefix" dir="auto"><br /></div>
<blockquote type="cite" cite="mid:44e95a0e-d070-4f9a-9e7d-43152cf2522c@Spark" style="border-left-color:#e67e22; margin:5px 5px; padding-left:10px; border-left-width:thin; border-left-style:solid;" class="spark_indent">У меня совсем другие выводы:<br />
<div name="messageBodySection" dir="auto">
<div dir="auto">[ ... ]<br />
2) все академики продолжают обсуждать TCP tuning и не хотят видеть, что уже в 2019 у Deutsche Telekom он составлял всего 84.4% (все остальное - UDP с быстрым ростом QUIC)<br /></div>
</div>
</blockquote>
<p>КМК, могу ошибаться<br /></p>
<ul>
<li>выбор underlaying UDP для QUIC обсуловил появление у него своего собственного flow control, который точно так же <i><u>может</u></i> опираться на ECN bit в IP-заголовке и давать обратную связь в рамках QUIC flow control</li>
<li>понятие "flow" применимо как к TCP-трафику (здесь оно натурально мапится на TCP session), так и к UDP-трафику (src/dst ip/port), потому, я полагаю, когда академики говорят про "100,000 flows", то речь идет именно об автономных/асинхронных потоках данных, а не о TCP sessions<br /></li>
</ul>
<blockquote type="cite" cite="mid:44e95a0e-d070-4f9a-9e7d-43152cf2522c@Spark" style="border-left-color:#e67e22; margin:5px 5px; padding-left:10px; border-left-width:thin; border-left-style:solid;" class="spark_indent">
<div name="messageBodySection" dir="auto">
<div dir="auto">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<br /></div>
</div>
</blockquote>
<p>полагаю, что это не имеет большого значения для конечного результата. Для простоты тестирования выбрали 1500, но правила управления трафиком in general не драматически зависят от величины контейнера.<br /></p>
<blockquote type="cite" cite="mid:44e95a0e-d070-4f9a-9e7d-43152cf2522c@Spark" style="border-left-color:#e67e22; margin:5px 5px; padding-left:10px; border-left-width:thin; border-left-style:solid;" class="spark_indent">
<div name="messageBodySection" dir="auto">НО это все было в 2019, а сейчас кажется что Гугл был прав и будущее это UDP+QUIC и все исследования на тему буферов нужно начинать с нуля.</div>
</blockquote>
<p>С учетом "КМК" выше, still КМК, не придется - (1) QUIC может использовать ECN и (2) характер сервисов (требования к пропускной полосе и джиттеру) не поменяются в зависимости от underlying protocol - голос всё так же будет страдать от глубоких буферов, а bigdata всё также будет плевать на время доставки, требуя взамен deep buffers для гарантированной доставки :)</p>
<p>Собственно, продуктовый перечень коммутаторов у вендоров подчеркивает это - есть линейные карты и коммуаторы с 40-80MB shared buffer, а есть - модульные с разными типами карт - 40-80MB и 4-8GB буферами. С соответствующим ценником: для массового применения - первые, для отдельных случаев (дорого) - вторые.</p>
<p>Спасибо<br /></p>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
_______________________________________________<br />
uanog mailing list<br />
uanog@uanog.kiev.ua<br />
https://mailman.uanog.kiev.ua/mailman/listinfo/uanog<br /></blockquote>
</div>
</body>
</html>