<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 30.12.2021 12:56, Maksym Tulyuk
wrote:</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:44e95a0e-d070-4f9a-9e7d-43152cf2522c@Spark">У меня
совсем другие выводы:<br>
<div name="messageBodySection">
<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">
<div name="messageBodySection">
<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">
<div name="messageBodySection">НО это все было в 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>
</body>
</html>