Draft: draft-ietf-quic-transport

Commentary: We 've been talking about Version Negotiation ( VN ) for a while , as the current design is n't perfect yet . In particular , it is vulnerable to subtle deadlocks and downgrades and requires a full RTT . I have a proposal for the WG that would effectively punt this issue , allowing us to focus on other QUICv1 deliverables until we actually need VN and have deployment experience . I 'm working with the following assumptions : when we 'll have clients and servers supporting both QUICv1 and QUICv2 , we will not be willing to pay a full RTT to negotiate which version to use when we standardize QUICv1 , we will not know what QUICv2 will look like , so can not design compatible VN in v1 and be sure it will work with v2 compatible VN can rely on transport parameters , so it will be possible to standardize it later as an extension to QUICv1 The proposal is to make VN packets a fatal error that effectively kills the first connection , and have them transmit a new connection ID to allow clients to create a new connection that will hit the same server ( or not , based on server preference ) . In terms of wire format , this makes VN more like Retry by making the server send a new connection ID to the client . ( Note that this was mostly inspired by EKR 's proposals . ) 
 My issue with this general approach is that VN is currently part of the invariants . ( Or otherwise framed , VN is the only packet defined by QUIC version zero . ) If we want to support versions which are n't mutually intelligible , it basically has to be version - independent . If you 're only writing in the  document , the PR probably does n't have the necessary contents yet . Further , I think we as a WG need to return to our basic principles in VN and agree on those first -- we have too many designs being tossed around fueled by different assumptions . 
 I agree . I wrote this up so people could reason about the proposal . Maybe it would be worth spending some time on VN in Tokyo ? 
 I 've now reverted the part of this proposal that changed the invariants . It now simply removes VN from v1 . 
 Added a commit which incorporates and feedback 
 Applied latest comments / changes from 
 In QUIC , version upgrade does n't work w/o aditional RTs . Consider the case where the client and server start out supporting version N. Then the client starts supporting N+1 . If it offers N+1 , then it 's going to basically take an extra RT with every server , so it has to offer N , but then when the server upgrades to N+1 , you have to take a RT to get to N+1 . See for one such design 
 We discussed this in NYC and agreed as a WG that this is good in principle , but the PR needed a little more work . 
 This now has a new proposal in . 
 Tokyo proposal : take version downgrade protections out of the draft , make a new draft with an extension that provides that . This would entail merging a fixed - up version of into the docs . Disabling downgrade protection would If that extension makes traction before we complete v1 , then we can merge it back in . 
 Resolution included in . We 'll take this on in a new version ( or extension ) . 
 I think the paragraph starting with " The final version used for a connection ... " is no longer necessary . A few suggestions , and one bit of text that needs to be fixed , otherwise this is good .
Paragraph (version A):
This document defines the core of the QUIC transport protocol.
Accompanying documents describe QUIC's loss detection and congestion
control QUIC-RECOVERY and the use of TLS for key negotiation QUIC-
TLS.
Paragraph (version B):
Endpoints MUST explicitly negotiate an application protocol.  This
avoids situations where there is a disagreement about the protocol
that is in use.
Paragraph (version A):
Endpoints SHOULD send acknowledgments for packets containing CRYPTO
frames with a reduced delay; see Section 5.3.1 of QUIC-RECOVERY.
Paragraph (version A):
The ECN section should only be parsed when the ACK frame type is
0x03.  The ECN section consists of 3 ECN counts as shown below.