Dave - I tend to agree with Christian's thesis, despite the flaws in his "history". 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. 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) 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. 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. -----Original Message----- From: "Dave Taht" Sent: Saturday, March 23, 2019 2:15am To: "Matt Taggart" Cc: "cerowrt-devel" Subject: Re: [Cerowrt-devel] Will transport innovation collapse the Internet? On Sat, Mar 23, 2019 at 1:31 AM Matt Taggart wrote: > > This is from Jan 12th but I hadn't seen it yet. > > https://huitema.wordpress.com/2019/01/12/will-transport-innovation-collapse-the-internet/ I am awaiting moderation on this comment: While I agree with your thesis, about the problem! I am very bothered by your descriptions of the timelines and who were involved. Other processes are required long before something hits the ietf and recent attempts to file the serial numbers off in favor of corporate “innovation” rather bug me, so: 1) “More recent algorithms were developed in the IETF AQM Working Group to address the “buffer bloat” problem, such as FQ-CODEL or PIE. ” fq_codel sprang from an outside the ietf effort (bufferbloat.net) founded by myself and jim gettys in 2011. In may of 2012 (after many other innovations in linux such as BQL (which made FQ and AQM technology possible), multiple other fixes in the stack, the publication of Van Jacobson’s and Kathie nichols’s paper on codel (which we turned from ns2 to linux in a week, and arrived in linux mainline the week later)… and two weeks later .- fq_codel incorporated the best of all our research. It took 6 hours to write, and while there have been many minor tweaks along the way, it then took 6 years to standardize in the IETF while achieving a near total deployment in linux today, and is now in freebsd. The ietf AQM working group was founded only because of and after VJ and Kathie’s breakthrough AQM design. It was a hard fight to even get fair queuing as part of the charter. 2) QUIC’s real history started with a renegade engineer (Jim Roskind, father of QUIC) that gathered a small team inside google to re-examine tcp in the context of web traffic around 2011 – 3 years before you claim it happened. See the commit logs. They re-evaluated 30 years of discarded tcp ideas, and retried them, much in the manner of how edison would try 3000 ideas to get one. Month in month out, they built release after release, wrote the code, deployed it, made changes to the code and protocol on a monthly basis. They faced enormous barriers by folk that thought we should just fix tcp, or laughed at each new idea and said that couldn’t (or shouldn’t) be done. They just went ahead and did it. Every time they made a “breaking change” in the protocol they bumped the version number. Sometimes it was crypto, sometimes frames, sometimes congestion control, etc. It went through *20* *deployed* revisions before it made the ietf. Looking at the wire spec https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit You can see the long list of recent versions: Q009: added priority as the first 4 bytes on spdy streams. Q010: renumber the various frame types Q011: shrunk the fnv128 hash on NULL encrypted packets from 16 bytes to 12 bytes. Q012: optimize the ack frame format to reduce the size and better handle ranges of nacks, which should make truncated acks virtually impossible. Also adding an explicit flag for truncated acks and moving the ack outside of the connection close frame. Q013: Compressed headers for *all* data streams are serialized into a reserved stream. This ensures serialized handling of headers, independent of stream cancellation notification. Q014: Added WINDOW_UPDATE and BLOCKED frames, no behavioral change. Q015: Removes the accumulated_number_of_lost_packets field from the TCP and inter arrival congestion feedback frames and adds an explicit list of recovered packets to the ack frame. Q016: Breaks out the sent_info field from the ACK frame into a new STOP_WAITING frame. Changed GUID to Connection ID Q017: Adds stream level flow control Q018: Added a PING frame Q019: Adds session/connection level flow control Q020: Allow endpoints to set different stream/session flow control windows Q021: Crypto and headers streams are flow controlled (at stream level) Q023: Ack frames include packet timestamps Q024: HTTP/2-style header compression Q025: HTTP/2-style header keys. Removal of error_details from the RST_STREAM frame. Q026: Token binding, adds expected leaf cert (XLCT) tag to client hello Q027: Adds a nonce to the server hello Q029: Server and client honor QUIC_STREAM_NO_ERROR on early response Q030: Add server side support of certificate transparency. Q031: Adds a SHA256 hash of the serialized client hello messages to crypto proof. Q032: FEC related fields are removed from wire format. Q033: Adds an optional diversification nonce to packet headers, and eliminates the 2 byte and 4 byte connection ID length public flags. Q034: Removes entropy and private flags and changes the ack frame from nack ranges to ack ranges and removes truncated acks. Q035: Allows each endpoint to independently set maximum number of supported incoming streams using the MIDS (“Maximum Incoming Dynamic Streams”) tag instead of the older MSPC (“Maximum Streams Per Connection”) tag. Q036: Adds support for inducing head-of-line blocking between streams via the new FHOL tag in the handshake. Jim Roskind is a hero. … Your article also conflates QUIC with BBR. BBR is a congestion control algorithm. QUIC is a protocol that can use any congestion control algorithm. > -- > Matt Taggart > matt@lackof.org > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel