From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp92.iad3a.emailsrvr.com (smtp92.iad3a.emailsrvr.com [173.203.187.92]) (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 8560A3CB36 for ; Wed, 27 Mar 2019 11:39:32 -0400 (EDT) Received: from smtp36.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5256A42B4; Wed, 27 Mar 2019 11:39:32 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp36.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4D1B6556A; Wed, 27 Mar 2019 11:39:32 -0400 (EDT) Received: from app47.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2454D42B4; Wed, 27 Mar 2019 11:39:32 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app47.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Wed, 27 Mar 2019 11:39:32 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app47.wa-webapps.iad3a (Postfix) with ESMTP id 0FB7DE0045; Wed, 27 Mar 2019 11:39:32 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 27 Mar 2019 11:39:32 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Wed, 27 Mar 2019 11:39:32 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "Jonathan Morton" , "ECN-Sane" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190327113932000000_83270" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1553701172.062232551@apps.rackspace.com> X-Mailer: webmail/16.2.2-RC Subject: Re: [Ecn-sane] QUIC original design documents X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 15:39:32 -0000 ------=_20190327113932000000_83270 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AWorth keeping in mind that QUIC didn't propose a change to the rock-bott= om foundation of the entire Internet - the IP datagram and its core functio= ns across all technologies.=0A =0AChanges to IPv4 or IPv6 headers and the s= emantics of those headers in router behavior are changes to the core invari= ants of the entire Internet world, both inside and outside IETF.=0A =0AThis= is not the place to put functionality specialized to one particular commer= cial business model, or one application silo.=0A =0AThat's putting a functi= on into the Internet, and an end-to-end argument applies. 1) does the funct= ion actually achieve a goal for all of the Internet? 2) can that function = be accomplished without putting this feature in the core common Internet?= =0A =0AThat's the discussion that needs to be had.=0A =0AI believe that con= gestion management *is* an essential function for the entire Internet, but = only so much of that function that is common to all current and conceivable= future uses of the Internet.=0A =0AHowever, cable-company-business-specifi= c end-to-end functionality does NOT belong there.=0AIt would take an extrem= ely strong argument to coiunter the end-to-end argument here.=0A =0AIt's NO= T sufficient, in my view, to say "oh well, they have a lot of votes in the = management of IETF, so let them have it".=0A =0A =0A-----Original Message--= ---=0AFrom: "Dave Taht" =0ASent: Wednesday, March 27, = 2019 5:15am=0ATo: "Jonathan Morton" , "ECN-Sane" =0ASubject: [Ecn-sane] QUIC original design do= cuments=0A=0A=0A=0A---------- Forwarded message ---------=0AFrom: Roskind, = Jim=0ADate: Thu, Mar 21, 2019 at 9:39 AM=0ASubject: Re: versions of quic=0A= To: Dave Taht =0A=0A=0AEvery time we made a =E2=80=9Cb= reaking change=E2=80=9D in the protocol we bumped the=0Aversion number. Som= etimes it was crypto, sometimes frames, sometimes=0Acongestion control, etc= .=0A=0A=0A=0AI=E2=80=99d have to look back at the codebase to see it precis= ely, but I would=0Ahave guessed over 20.=0A=0A=0A=0AAs IETF worked, we also= regularly rev=E2=80=99ed the protocol to be more=0Asimilar, if not compati= ble. It was up to version 34 back in 2016.=0A=0A=0A=0ALooking at the wire s= pec=0Ahttps://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV= 8I0fQe-B_U/edit=0A=0A=0A=0AYou can see the long list of recent versions:=0A= =0A=0A=0AQ009: added priority as the first 4 bytes on spdy streams.=0AQ010:= renumber the various frame types=0AQ011: shrunk the fnv128 hash on NULL en= crypted packets from 16 bytes=0Ato 12 bytes.=0AQ012: optimize the ack frame= format to reduce the size and better=0Ahandle ranges of nacks, which shoul= d make truncated acks virtually=0Aimpossible. Also adding an explicit flag = for truncated acks and moving=0Athe ack outside of the connection close fra= me.=0AQ013: Compressed headers for *all* data streams are serialized into a= =0Areserved stream. This ensures serialized handling of headers,=0Aindepend= ent of stream cancellation notification.=0AQ014: Added WINDOW_UPDATE and BL= OCKED frames, no behavioral change.=0AQ015: Removes the accumulated_number_= of_lost_packets field from the=0ATCP and inter arrival congestion feedback = frames and adds an explicit=0Alist of recovered packets to the ack frame.= =0AQ016: Breaks out the sent_info field from the ACK frame into a new=0ASTO= P_WAITING frame.=0AChanged GUID to Connection ID=0AQ017: Adds stream level = flow control=0AQ018: Added a PING frame=0AQ019: Adds session/connection lev= el flow control=0AQ020: Allow endpoints to set different stream/session flo= w control windows=0AQ021: Crypto and headers streams are flow controlled (a= t stream level)=0AQ023: Ack frames include packet timestamps=0AQ024: HTTP/2= -style header compression=0AQ025: HTTP/2-style header keys. Removal of erro= r_details from the=0ARST_STREAM frame.=0AQ026: Token binding, adds expected= leaf cert (XLCT) tag to client hello=0AQ027: Adds a nonce to the server he= llo=0AQ029: Server and client honor QUIC_STREAM_NO_ERROR on early response= =0AQ030: Add server side support of certificate transparency.=0AQ031: Adds = a SHA256 hash of the serialized client hello messages to=0Acrypto proof.=0A= Q032: FEC related fields are removed from wire format.=0AQ033: Adds an opti= onal diversification nonce to packet headers, and=0Aeliminates the 2 byte a= nd 4 byte connection ID length public flags.=0AQ034: Removes entropy and pr= ivate flags and changes the ack frame from=0Anack ranges to ack ranges and = removes truncated acks.=0AQ035: Allows each endpoint to independently set m= aximum number of=0Asupported incoming streams using the MIDS ("Maximum Inco= ming Dynamic=0AStreams") tag instead of the older MSPC ("Maximum Streams Pe= r=0AConnection") tag.=0AQ036: Adds support for inducing head-of-line blocki= ng between streams=0Avia the new FHOL tag in the handshake.=0A=0A=0A=0A=0A= =0AFor instance, I know the PING frame was critical to SPDY, and added=0Aea= rly on to QUIC, and that appears (above) in version 18 above. I=E2=80=99m= =0Apretty sure that was present before discussing with IETF (2013).=0A=0A= =0A=0AReviewing the check-in history would surely nail it down, and I think= =0Amy talk at IETF about QUIC was in November 2013. The actual Internet=0AD= raft for QUIC didn=E2=80=99t come until November 2015, and that may be the= =0Adate you care about.=0A=0A=0A=0AWhy?=0A=0A=0A=0AJim=0A=0A=0A=0A=0A=0AFro= m: Dave Taht =0ADate: Thursday, March 21, 2019 at 9:20= AM=0ATo: "Roskind, Jim" =0ASubject: versions of quic= =0A=0A=0A=0AHow many versions of quic before it hit the ietf?=0A=0A=0A=0A--= =0A=0A=0A=0ADave T=C3=A4ht=0A=0ACTO, TekLibre, LLC=0A=0Ahttp://www.teklibr= e.com=0A=0ATel: 1-831-205-9740=0A=0A=0A=0A=0A=0A-- =0A=0ADave T=C3=A4ht=0AC= TO, TekLibre, LLC=0Ahttp://www.teklibre.com=0ATel: 1-831-205-9740=0A_______= ________________________________________=0AEcn-sane mailing list=0AEcn-sane= @lists.bufferbloat.net=0Ahttps://lists.bufferbloat.net/listinfo/ecn-sane ------=_20190327113932000000_83270 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Worth keeping in mind = that QUIC didn't propose a change to the rock-bottom foundation of the enti= re Internet - the IP datagram and its core functions across all technologie= s.

=0A

 

=0A

Changes to = IPv4 or IPv6 headers and the semantics of those headers in router behavior = are changes to the core invariants of the entire Internet world, both insid= e and outside IETF.

=0A

 

=0A

This is not the place to put functionality specialized to one particu= lar commercial business model, or one application silo.

=0A

 

=0A

That's putting a function into th= e Internet, and an end-to-end argument applies. 1) does the function actual= ly achieve a goal for all of the Internet?  2) can that function be ac= complished without putting this feature in the core common Internet?

=0A=

 

=0A

That's the discussio= n that needs to be had.

=0A

 

=0A

I believe that congestion management *is* an essential function f= or the entire Internet, but only so much of that function that is common to= all current and conceivable future uses of the Internet.

=0A

 

=0A

However, cable-company-business= -specific end-to-end functionality does NOT belong there.

=0A

It would take an extremely strong argument to coiunter the end-to= -end argument here.

=0A

 

=0A

It's NOT sufficient, in my view, to say "oh well, they have a lot of = votes in the management of IETF, so let them have it".

=0A

 

=0A

 

=0A

= -----Original Message-----
From: "Dave Taht" <dave.taht@gmail.com&g= t;
Sent: Wednesday, March 27, 2019 5:15am
To: "Jonathan Morton" &= lt;chromatix99@gmail.com>, "ECN-Sane" <ecn-sane@lists.bufferbloat.net= >
Subject: [Ecn-sane] QUIC original design documents

=0A

=0A

---------- For= warded message ---------
From: Roskind, Jim
Date: Thu, Mar 21, 20= 19 at 9:39 AM
Subject: Re: versions of quic
To: Dave Taht <dav= e.taht@gmail.com>


Every time we made a =E2=80=9Cbreakin= g change=E2=80=9D in the protocol we bumped the
version number. Someti= mes it was crypto, sometimes frames, sometimes
congestion control, etc= .



I=E2=80=99d have to look back at the codebase to s= ee it precisely, but I would
have guessed over 20.


As IETF worked, we also regularly rev=E2=80=99ed the protocol to be mor= e
similar, if not compatible. It was up to version 34 back in 2016.


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: re= number the various frame types
Q011: shrunk the fnv128 hash on NULL en= crypted packets from 16 bytes
to 12 bytes.
Q012: optimize the ack= frame format to reduce the size and better
handle ranges of nacks, wh= ich should make truncated acks virtually
impossible. Also adding an ex= plicit flag for truncated acks and moving
the ack outside of the conne= ction close frame.
Q013: Compressed headers for *all* data streams are= serialized into a
reserved stream. This ensures serialized handling o= f headers,
independent of stream cancellation notification.
Q014:= Added WINDOW_UPDATE and BLOCKED frames, no behavioral change.
Q015: R= emoves the accumulated_number_of_lost_packets field from the
TCP and i= nter arrival congestion feedback frames and adds an explicit
list of r= ecovered packets to the ack frame.
Q016: Breaks out the sent_info fiel= d 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
Q0= 20: Allow endpoints to set different stream/session flow control windowsQ021: Crypto and headers streams are flow controlled (at stream level)Q023: Ack frames include packet timestamps
Q024: HTTP/2-style head= er compression
Q025: HTTP/2-style header keys. Removal of error_detail= s from the
RST_STREAM frame.
Q026: Token binding, adds expected l= eaf cert (XLCT) tag to client hello
Q027: Adds a nonce to the server h= ello
Q029: Server and client honor QUIC_STREAM_NO_ERROR on early respo= nse
Q030: Add server side support of certificate transparency.
Q0= 31: Adds a SHA256 hash of the serialized client hello messages to
cryp= to proof.
Q032: FEC related fields are removed from wire format.
= Q033: Adds an optional diversification nonce to packet headers, and
el= iminates the 2 byte and 4 byte connection ID length public flags.
Q034= : Removes entropy and private flags and changes the ack frame from
nac= k ranges to ack ranges and removes truncated acks.
Q035: Allows each e= ndpoint to independently set maximum number of
supported incoming stre= ams using the MIDS ("Maximum Incoming Dynamic
Streams") tag instead of= the older MSPC ("Maximum Streams Per
Connection") tag.
Q036: Add= s support for inducing head-of-line blocking between streams
via the n= ew FHOL tag in the handshake.





For instan= ce, I know the PING frame was critical to SPDY, and added
early on to = QUIC, and that appears (above) in version 18 above. I=E2=80=99m
pretty= sure that was present before discussing with IETF (2013).



Reviewing the check-in history would surely nail it down, and I thin= k
my talk at IETF about QUIC was in November 2013. The actual Internet=
Draft for QUIC didn=E2=80=99t come until November 2015, and that may = be the
date you care about.



Why?


Jim





From: Dave Taht <dave.ta= ht@gmail.com>
Date: Thursday, March 21, 2019 at 9:20 AM
To: "R= oskind, Jim" <jroskind@amazon.com>
Subject: versions of quic



How many versions of quic before it hit the ietf?
=


--



Dave T=C3=A4ht

CTO,= TekLibre, LLC

http://www.teklibre.com

Tel: 1-831-205= -9740





--

Dave T=C3=A4ht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740_______________________________________________
Ecn-sane mailing l= ist
Ecn-sane@lists.bufferbloat.net
https://lists.bufferbloat.net/= listinfo/ecn-sane

=0A
 ------=_20190327113932000000_83270--