[quicwg/base-drafts] QUIC header format/demultiplexing (#426)

[Lars Eggert <[e-mail]>]

[I am raising this for @csperkins; text below is from him.]

If I understand correctly, the first octet of the new QUIC header is either:
```
 +-+-+-+-+-+-+-+-+
 |1|   Type (7)  |  Long header packet
 +-+-+-+-+-+-+-+-+
```
or
```
 +-+-+-+-+-+-+-+-+
 |0|C|K| Type (5)|  Short header packet
 +-+-+-+-+-+-+-+-+
```
Given the assigned types, this gives number values for the first octet in the ranges 0-3, 32-35, 64-67, 96-99, or 128-136.

RFC 7983 talks about how to demultiplex protocols running on a single UDP port, based on the values of the first octet. The important part is the new text table in Section 7, which demultiplexes based on the value of the first octet of the packet as follows:
```
                   +----------------+
                   |        [0..3] -+--> forward to STUN
                   |                |
                   |      [16..19] -+--> forward to ZRTP
                   |                |
       packet -->  |      [20..63] -+--> forward to DTLS
                   |                |
                   |      [64..79] -+--> forward to TURN Channel
                   |                |
                   |    [128..191] -+--> forward to RTP/RTCP
                   +----------------+
```
The QUIC headers don’t fit cleanly into this. The result is that it’s not possible to run demultiplex QUIC and WebRTC running on the same UDP port, since WebRTC uses STUN, DTLS, TURN and RTP/RTCP. Demultiplexing these is probably desirable, since it would let you switch from web traffic to interactive WebRTC or very low latency streaming without de-doing the NAT bindings on a port.

The simplest fix to allow the protocols to be demultiplexed is to set the top two bits of the first octet of a QUIC packet to 1 and reduce the size of the type fields:
```
 +-+-+-+-+-+-+-+-+
 |1|1|1|Type (5) |  Long header packet
 +-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+
 |1|1|0|C|K|Type3|  Short header packet
 +-+-+-+-+-+-+-+-+
```
There are probably other options that keep a larger type field, if we accept a less obvious bit packing, although even these likely lose one bit from the type field.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/426