<font face="arial" size="2"><p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">What does this have to do with QUIC and "spin bits"?</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Just asking because Michael triggered me to read the QUIC document he cited and that got me to go and read RFC 9002 which supposedly (but not really) suggests that QUIC has a "solution" to congestion in it.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">I'm awfully skeptical that QUIC's solution is a solution and not a new dramatic problem.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">To me, the key metric of solution is that it can be deployed in less than a year across the entire current Internet - and it works. Otherwise, it's just handwaving but-if-only-we-did-it-this-other-way everything would be great. That is what ECN has been all along, along with diffserv.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">I think ECN has a shot at being helpful, but the core problem is that it was premised on the idea that in order to mark, you first need to create a bloated buffer in some bottleneck link, and that all endpoints will treat ECN as they treat a dropped packet. But the endpoints stack designers are still measuring throughput only, so they have no incentive to decrease windows, because that would make throughput low. This isn't a problem with ECN, really, you could mark a packet that goes through a node that is not already overloaded, but it takes courage to do that when all the industry is saying "you just lowered throughput from 99.9% to 98%".</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">On Thursday, April 14, 2022 1:16pm, "Dave Taht" <dave.taht@gmail.com> said:<br /><br /></p>
<div id="SafeStyles1649968641">
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">> Actually, in looking back at what I wrote, I was<br />> <br />> A) comparing a recent rtt-fairness result I'd got without ECN with<br />> multiple flows at 20ms to 260ms RTT that I was insanely pleased with.<br />> <br />> B) while trying to understand and asking about what sort of<br />> RTT-fairness results were being achieved with early ECN marking in the<br />> dctcp world. which until recently was mostly shooting for fairness in<br />> the sub-us to 2ms range. I was laboriously starting over from<br />> scratch, reading the original papers, tracking the breadcrumbs from<br />> 2009 until today, so I'd stumbled on some thoughts in the next paper<br />> after the dctcp paper that I was too lazy to try and correlate to<br />> present day "prague" and BBRv2 thinking.<br />> </p>
</div></font>