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" Sent: Wednesday, March 27, 2019 5:15am To: "Jonathan Morton" , "ECN-Sane" 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 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 Date: Thursday, March 21, 2019 at 9:20 AM To: "Roskind, Jim" 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