<font face="arial" size="3"><p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">This is not the place to put functionality specialized to one particular commercial business model, or one application silo.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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?</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">That's the discussion that needs to be had.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">However, cable-company-business-specific end-to-end functionality does NOT belong there.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">It would take an extremely strong argument to coiunter the end-to-end argument here.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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".</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">-----Original Message-----<br />From: "Dave Taht" <dave.taht@gmail.com><br />Sent: Wednesday, March 27, 2019 5:15am<br />To: "Jonathan Morton" <chromatix99@gmail.com>, "ECN-Sane" <ecn-sane@lists.bufferbloat.net><br />Subject: [Ecn-sane] QUIC original design documents<br /><br /></p>
<div id="SafeStyles1553700719">
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">---------- Forwarded message ---------<br />From: Roskind, Jim<br />Date: Thu, Mar 21, 2019 at 9:39 AM<br />Subject: Re: versions of quic<br />To: Dave Taht <dave.taht@gmail.com><br /><br /><br />Every time we made a “breaking change” in the protocol we bumped the<br />version number. Sometimes it was crypto, sometimes frames, sometimes<br />congestion control, etc.<br /><br /><br /><br />I’d have to look back at the codebase to see it precisely, but I would<br />have guessed over 20.<br /><br /><br /><br />As IETF worked, we also regularly rev’ed the protocol to be more<br />similar, if not compatible. It was up to version 34 back in 2016.<br /><br /><br /><br />Looking at the wire spec<br />https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit<br /><br /><br /><br />You can see the long list of recent versions:<br /><br /><br /><br />Q009: added priority as the first 4 bytes on spdy streams.<br />Q010: renumber the various frame types<br />Q011: shrunk the fnv128 hash on NULL encrypted packets from 16 bytes<br />to 12 bytes.<br />Q012: optimize the ack frame format to reduce the size and better<br />handle ranges of nacks, which should make truncated acks virtually<br />impossible. Also adding an explicit flag for truncated acks and moving<br />the ack outside of the connection close frame.<br />Q013: Compressed headers for *all* data streams are serialized into a<br />reserved stream. This ensures serialized handling of headers,<br />independent of stream cancellation notification.<br />Q014: Added WINDOW_UPDATE and BLOCKED frames, no behavioral change.<br />Q015: Removes the accumulated_number_of_lost_packets field from the<br />TCP and inter arrival congestion feedback frames and adds an explicit<br />list of recovered packets to the ack frame.<br />Q016: Breaks out the sent_info field from the ACK frame into a new<br />STOP_WAITING frame.<br />Changed GUID to Connection ID<br />Q017: Adds stream level flow control<br />Q018: Added a PING frame<br />Q019: Adds session/connection level flow control<br />Q020: Allow endpoints to set different stream/session flow control windows<br />Q021: Crypto and headers streams are flow controlled (at stream level)<br />Q023: Ack frames include packet timestamps<br />Q024: HTTP/2-style header compression<br />Q025: HTTP/2-style header keys. Removal of error_details from the<br />RST_STREAM frame.<br />Q026: Token binding, adds expected leaf cert (XLCT) tag to client hello<br />Q027: Adds a nonce to the server hello<br />Q029: Server and client honor QUIC_STREAM_NO_ERROR on early response<br />Q030: Add server side support of certificate transparency.<br />Q031: Adds a SHA256 hash of the serialized client hello messages to<br />crypto proof.<br />Q032: FEC related fields are removed from wire format.<br />Q033: Adds an optional diversification nonce to packet headers, and<br />eliminates the 2 byte and 4 byte connection ID length public flags.<br />Q034: Removes entropy and private flags and changes the ack frame from<br />nack ranges to ack ranges and removes truncated acks.<br />Q035: Allows each endpoint to independently set maximum number of<br />supported incoming streams using the MIDS ("Maximum Incoming Dynamic<br />Streams") tag instead of the older MSPC ("Maximum Streams Per<br />Connection") tag.<br />Q036: Adds support for inducing head-of-line blocking between streams<br />via the new FHOL tag in the handshake.<br /><br /><br /><br /><br /><br />For instance, I know the PING frame was critical to SPDY, and added<br />early on to QUIC, and that appears (above) in version 18 above. I’m<br />pretty sure that was present before discussing with IETF (2013).<br /><br /><br /><br />Reviewing the check-in history would surely nail it down, and I think<br />my talk at IETF about QUIC was in November 2013. The actual Internet<br />Draft for QUIC didn’t come until November 2015, and that may be the<br />date you care about.<br /><br /><br /><br />Why?<br /><br /><br /><br />Jim<br /><br /><br /><br /><br /><br />From: Dave Taht <dave.taht@gmail.com><br />Date: Thursday, March 21, 2019 at 9:20 AM<br />To: "Roskind, Jim" <jroskind@amazon.com><br />Subject: versions of quic<br /><br /><br /><br />How many versions of quic before it hit the ietf?<br /><br /><br /><br />-- <br /><br /><br /><br />Dave Täht<br /><br />CTO, TekLibre, LLC<br /><br />http://www.teklibre.com<br /><br />Tel: 1-831-205-9740<br /><br /><br /><br /><br /><br />-- <br /><br />Dave Täht<br />CTO, TekLibre, LLC<br />http://www.teklibre.com<br />Tel: 1-831-205-9740<br />_______________________________________________<br />Ecn-sane mailing list<br />Ecn-sane@lists.bufferbloat.net<br />https://lists.bufferbloat.net/listinfo/ecn-sane</p>
</div></font>