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

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Mar 2017 06:46:52 -0700

[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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Mar 2017 06:49:56 -0700

I don't think that we need to multiplex QUIC with realtime media.  (If we multiplexed every conceivable protocol, we'd run out of bits.)

-- 
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#issuecomment-290416416

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Mar 2017 06:56:51 -0700

I tend to think the ability to do very low latency streaming on a UDP port you know works through NAT could be appealing.

Or, at least, shouldn't be accidentally prohibited...

-- 
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#issuecomment-290418431

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Mar 2017 11:05:07 -0700

To be a little more general: we should decide whether we want to allow QUIC flows to be easily multiplexed along with some other UDP-based protocols on a single port. 

Multiplexing with the full WebRTC stack is one example of this, but is not the only use case. For example, if we want to enable peer-to-peer QUIC in future, then we should consider defining the packet formats to be easily distinguishable from STUN and/or TURN to help NAT traversal.

-- 
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#issuecomment-290494237