From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp72.iad3a.emailsrvr.com (smtp72.iad3a.emailsrvr.com [173.203.187.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9544C3CB37 for ; Sat, 23 Mar 2019 14:11:33 -0400 (EDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 643A1425C; Sat, 23 Mar 2019 14:11:33 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5CDD742BE; Sat, 23 Mar 2019 14:11:33 -0400 (EDT) Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 20D8A425C; Sat, 23 Mar 2019 14:11:33 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sat, 23 Mar 2019 14:11:33 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app11.wa-webapps.iad3a (Postfix) with ESMTP id 0A63DA0044; Sat, 23 Mar 2019 14:11:33 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sat, 23 Mar 2019 14:11:33 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Sat, 23 Mar 2019 14:11:33 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "Matt Taggart" , "cerowrt-devel" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190323141133000000_28646" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <8bff80d6-9b5f-6963-1bc5-45bfab636008@lackof.org> Message-ID: <1553364693.03986017@apps.rackspace.com> X-Mailer: webmail/16.2.2-RC Subject: Re: [Cerowrt-devel] =?utf-8?q?Will_transport_innovation_collapse_the_?= =?utf-8?q?Internet=3F?= X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 18:11:33 -0000 ------=_20190323141133000000_28646 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ADave -=0A =0AI tend to agree with Christian's thesis, despite the flaws = in his "history".=0A =0AHTTP/3 does NOT specify a congestion control algori= thm, and in fact seems to encourage experimentation with wacky concepts. T= hat's a terrible approach to standardization.=0A =0ARoskind 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 hu= ge scale* that Google pursues has not been backed up by any serious experim= entation to understand its effects. In fact, that approach, non-scientific = in the extreme, has become typical of Google's PR-driven and deceptive acti= ons. (See the extremely flawed claims about its "AI" flu-prediction experim= ent being "better than any public health department" and its flacking of a = Jeff Dean Nature publication that was reframed by Google PR and Jeff himsel= f 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 exp= erimental results. The Flu test has never been reproduced since, suggesting= it was (un?)intentionally cherry-picked to show off)=0A =0ANow whether Ros= kind is typical of Google's Aim, Fire, Ready approach to science and engine= ering or not, it seems you are calling him a "hero" because of that cowboy = approach.=0A =0AEven though I find the IETF of today full of non-science an= d corrupt influence, the idea that Roskind is "better" than that, I can't s= tomach the idea that QUIC or HTTP/3 are "good" merely because they are diff= erent and the product of a renegade.=0A =0A =0A-----Original Message-----= =0AFrom: "Dave Taht" =0ASent: Saturday, March 23, 2019= 2:15am=0ATo: "Matt Taggart" =0ACc: "cerowrt-devel" =0ASubject: Re: [Cerowrt-devel] Will transpo= rt innovation collapse the Internet?=0A=0A=0A=0AOn Sat, Mar 23, 2019 at 1:3= 1 AM Matt Taggart wrote:=0A>=0A> This is from Jan 12th bu= t I hadn't seen it yet.=0A>=0A> https://huitema.wordpress.com/2019/01/12/wi= ll-transport-innovation-collapse-the-internet/=0A=0AI am awaiting moderatio= n on this comment:=0A=0AWhile I agree with your thesis, about the problem!= =0A=0AI am very bothered by your descriptions of the timelines and who were= =0Ainvolved. Other processes are required long before something hits the=0A= ietf and recent attempts to file the serial numbers off in favor of=0Acorpo= rate =E2=80=9Cinnovation=E2=80=9D rather bug me, so:=0A=0A1) =E2=80=9CMore = recent algorithms were developed in the IETF AQM Working=0AGroup to address= the =E2=80=9Cbuffer bloat=E2=80=9D problem, such as FQ-CODEL or PIE.=0A=E2= =80=9D=0A=0Afq_codel sprang from an outside the ietf effort (bufferbloat.ne= t)=0Afounded by myself and jim gettys in 2011. In may of 2012 (after many= =0Aother innovations in linux such as BQL (which made FQ and AQM=0Atechnolo= gy possible), multiple other fixes in the stack, the=0Apublication of Van J= acobson=E2=80=99s and Kathie nichols=E2=80=99s paper on codel=0A(which we t= urned from ns2 to linux in a week, and arrived in linux=0Amainline the week= later)=E2=80=A6 and two weeks later .- fq_codel incorporated=0Athe best of= all our research. It took 6 hours to write, and while=0Athere have been ma= ny minor tweaks along the way, it then took 6 years=0Ato standardize in the= IETF while achieving a near total deployment in=0Alinux today, and is now = in freebsd.=0A=0AThe ietf AQM working group was founded only because of and= after VJ=0Aand Kathie=E2=80=99s breakthrough AQM design. It was a hard fig= ht to even get=0Afair queuing as part of the charter.=0A=0A2) QUIC=E2=80=99= s real history started with a renegade engineer (Jim Roskind,=0Afather of Q= UIC) that gathered a small team inside google to re-examine=0Atcp in the co= ntext of web traffic around 2011 =E2=80=93 3 years before you=0Aclaim it ha= ppened. See the commit logs. They re-evaluated 30 years of=0Adiscarded tcp = ideas, and retried them, much in the manner of how=0Aedison would try 3000 = ideas to get one. Month in month out, they built=0Arelease after release, w= rote the code, deployed it, made changes to=0Athe code and protocol on a mo= nthly basis. They faced enormous barriers=0Aby folk that thought we should = just fix tcp, or laughed at each new=0Aidea and said that couldn=E2=80=99t = (or shouldn=E2=80=99t) be done.=0A=0AThey just went ahead and did it.=0A=0A= Every time they made a =E2=80=9Cbreaking change=E2=80=9D in the protocol th= ey bumped=0Athe version number. Sometimes it was crypto, sometimes frames,= =0Asometimes congestion control, etc.=0A=0AIt went through *20* *deployed* = revisions before it made the ietf.=0A=0ALooking at the wire spec=0Ahttps://= docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edi= t=0A=0AYou can see the long list of recent versions:=0A=0AQ009: added prior= ity as the first 4 bytes on spdy streams.=0AQ010: renumber the various fram= e types=0AQ011: shrunk the fnv128 hash on NULL encrypted packets from 16 by= tes=0Ato 12 bytes.=0AQ012: optimize the ack frame format to reduce the size= and better=0Ahandle ranges of nacks, which should make truncated acks virt= ually=0Aimpossible. Also adding an explicit flag for truncated acks and mov= ing=0Athe ack outside of the connection close frame.=0AQ013: Compressed hea= ders for *all* data streams are serialized into a=0Areserved stream. This e= nsures serialized handling of headers,=0Aindependent of stream cancellation= notification.=0AQ014: Added WINDOW_UPDATE and BLOCKED frames, no behaviora= l change.=0AQ015: Removes the accumulated_number_of_lost_packets field from= the=0ATCP and inter arrival congestion feedback frames and adds an explici= t=0Alist of recovered packets to the ack frame.=0AQ016: Breaks out the sent= _info field from the ACK frame into a new=0ASTOP_WAITING frame.=0AChanged G= UID to Connection ID=0AQ017: Adds stream level flow control=0AQ018: Added a= PING frame=0AQ019: Adds session/connection level flow control=0AQ020: Allo= w endpoints to set different stream/session flow control windows=0AQ021: Cr= ypto and headers streams are flow controlled (at stream level)=0AQ023: Ack = frames include packet timestamps=0AQ024: HTTP/2-style header compression=0A= Q025: HTTP/2-style header keys. Removal of error_details from the=0ARST_STR= EAM frame.=0AQ026: Token binding, adds expected leaf cert (XLCT) tag to cli= ent hello=0AQ027: Adds a nonce to the server hello=0AQ029: Server and clien= t honor QUIC_STREAM_NO_ERROR on early response=0AQ030: Add server side supp= ort of certificate transparency.=0AQ031: Adds a SHA256 hash of the serializ= ed client hello messages to=0Acrypto proof.=0AQ032: FEC related fields are = removed from wire format.=0AQ033: Adds an optional diversification nonce to= packet headers, and=0Aeliminates the 2 byte and 4 byte connection ID lengt= h public flags.=0AQ034: Removes entropy and private flags and changes the a= ck frame from=0Anack ranges to ack ranges and removes truncated acks.=0AQ03= 5: Allows each endpoint to independently set maximum number of=0Asupported = incoming streams using the MIDS (=E2=80=9CMaximum Incoming Dynamic=0AStream= s=E2=80=9D) tag instead of the older MSPC (=E2=80=9CMaximum Streams Per=0AC= onnection=E2=80=9D) tag.=0AQ036: Adds support for inducing head-of-line blo= cking between streams=0Avia the new FHOL tag in the handshake.=0A=0AJim Ros= kind is a hero.=0A=0A=E2=80=A6=0A=0AYour article also conflates QUIC with B= BR. BBR is a congestion control=0Aalgorithm. QUIC is a protocol that can us= e any congestion control=0Aalgorithm.=0A=0A> --=0A> Matt Taggart=0A> matt@l= ackof.org=0A> _______________________________________________=0A> Cerowrt-d= evel mailing list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://lists= .bufferbloat.net/listinfo/cerowrt-devel=0A=0A=0A=0A-- =0A=0ADave T=C3=A4ht= =0ACTO, TekLibre, LLC=0Ahttp://www.teklibre.com=0ATel: 1-831-205-9740=0A___= ____________________________________________=0ACerowrt-devel mailing list= =0ACerowrt-devel@lists.bufferbloat.net=0Ahttps://lists.bufferbloat.net/list= info/cerowrt-devel ------=_20190323141133000000_28646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dave -

=0A

 

=0A

I tend to agree with Christi= an's thesis, despite the flaws in his "history".

=0A

 

=0A

HTTP/3 does NOT specify a congestion con= trol algorithm, and in fact seems to encourage experimentation with wacky c= oncepts.  That's a terrible approach to standardization.

=0A

 

=0A

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 h= uge scale* that Google pursues has not been backed up by any serious experi= mentation to understand its effects. In fact, that approach, non-scientific= in the extreme, has become typical of Google's PR-driven and deceptive act= ions. (See the extremely flawed claims about its "AI" flu-prediction experi= ment being "better than any public health department" and its flacking of a= Jeff Dean Nature publication that was reframed by Google PR and Jeff himse= lf 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 actu= al experimental results. The Flu test has never been reproduced since, sugg= esting it was (un?)intentionally cherry-picked to show off)

=0A

 

=0A

Now whether Roskind is typic= al 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.

= =0A

 

=0A

Even though I fin= d the IETF of today full of non-science and corrupt influence, the idea tha= t 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 renega= de.

=0A

 

=0A

 

= =0A

-----Original Message-----
From: "Dave Taht" &= lt;dave.taht@gmail.com>
Sent: Saturday, March 23, 2019 2:15am
= To: "Matt Taggart" <matt@lackof.org>
Cc: "cerowrt-devel" <cer= owrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Will= transport innovation collapse the Internet?

=0A
=0A

On Sat, Mar 23, 2019 at 1:31 A= M Matt Taggart <matt@lackof.org> wrote:
>
> This is f= rom 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 agre= e with your thesis, about the problem!

I am very bothered by you= r 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 =E2=80=9Cinnovati= on=E2=80=9D rather bug me, so:

1) =E2=80=9CMore recent algorithm= s were developed in the IETF AQM Working
Group to address the =E2=80= =9Cbuffer bloat=E2=80=9D problem, such as FQ-CODEL or PIE.
=E2=80=9D
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<= br />other innovations in linux such as BQL (which made FQ and AQM
tec= hnology possible), multiple other fixes in the stack, the
publication = of Van Jacobson=E2=80=99s and Kathie nichols=E2=80=99s paper on codel
= (which we turned from ns2 to linux in a week, and arrived in linux
mai= nline the week later)=E2=80=A6 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=E2=80=99s breakth= rough AQM design. It was a hard fight to even get
fair queuing as part= of the charter.

2) QUIC=E2=80=99s real history started with a r= enegade engineer (Jim Roskind,
father of QUIC) that gathered a small t= eam inside google to re-examine
tcp in the context of web traffic arou= nd 2011 =E2=80=93 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 basi= s. They faced enormous barriers
by folk that thought we should just fi= x tcp, or laughed at each new
idea and said that couldn=E2=80=99t (or = shouldn=E2=80=99t) be done.

They just went ahead and did it.

Every time they made a =E2=80=9Cbreaking change=E2=80=9D in the pro= tocol they bumped
the version number. Sometimes it was crypto, sometim= es frames,
sometimes congestion control, etc.

It went throu= gh *20* *deployed* revisions before it made the ietf.

Looking at= the wire spec
https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp= 9NsGjC1CHetAXV8I0fQe-B_U/edit

You can see the long list of recen= t versions:

Q009: added priority as the first 4 bytes on spdy st= reams.
Q010: renumber the various frame types
Q011: shrunk the fn= v128 hash on NULL encrypted packets from 16 bytes
to 12 bytes.
Q0= 12: optimize the ack frame format to reduce the size and better
handle= ranges of nacks, which should make truncated acks virtually
impossibl= e. Also adding an explicit flag for truncated acks and moving
the ack = outside of the connection close frame.
Q013: Compressed headers for *a= ll* data streams are serialized into a
reserved stream. This ensures s= erialized handling of headers,
independent of stream cancellation noti= fication.
Q014: Added WINDOW_UPDATE and BLOCKED frames, no behavioral = change.
Q015: Removes the accumulated_number_of_lost_packets field fro= m the
TCP and inter arrival congestion feedback frames and adds an exp= licit
list of recovered packets to the ack frame.
Q016: Breaks ou= t the sent_info field from the ACK frame into a new
STOP_WAITING frame= .
Changed GUID to Connection ID
Q017: Adds stream level flow cont= rol
Q018: Added a PING frame
Q019: Adds session/connection level = flow control
Q020: Allow endpoints to set different stream/session flo= w control windows
Q021: Crypto and headers streams are flow controlled= (at stream level)
Q023: Ack frames include packet timestamps
Q02= 4: HTTP/2-style header compression
Q025: HTTP/2-style header keys. Rem= oval of error_details from the
RST_STREAM frame.
Q026: Token bind= ing, adds expected leaf cert (XLCT) tag to client hello
Q027: Adds a n= once to the server hello
Q029: Server and client honor QUIC_STREAM_NO_= ERROR on early response
Q030: Add server side support of certificate t= ransparency.
Q031: Adds a SHA256 hash of the serialized client hello m= essages to
crypto proof.
Q032: FEC related fields are removed fro= m wire format.
Q033: Adds an optional diversification nonce to packet = headers, and
eliminates the 2 byte and 4 byte connection ID length pub= lic 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
sup= ported incoming streams using the MIDS (=E2=80=9CMaximum Incoming DynamicStreams=E2=80=9D) tag instead of the older MSPC (=E2=80=9CMaximum Strea= ms Per
Connection=E2=80=9D) tag.
Q036: Adds support for inducing = head-of-line blocking between streams
via the new FHOL tag in the hand= shake.

Jim Roskind is a hero.

=E2=80=A6

Yo= ur article also conflates QUIC with BBR. BBR is a congestion control
a= lgorithm. QUIC is a protocol that can use any congestion control
algor= ithm.

> --
> Matt Taggart
> matt@lackof.org> _______________________________________________
> Cerowrt-= devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> = https://lists.bufferbloat.net/listinfo/cerowrt-devel



--

Dave T=C3=A4ht
CTO, TekLibre, LLC
http://www.tekl= ibre.com
Tel: 1-831-205-9740
____________________________________= ___________
Cerowrt-devel mailing list
Cerowrt-devel@lists.buffer= bloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

=0A<= /div> ------=_20190323141133000000_28646--