Re: [AVTCORE] Call for Adoption: Multiplexing Scheme Updates for QUIC

[Justin Uberti <[e-mail]>]

On Thu, Jul 30, 2020 at 9:49 PM Martin Thomson <[e-mail]> wrote:

> Hi Jonathan,
>
> The draft makes some claims that are not clearly true about QUIC.  In
> particular:
>
>    As noted in [I-D.aboba-avtcore-quic-multiplexing], the first octet of
>    a QUIC short header packet falls in the range 64 to 127, thereby
>    overlapping with the allocated range for TURN channels of 64 to 79.
>
> It's important to distinguish between QUIC as defined in
> draft-ietf-quic-transport and QUIC as defined in
> draft-ietf-quic-invariants.  The draft is correct in that it cites the
> former and relies on properties of the former.  However, it is very easy to
> misinterpret this statement as applying more broadly.
>
> To add spice to this, the claims here are invalid if you consider
> draft-thomson-quic-bit-grease, which allows long and short headers to take
> 128-255 and 0-127 respectively.
>
> It would be most unfortunate if an IETF RFC were to so directly encourage
> protocol ossification.  This draft needs a more careful treatment of this
> problem.
>
> Other than that fairly serious shortcoming, this is a worthwhile update
> that is worth doing.
>
> p.s., I don't know if the approach suggested for TURN channels is
> appropriate, but I trust that AVTCore are competent to decide that.
>

TBH, I'm not sure whether TURN demux is a real-world problem. You only need
to handle TURN channels if you are talking to a TURN server, and in that
case, you should not be receiving unencapsulated RTP or QUIC traffic on the
same 5-tuple.

If the goal is to be able to mux QUIC and TURN channels on the same
5-tuple, I imagine that we'd probably want to first design some sort of new
QTURN that uses QUIC to address TURN's many shortcomings (e.g., TURN
authentication).