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

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
>