Draft: draft-ietf-quic-transport

Commentary: This must be ignored , and should be set to 1 . 
 I 've had conversations with a number of people who are interested in identifying QUIC using the QUIC bit . Only one packet does not have the QUIC bit always set to 1 currently , and that 's version negotiation . Given we have no use for the extra bits in VN , I 'm inclined to specify implementations must set it to 1 . If we think we 'll one day want to claw back use of the QUIC bit and allow it to be 0 , then this is a poor plan , but I do n't think that will end up being practical on the public internet . A related question is whether we want to put the QUIC bit in the invariants . It 's clearly not technically necessary , but it would recognize the ossification I anticipate . 
 I have a different proposal : allow those that do n't depend on this bit to toggle it . That is , if you are certain that you do n't need this bit set to 1 , set it to 0 occasionally . 
 That could work . It comes down to whether the WG thinks the QUIC bit is a bug or feature , as well as whether enough people will toggle it that it wo n't be ossified anyway . 
 I like how you frame the issue . I think that the QUIC bit should either be defined in the invariants draft , or be greased to avoid it getting ossified . And my weak preference goes to greasing the bit , so that we could have maximum flexibility in the future versions of QUIC . 
 I 'm a bit concerned that relying on greasing is wishful thinking , here and elsewhere . Mostly this has been bypassed with header protection . All it takes is one dominant implementation to be lazy about it . Think older IE browsers vs. standards . 
 The reason the second bit was fixed to 1 in QUICv1 was to allow multiplexing with other protocols . Greasing it would defeat that and would cause problems with some Google servers that use it for demultiplexing . Given that these demultiplexing concerns are unlikely to go away , it does make sense to add it to the invariants . 
 I suspect VN packets will be pretty rare in the internet before we roll out v2 , so we are in real danger of 50 % of these packets failing because they have QUIC set to zero . The most straightforward solution is to just codify the ossification that will happen anyway . is this multiplexing mostly an issue for Initial Packets ? Because the way to free up the QUIC bit could be to grease it in the Short Header . No one will implement something that drops 50 % of 1RTT packets . 
 good point - most of the use - cases we have today are servers doing the demultiplexing , and VN is currently only server - to - client . I 'm less worried about VN and more about the Internet ossifying " QUIC = = the second bit is 1 " without it being in the invariants . Greasing the second bit in client - to - server short headers would make it harder to demultiplex on the server without keeping track of all the issued connection IDs , and I do n't think we want to make the server demultiplexer stateful . 
 I agree that the long header packets sent by the client need to have the QUIC bit set . I also agree that there 's less need to have the bit set in the long header packets sent by the server , though I think it 's possible to argue that we should not have different requirements based on the direction of the packets , because QUIC does not have a distinguish a client address tuple and a server address tuple ( i.e. an endpoint can use a one address tuple for accepting connections and also for initiating connections as a client ) . For short header packets , I think we agree that the bit is not required . Then the question is , assuming that we decide to kill the bit , should we grease it , or rather , change it to a reserve bit ? I suggest the latter because changing the definition to " reserved " and covering the bit using header protection is the strongest way of preserving the freedom to use the bit in future versions of QUIC . It can also be considered as a simplification , because there would be not need to " randomize " the bit for greasing ; endpoints can rely on the header protection to flip the bits . FWIW , current definition of the short header first byte is : . This would change to if we are going to change the QUIC bit to a reserved bit . 
 To me , it 's clear that we should either ( 1 ) add it to the invariants or ( 2 ) bring it under header protection for server - generated packets only . ( 2 ) is somewhat inelegant , but we get to keep using the bits . Are there any privacy implications to there being a " client bit " ? 
 I would oppose to such a design , because that disables a reverse proxy from using a single port for accepting connections and also for initiating connections , assuming that either the proxy or a middlebox in front of the proxy relies on the QUIC bit to route the packets . Greasing would be fine , because it 's not something to be required for every endpoint to implement . The bit would be a good indicator to police P2P traffic for ISPs ... 
 I ’m in favor of always setting the bit , and if not , symmetric header protection . There are significant symmetric use cases , including NAT - punching p2p . Making it 1 permanently lets QUIC co - exist , eg on a single client 443 port , and it avoids a lot of potential problems over a bit that is not needed . 
 IIRC , the bit was a result of us wanting to demux with various other protocols , and as such , the entire purpose of the bit is to allow identification of QUIC . This may not be a feature we like , but it is a feature . I do n't think we should be talking about the bit , but about co - existence with the other protocols . We discussed this , made a presentation about it ( in Montreal , I think ) , and we agreed to co - exist . While it can be seen as a natural consequence of setting the QUIC bit , I think the question we want to ask is whether we ought to make this co - existence an invariant . If so , what is the minimal set of packets that need to be demux - able with these other protocols . ( We 've been over this before , but I do n't think we discussed whether it was adequate to demux only for the long header . ) 
 FWIW most of the discussion happen in New York . See 
 thanks for jogging my memory . It seems that we did n't agree on something specific there . 
 Discussed in Prague ; proposal to encourage senders in v1 to set to ; retain requirement in invariants to ignore . 
 I realize there exist a need to clarify the text regarding ECN on the relation between IP packets and QUIC packets . As QUIC tracks QUIC packets , and not IP packets , this relation when coaleing occurs needs to be clarified . What I think is needed are : In Section 6.8 : Using Explicit Congestion Notification should be updated to be explicit about when it talks about IP packet and when about QUIC packets . State explicitly that for coalesed QUIC packets , the IP packet 's ECN field value is reported for each QUIC packet . 
 Sounds good . I 'm sure that we 'd appreciate getting a PR for this . 
 So how do we deal with the different packet number spaces here . I see two options : Either say that we totally ignore Initial packets in the perspective of ECN handling . Which basically delays the ECN verification until one sees ACKs for the 0- or 1 - RTT packets . Or one requires one set of counters per packet number space . What are peoples preference here ? 
 I 'm thinking that you count separately , in the interests of keeping ACK accounting separate ( and consistent ) . But no special handling , or disabling ECN for different phases . You can still use Initial / Handshake to verify that the path supports ECN . 
 Agreed , each PN space has its own set of counters , and an ACK frame sent in a PN space conveys the counters of that PN space .
Paragraph (version A):
The value in the Unused field is selected randomly by the server.
Paragraph (version B):
The value in the Unused field is selected randomly by the server.
Clients MUST ignore the value of this field.  Servers SHOULD set the
most significant bit of this field (0x40) to 1 so that Version
Negotiation packets appear to have the Fixed Bit field.