<div dir="ltr">Am Donnerstag, 27. Oktober 2016 20:14:42 UTC+2 schrieb Dave Taht:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Oct 27, 2016 at 10:57 AM, Yuchung Cheng <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="aUN7Ww5XAAAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">ych...@google.com</a>> wrote:
<br>Well, against cubic on the same link in single queue mode, even
<br>without ecn, life looks like this:
<br>
<br><a href="http://blog.cerowrt.org/flent/bbr-ecncaps/bandwidth-share-creaming-cubic-flowblind-aqm.svg" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fblog.cerowrt.org%2Fflent%2Fbbr-ecncaps%2Fbandwidth-share-creaming-cubic-flowblind-aqm.svg\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE4w7E3KjGjBaeZMoYCrquW9OW2rg';return true;" onclick="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fblog.cerowrt.org%2Fflent%2Fbbr-ecncaps%2Fbandwidth-share-creaming-cubic-flowblind-aqm.svg\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE4w7E3KjGjBaeZMoYCrquW9OW2rg';return true;">http://blog.cerowrt.org/flent/<wbr>bbr-ecncaps/bandwidth-share-<wbr>creaming-cubic-flowblind-aqm.<wbr>svg</a>
<br>
<br>but fq_codel is fine, so long as there is no ecn vs nonecn collission
<br>
<br><a href="http://blog.cerowrt.org/flent/bbr-ecncaps/bandwidth-share-ecn-fq.png" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fblog.cerowrt.org%2Fflent%2Fbbr-ecncaps%2Fbandwidth-share-ecn-fq.png\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEgHzGL1wrt5AzodueJ63lJGL-SgQ';return true;" onclick="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fblog.cerowrt.org%2Fflent%2Fbbr-ecncaps%2Fbandwidth-share-ecn-fq.png\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEgHzGL1wrt5AzodueJ63lJGL-SgQ';return true;">http://blog.cerowrt.org/flent/<wbr>bbr-ecncaps/bandwidth-share-<wbr>ecn-fq.png</a>
</blockquote><div> </div><div>Looks like you are on the right track. I've been done some work on flow/congestion control on my net2o protocol, which is not limited by TCP's constraints, and I think you should look at what I did. See my 31c3 presentation.</div><div><br></div><div>Flow/congestion control discussion starts at 46:00, page 79 on the slides.</div><div><br></div><div>https://fossil.net2o.de/net2o/doc/trunk/wiki/31c3.md<br></div><div><br></div><div>The primary algorithm is really simple and straight-forward: I send a short burst out, and measure the bandwidth achieved on the receiver side - this time is used to calculate the delays between two bursts, the average sending rate.  In TCP, you would measure the ACKs back at the sender, and calculate bandwidth achieved based on the delays between the acks; that should be a bit less precise, but good enough.  These bursts allow to adapt to changing loads quickly, and there is no need to fill the buffer at all (you don't need to create more increase in RTD than those few packets in the burst take).  This primary algorithm is ignorant of the buffer fill state, so it works together with a buffer filled up by normal TCP congestion control.</div><div><br></div><div>I took a great deal at providing fairness even without a fair queuing policy (much more complicated second order regulation; I'm still not happy with the results and trying to figure out something better), therefore, FQ is really necessary, everywhere, including on the last mile routers (see timings of 4 concurrent streams on page 108 w/o FQ and 109 w. net2o's own FQ).  The spikes in the last diagrams result from the receivers regularly writing the data away to disk, and when they do so, temporarily stopping the transmission of their stream for a short period of time.  That shows how fast the bursts can react on changed bandwidth.  With just one client, I can hide that delay with a second thread, but with 4 clients on one CPU, it just shows up.</div></div>