<div dir="ltr"><div>If it's of any help... the bloat mailing list at <a href="http://lists.bufferbloat.net">lists.bufferbloat.net</a> has the largest concentration of</div><div>queue theorists and network operator + developers I know of. (also, bloat readers, this ongoing thread on nanog about 400Gbit is fascinating)</div><div><br></div>There is 10+ years worth of debate in the archives: <a href="https://lists.bufferbloat.net/pipermail/bloat/2012-May/thread.html">https://lists.bufferbloat.net/pipermail/bloat/2012-May/thread.html</a> as one example. <div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 7, 2022 at 10:14 AM dip <<a href="mailto:diptanshu.singh@gmail.com">diptanshu.singh@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br><div><div><div>Disclaimer: I often use the M/M/1 queuing assumption for much of my work to keep the maths simple and believe that I am reasonably aware in which context it's a right or a wrong application :). Also, I don't intend to change the core topic of the thread, but since this has come up, I couldn't resist.</div><div><br></div><div><font color="#351c75">>> With 99% load M/M/1, 500 packets (750kB for 1500B MTU) of<br>>> buffer is enough to make packet drop probability less than<br>>> 1%. With 98% load, the probability is 0.0041%.</font><br></div><div><font color="#351c75"><br></font></div><div>To expand the above a bit so that there is no ambiguity. The above assumes that the router behaves like an M/M/1 queue. The expected number of packets in the systems can be given by</div><div><br></div><div><img alt="image.png" width="106" height="43" style="margin-right: 0px;"><br></div></div><div>where <img alt="image.png" width="15" height="17"> is the utilization. The probability that at least B packets are in the system is given by <img alt="image.png" width="25" height="22"> where B is the number of packets in the system. for a link utilization of .98, the packet drop probability is .98**(500) = 0.000041%. for a link utilization of 99%, .99**500 = 0.00657%.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Regrettably, tcp ccs, by design do not stop growth until you get that drop, e.g. 100+% utilization.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div></div><div><div><font color="#351c75">>> When many TCPs are running, burst is averaged and traffic</font></div><font color="#351c75">>> is poisson.</font><br></div><div><font color="#351c75"><br></font></div><div>M/M/1 queuing assumes that traffic is Poisson, and the Poisson assumption is</div><div>1) The number of sources is infinite <br><div>2) The traffic arrival pattern is random. </div><div><br></div><div>I think the second assumption is where I often question whether the traffic arrival pattern is truly random. I have seen cases where traffic behaves more like self-similar. Most Poisson models rely on the Central limit theorem, which loosely states that the sample distribution will approach a normal distribution as we aggregate more from various distributions. The mean will smooth towards a value. </div></div><div><div><br></div><div>Do you have any good pointers where the research has been done that today's internet traffic can be modeled accurately by Poisson? For as many papers supporting Poisson, I have seen as many papers saying it's not Poisson.</div><div><br></div><div><a href="https://www.icir.org/vern/papers/poisson.TON.pdf" target="_blank">https://www.icir.org/vern/papers/poisson.TON.pdf</a><br></div><div><a href="https://www.cs.wustl.edu/~jain/cse567-06/ftp/traffic_models2/#sec1.2" target="_blank">https://www.cs.wustl.edu/~jain/cse567-06/ftp/traffic_models2/#sec1.2</a></div></div></div></div></div></blockquote><div><br></div><div>I am firmly in the not-poisson camp, however, by inserting (esp) FQ and AQM techniques on the bottleneck links it is very possible to smooth traffic into this more easily analytical model - and gain enormous benefits from doing so. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 7 Aug 2022 at 04:18, Masataka Ohta <<a href="mailto:mohta@necom830.hpcl.titech.ac.jp" target="_blank">mohta@necom830.hpcl.titech.ac.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Saku Ytti wrote:<br>
<br>
>> I'm afraid you imply too much buffer bloat only to cause<br>
>> unnecessary and unpleasant delay.<br>
>><br>
>> With 99% load M/M/1, 500 packets (750kB for 1500B MTU) of<br>
>> buffer is enough to make packet drop probability less than<br>
>> 1%. With 98% load, the probability is 0.0041%.<br>
<br>
> I feel like I'll live to regret asking. Which congestion control<br>
> algorithm are you thinking of?<br>
<br>
I'm not assuming LAN environment, for which paced TCP may<br>
be desirable (if bandwidth requirement is tight, which is<br>
unlikely in LAN).<br>
<br>
> But Cubic and Reno will burst tcp window growth at sender rate, which<br>
> may be much more than receiver rate, someone has to store that growth<br>
> and pace it out at receiver rate, otherwise window won't grow, and<br>
> receiver rate won't be achieved.<br>
<br>
When many TCPs are running, burst is averaged and traffic<br>
is poisson.<br>
<br>
> So in an ideal scenario, no we don't need a lot of buffer, in<br>
> practical situations today, yes we need quite a bit of buffer.<br>
<br>
That is an old theory known to be invalid (Ethernet switches with<br>
small buffer is enough for IXes) and theoretically denied by:<br>
<br>
Sizing router buffers<br>
<a href="https://dl.acm.org/doi/10.1145/1030194.1015499" rel="noreferrer" target="_blank">https://dl.acm.org/doi/10.1145/1030194.1015499</a><br>
<br>
after which paced TCP was developed for unimportant exceptional<br>
cases of LAN.<br>
<br>
> Now add to this multiple logical interfaces, each having 4-8 queues,<br>
> it adds up.<br>
<br>
Having so may queues requires sorting of queues to properly<br>
prioritize them, which costs a lot of computation (and<br>
performance loss) for no benefit and is a bad idea.<br>
<br>
> Also the shallow ingress buffers discussed in the thread are not delay<br>
> buffers and the problem is complex because no device is marketable<br>
> that can accept wire rate of minimum packet size, so what trade-offs<br>
> do we carry, when we get bad traffic at wire rate at small packet<br>
> size? We can't empty the ingress buffers fast enough, do we have<br>
> physical memory for each port, do we share, how do we share?<br>
<br>
People who use irrationally small packets will suffer, which is<br>
not a problem for the rest of us.<br>
<br>
Masataka Ohta<br>
<br>
<br>
</blockquote></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>FQ World Domination pending: <a href="https://blog.cerowrt.org/post/state_of_fq_codel/" target="_blank">https://blog.cerowrt.org/post/state_of_fq_codel/</a><br></div><div>Dave Täht CEO, TekLibre, LLC <br></div></div></div></div></div>