Draft: draft-ietf-quic-manageability

Commentary: addresses 
 started this discussion in the mailing list ( ) , which made me think that the distinguishable QUIC version number practice should be written in the applicability draft . would like to know what others think about it . 
 I do n't think that it needs consideration . We have n't talked about sharing ports before , so while QUIC gives us that option under certain narrow conditions , those are special enough that burning text on it is wasteful . 
 We already have this text in manageability : and 
 The point about the 1 bit is probably most pertinent to question . And I think that it is sufficient . 
 Yes , there are some text in the manageability doc but I was asking if we should include some text in the applicability draft as well . The applicability draft is more towards the designer and developers of the applications on top of QUIC which I believe the case for DoQ. " As wire image is not invariant , demuxing based on that ( for example 1 bit for version QUIC 1 ) will make a deployment very version dependent and that need to be taken into consideration " - saying something like - would be helpful I think . I also see the mailing list discussions are deviating from what is we are saying in the manageability document - coexisting of UDP based protocols on the same port . 
 I 'm not sure we need any additional discussion in the applicability draft . RFC900 has this : I do n't think there is anything else that we could say in the applicability draft . For manageability , I create a PR with a reference to draft - ietf - quic - bit - grease 
 on a second thought , I think we are fine here . Thanks .
Mailing list commentary: Hello QUIC , DNS - over - QUIC just requested UDP Port 843 , where it would coexist with DNS - over - DTLS . As long as the DNS server is running QUICv1 without greasing the QUIC bit , that should work out just fine . This does lead me to think about how QUIC versions will interact with the port over which they are intended to operate . In RFC 9000 , designed explicitly for HTTP/443 , we took care to make sure the signature was distinguishable from other things that run there . So , if someone wanted to deploy QUIC over some other UDP port , we might have to roll a new version simply to create a signature that does n't clash with the protocols already operating over that port . For any given QUIC application , there is therefore a choice between ( 1 ) Picking an existing port and making sure that either ( a ) the other UDP application is n't present , or ( b ) using only QUIC versions that are distinguishable , or ( 2 ) Requesting a new port A few questions : Is my analysis correct ? Are we comfortable with having to take up these new versions when they arise ( which may not be that often ) ? Would it be preferable to have a less balkanized QUIC version space and more port allocations ? I would like to start thinking through this issue and perhaps issue guidance to the ports team .
Paragraph (version A):
While the second-most-significant bit (0x40) of the first octet is
set to 1 in most QUIC packets of the current version (see public-
header and Section 17 of QUIC-TRANSPORT), this method of recognizing
QUIC traffic is not reliable.  First, it only provides one bit of
information and is prone to collision with UDP-based protocols other
than those considered in RFC7983.  Second, this feature of the wire
image is not invariant QUIC-INVARIANTS and may change in future
versions of the protocol, or even be negotiated during the handshake
via the use of an extension.
Paragraph (version B):
While the second-most-significant bit (0x40) of the first octet is
set to 1 in most QUIC packets of the current version (see public-
header and Section 17 of QUIC-TRANSPORT), this method of recognizing
QUIC traffic is not reliable.  First, it only provides one bit of
information and is prone to collision with UDP-based protocols other
than those considered in RFC7983.  Second, this feature of the wire
image is not invariant QUIC-INVARIANTS and may change in future
versions of the protocol, or even be negotiated during the handshake
via the use of an extension QUIC-GREASE.