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

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>
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>
> 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>
>> 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 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>
>>> *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
>>>
>>> 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/
>>>
>>> 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
>> https://www.ietf.org/mailman/listinfo/avt
>>
>