[Cerowrt-devel] Will transport innovation collapse the Internet?

Sat Mar 23 14:11:33 EDT 2019

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" <dave.taht at gmail.com>
Sent: Saturday, March 23, 2019 2:15am
To: "Matt Taggart" <matt at lackof.org>
Cc: "cerowrt-devel" <cerowrt-devel at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Will transport innovation collapse the Internet?

On Sat, Mar 23, 2019 at 1:31 AM Matt Taggart <matt at lackof.org> 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 at lackof.org
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at 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 at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20190323/579662e3/attachment.html>