* Re: [Ecn-sane] QUIC original design documents
2019-03-27 9:15 ` [Ecn-sane] QUIC original design documents Dave Taht
@ 2019-03-27 15:39 ` David P. Reed
0 siblings, 0 replies; 2+ messages in thread
From: David P. Reed @ 2019-03-27 15:39 UTC (permalink / raw)
To: Dave Taht; +Cc: Jonathan Morton, ECN-Sane
[-- Attachment #1: Type: text/plain, Size: 5774 bytes --]
Worth keeping in mind that QUIC didn't propose a change to the rock-bottom foundation of the entire Internet - the IP datagram and its core functions across all technologies.
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 inside and outside IETF.
This is not the place to put functionality specialized to one particular commercial business model, or one application silo.
That's putting a function into the Internet, and an end-to-end argument applies. 1) does the function actually achieve a goal for all of the Internet? 2) can that function be accomplished without putting this feature in the core common Internet?
That's the discussion that needs to be had.
I believe that congestion 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.
However, cable-company-business-specific end-to-end functionality does NOT belong there.
It would take an extremely strong argument to coiunter the end-to-end argument here.
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".
-----Original Message-----
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Wednesday, March 27, 2019 5:15am
To: "Jonathan Morton" <chromatix99@gmail.com>, "ECN-Sane" <ecn-sane@lists.bufferbloat.net>
Subject: [Ecn-sane] QUIC original design documents
---------- Forwarded message ---------
From: Roskind, Jim
Date: Thu, Mar 21, 2019 at 9:39 AM
Subject: Re: versions of quic
To: Dave Taht <dave.taht@gmail.com>
Every time we made a “breaking change” in the protocol we bumped the
version number. Sometimes it was crypto, sometimes frames, sometimes
congestion control, etc.
I’d have to look back at the codebase to see it precisely, but I would
have guessed over 20.
As IETF worked, we also regularly rev’ed the protocol to be more
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: 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.
For instance, I know the PING frame was critical to SPDY, and added
early on to QUIC, and that appears (above) in version 18 above. I’m
pretty sure that was present before discussing with IETF (2013).
Reviewing the check-in history would surely nail it down, and I think
my talk at IETF about QUIC was in November 2013. The actual Internet
Draft for QUIC didn’t come until November 2015, and that may be the
date you care about.
Why?
Jim
From: Dave Taht <dave.taht@gmail.com>
Date: Thursday, March 21, 2019 at 9:20 AM
To: "Roskind, Jim" <jroskind@amazon.com>
Subject: versions of quic
How many versions of quic before it hit the ietf?
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
_______________________________________________
Ecn-sane mailing list
Ecn-sane@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane
[-- Attachment #2: Type: text/html, Size: 8476 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread