<font face="arial" size="3"><p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Dave -</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">I tend to agree with Christian's thesis, despite the flaws in his "history".</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">HTTP/3 does NOT specify a congestion control algorithm, and in fact seems to encourage experimentation with wacky concepts.  That's a terrible approach to standardization.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Roskind is not my kind of a hero.  As Bob Dylan said, "to live outside the law you must be honest". But Roskind's approach has not been honest, and the race to deploy *at huge scale* that Google pursues has not been backed up by any serious experimentation to understand its effects. In fact, that approach, non-scientific in the extreme, has become typical of Google's PR-driven and deceptive actions. (See the extremely flawed claims about its "AI" flu-prediction experiment being "better than any public health department" and its flacking of a Jeff Dean Nature publication that was reframed by Google PR and Jeff himself as *proving that upon admission to a hospital, a patient's life or death outcome was predicted far more accurately than was done by a control group of doctorsI*.  NEITHER of those are valid interpretations of the actual experimental results. The Flu test has never been reproduced since, suggesting it was (un?)intentionally cherry-picked to show off)</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Now whether Roskind is typical of Google's Aim, Fire, Ready approach to science and engineering or not, it seems you are calling him a "hero" because of that cowboy approach.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Even though I find the IETF of today full of non-science and corrupt influence, the idea that Roskind is "better" than that, I can't stomach the idea that QUIC or HTTP/3 are "good" merely because they are different and the product of a renegade.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">-----Original Message-----<br />From: "Dave Taht" <dave.taht@gmail.com><br />Sent: Saturday, March 23, 2019 2:15am<br />To: "Matt Taggart" <matt@lackof.org><br />Cc: "cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net><br />Subject: Re: [Cerowrt-devel] Will transport innovation collapse the Internet?<br /><br /></p>
<div id="SafeStyles1553364061">
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">On Sat, Mar 23, 2019 at 1:31 AM Matt Taggart <matt@lackof.org> wrote:<br />><br />> This is from Jan 12th but I hadn't seen it yet.<br />><br />> https://huitema.wordpress.com/2019/01/12/will-transport-innovation-collapse-the-internet/<br /><br />I am awaiting moderation on this comment:<br /><br />While I agree with your thesis, about the problem!<br /><br />I am very bothered by your descriptions of the timelines and who were<br />involved. Other processes are required long before something hits the<br />ietf and recent attempts to file the serial numbers off in favor of<br />corporate “innovation” rather bug me, so:<br /><br />1) “More recent algorithms were developed in the IETF AQM Working<br />Group to address the “buffer bloat” problem, such as FQ-CODEL or PIE.<br />”<br /><br />fq_codel sprang from an outside the ietf effort (bufferbloat.net)<br />founded by myself and jim gettys in 2011. In may of 2012 (after many<br />other innovations in linux such as BQL (which made FQ and AQM<br />technology possible), multiple other fixes in the stack, the<br />publication of Van Jacobson’s and Kathie nichols’s paper on codel<br />(which we turned from ns2 to linux in a week, and arrived in linux<br />mainline the week later)… and two weeks later .- fq_codel incorporated<br />the best of all our research. It took 6 hours to write, and while<br />there have been many minor tweaks along the way, it then took 6 years<br />to standardize in the IETF while achieving a near total deployment in<br />linux today, and is now in freebsd.<br /><br />The ietf AQM working group was founded only because of and after VJ<br />and Kathie’s breakthrough AQM design. It was a hard fight to even get<br />fair queuing as part of the charter.<br /><br />2) QUIC’s real history started with a renegade engineer (Jim Roskind,<br />father of QUIC) that gathered a small team inside google to re-examine<br />tcp in the context of web traffic around 2011 – 3 years before you<br />claim it happened. See the commit logs. They re-evaluated 30 years of<br />discarded tcp ideas, and retried them, much in the manner of how<br />edison would try 3000 ideas to get one. Month in month out, they built<br />release after release, wrote the code, deployed it, made changes to<br />the code and protocol on a monthly basis. They faced enormous barriers<br />by folk that thought we should just fix tcp, or laughed at each new<br />idea and said that couldn’t (or shouldn’t) be done.<br /><br />They just went ahead and did it.<br /><br />Every time they made a “breaking change” in the protocol they bumped<br />the version number. Sometimes it was crypto, sometimes frames,<br />sometimes congestion control, etc.<br /><br />It went through *20* *deployed* revisions before it made the ietf.<br /><br />Looking at the wire spec<br />https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit<br /><br />You can see the long list of recent versions:<br /><br />Q009: added priority as the first 4 bytes on spdy streams.<br />Q010: renumber the various frame types<br />Q011: shrunk the fnv128 hash on NULL encrypted packets from 16 bytes<br />to 12 bytes.<br />Q012: optimize the ack frame format to reduce the size and better<br />handle ranges of nacks, which should make truncated acks virtually<br />impossible. Also adding an explicit flag for truncated acks and moving<br />the ack outside of the connection close frame.<br />Q013: Compressed headers for *all* data streams are serialized into a<br />reserved stream. This ensures serialized handling of headers,<br />independent of stream cancellation notification.<br />Q014: Added WINDOW_UPDATE and BLOCKED frames, no behavioral change.<br />Q015: Removes the accumulated_number_of_lost_packets field from the<br />TCP and inter arrival congestion feedback frames and adds an explicit<br />list of recovered packets to the ack frame.<br />Q016: Breaks out the sent_info field from the ACK frame into a new<br />STOP_WAITING frame.<br />Changed GUID to Connection ID<br />Q017: Adds stream level flow control<br />Q018: Added a PING frame<br />Q019: Adds session/connection level flow control<br />Q020: Allow endpoints to set different stream/session flow control windows<br />Q021: Crypto and headers streams are flow controlled (at stream level)<br />Q023: Ack frames include packet timestamps<br />Q024: HTTP/2-style header compression<br />Q025: HTTP/2-style header keys. Removal of error_details from the<br />RST_STREAM frame.<br />Q026: Token binding, adds expected leaf cert (XLCT) tag to client hello<br />Q027: Adds a nonce to the server hello<br />Q029: Server and client honor QUIC_STREAM_NO_ERROR on early response<br />Q030: Add server side support of certificate transparency.<br />Q031: Adds a SHA256 hash of the serialized client hello messages to<br />crypto proof.<br />Q032: FEC related fields are removed from wire format.<br />Q033: Adds an optional diversification nonce to packet headers, and<br />eliminates the 2 byte and 4 byte connection ID length public flags.<br />Q034: Removes entropy and private flags and changes the ack frame from<br />nack ranges to ack ranges and removes truncated acks.<br />Q035: Allows each endpoint to independently set maximum number of<br />supported incoming streams using the MIDS (“Maximum Incoming Dynamic<br />Streams”) tag instead of the older MSPC (“Maximum Streams Per<br />Connection”) tag.<br />Q036: Adds support for inducing head-of-line blocking between streams<br />via the new FHOL tag in the handshake.<br /><br />Jim Roskind is a hero.<br /><br />…<br /><br />Your article also conflates QUIC with BBR. BBR is a congestion control<br />algorithm. QUIC is a protocol that can use any congestion control<br />algorithm.<br /><br />> --<br />> Matt Taggart<br />> matt@lackof.org<br />> _______________________________________________<br />> Cerowrt-devel mailing list<br />> Cerowrt-devel@lists.bufferbloat.net<br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel<br /><br /><br /><br />-- <br /><br />Dave Täht<br />CTO, TekLibre, LLC<br />http://www.teklibre.com<br />Tel: 1-831-205-9740<br />_______________________________________________<br />Cerowrt-devel mailing list<br />Cerowrt-devel@lists.bufferbloat.net<br />https://lists.bufferbloat.net/listinfo/cerowrt-devel</p>
</div></font>