Re: [AVTCORE] Working Group Last Call on "Multiplexing Scheme Updates for QUIC"

I’m not sure ambiguity between QUIC and TURN channels should be a concern.

TURN channel packets should only ever be received from a TURN server, and a TURN client knows whether it sent TURN allocation requests, and channel-binding requests, to a server.  A TURN client needs to be able to disambiguate STUN (i.e. regular TURN) packets from TURN channel packets, but packets from a TURN server can be disambiguated from packets from a peer based on the source IP and port.

Thus, this document needs to describe how to disambiguate within the set {QUIC, DTLS, RTP, RTCP, STUN, ZRTP}, and separately within the set {STUN, TURN channel}; but these two sets shouldn’t ever be overlapping.

> On May 20, 2022, at 4:10 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
> 
> Thanks Bernard.
> 
> Another option could be to say that 64-79 is ambiguous between QUIC and TURN,
> so it's best to avoid running both on the same socket. However, if both are in use
> then the best algorithm is to pass the packet to QUIC and if it fails to decrypt then
> pass it to TURN. This works in QUICv1 and QUICv2 because for those versions,
> all QUIC short header packets are encrypted with forward secure keys. It might not
> work for some future versions of QUIC but we can note that as a warning.
> 
> David
> 
> On Fri, May 20, 2022 at 11:15 AM Bernard Aboba <bernard.aboba@gmail.com <mailto:bernard.aboba@gmail.com>> wrote:
> David --
> 
> Thank you for your comments. I will make the changes you recommend with respect to bit greasing. 
> 
> The TURN channel conflict issue will require some WG discussion. 
> 
> TURN channels are not supported in WebRTC, so the potential conflict between TURN channels and QUIC short header packets would not occur in a situation where the STUN/TURN/RTP/RTCP implementation is webrtc-based.  While ICE traffic will be exchanged prior to exchange of P2P QUIC packets, I believe that TURN channel traffic can overlap in time with QUIC short header packets, and since there is overlap in their first octet range with TURN channels and QUIC short header packets, the only solution might be to say "don't use TURN channels".   Anyone see an issue with that? 
> 
> Even though the P2P QUIC trial in Chromium only. allowed a single connection between endpoints, the WG has discussed the potential need for more than one P2P QUIC connection between endpoints. So we probably want to avoid assumptions about a single connection between peers, if possible. 
> 
> On Fri, May 20, 2022 at 10:23 AM David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>> wrote:
> [ QUIC to BCC ]
> 
> Thanks for the ping Jonathan.
> 
> I've read the document and overall it looks good, it's clear and
> well-written, however I found a couple issues:
> 
> First issue is on QUIC bit greasing; the draft currently says:
> 
>    However, it is not compatible with QUIC Bit
>    greasing, as defined in [I-D.ietf-quic-bit-grease].  Therefore, in
>    situations where multiplexing is desired, QUIC Bit greasing MUST NOT
>    be negotiated.
> 
> but that doesn't reflect how QUIC bit grease works: every endpoint indicates
> it is willing to accept grease - you don't need both endpoints to agree to receive
> grease for grease to be enabled in the other direction. So I'd rephrase it as such:
> 
>    However, it is not compatible with QUIC Bit
>    greasing, as defined in [I-D.ietf-quic-bit-grease].  Therefore,
>    endpoints that wish to use multiplexing on their socket MUST
>    NOT send the grease_quic_bit transport parameter.
> 
> Similarly, I'd remove any mention of "negotiating QUIC bit greasing" in other
> parts of the document since the use of "negotiation" is unclear.
> 
> Also, typo "demultplexed"
> 
> Second issue is on the demultiplexing algorithm; draft currently says:
> 
>    If the value is
>    between 64 and 79 inclusive, then if a packet has been previously
>    forwarded that is in the range of 192 and 255, then the packet is
>    QUIC, otherwise it is TURN Channel.
> 
> It's unclear to me what the scope of "if a packet has been previously
> forwarded" is. In particular, how far back does "previously" go? If it
> means "since this socket has been opened", then this only works if
> there is only one QUIC connection on this socket. Also, is this a
> listening socket (3-tuple) or a connected socket (5-tuple)? One
> more point about this: relying on the fact that connections start
> with long headers is dangerous: QUICv1 behaves that way but the
> QUIC invariants on RFC8999 specify that other versions of QUIC
> might change that.
> 
> David
> 
> 
> On Fri, May 20, 2022 at 9:46 AM Jonathan Lennox <jonathan.lennox@8x8.com <mailto:jonathan.lennox@8x8.com>> wrote:
> The AVTCore working group is holding a Working Group Last Call on its document “Multiplexing Scheme Updates for QUIC”.
> 
> We would appreciate review by subject matter experts in QUIC.  Please comment on the avt@ietf.org <mailto:avt@ietf.org> mailing list.
> 
> For background, the abstract of this document is:
> 
>    This document defines how QUIC, Datagram Transport Layer Security
>    (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol
>    (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using
>    Relays around NAT (TURN), and ZRTP packets are multiplexed on a
>    single receiving socket.
> 
>    This document updates RFC 7983 and RFC 5764.
> 
>> Begin forwarded message:
>> 
>> From: Jonathan Lennox <jonathan.lennox@8x8.com <mailto:jonathan.lennox@8x8.com>>
>> Subject: Working Group Last Call on "Multiplexing Scheme Updates for QUIC"
>> Date: May 20, 2022 at 12:40:06 PM EDT
>> To: avt@ietf.org <mailto:avt@ietf.org>
>> 
>> This is an announcement of Working Group Last Call (WGLC) on "Multiplexing Scheme Updates for QUIC”.
>> 
>> The document is available for inspection here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc7983bis/ <https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc7983bis/>
>> 
>> WGLC will last until Monday, June 6, 2022, midnight Pacific Time.
>> 
>> In response, please reply with one of the following:
>>    * I support publication of the document as is.
>>    * I support publication of the document, but have comments (please include details)
>>    * I object to publication of the document, based on the following issues (please include details),
>> 
>> Jonathan
>> For the AVTCore Chairs
>> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org <mailto:avt@ietf.org>
> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>