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

From: Jonathan Lennox <[email-masked]>
Date: Thu, 30 Jul 2020 10:18:17 -0400

(Note this mail is Cc’d to [email-masked] <mailto:[email-masked]>; please keep discussion on [email-masked] <mailto:[email-masked]>.)

This is a call for adoption in the AVTCore working group of the document “Multiplexing Scheme Updates for QUIC”, https://tools.ietf.org/html/draft-aboba-avtcore-rfc7983bis-00 <https://tools.ietf.org/html/draft-aboba-avtcore-rfc7983bis-00> , as the basis for a working group item, along with an appropriate milestone.

As a summary for those unfamiliar with the document, it updates RFC 7983 to document how QUIC can be demultiplexed from STUN, DTLS, RTP, and other protocols common in WebRTC and WebRTC-like systems.

If you have opinions on whether this document should be adopted, please respond to the AVTCore mailing list by Friday, August 14th.

Technical comments on the document itself are also always welcome, of course!

Thanks,

Jonathan Lennox
AVTCore co-chair

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 30 Jul 2020 08:23:19 -0700

I support the adoption of this document as WG item.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Jul 2020 10:11:39 -0700

(Chair hat off). I also support adoption of RFC 7983bis as a WG work item.

On Thu, Jul 30, 2020 at 8:23 AM Marc Petit-Huguenin <[email-masked]>
wrote:

> > (Note this mail is Cc’d to [email-masked] <mailto:[email-masked]>; please
> keep discussion on [email-masked] <mailto:[email-masked]>.)
> >
> > This is a call for adoption in the AVTCore working group of the document
> “Multiplexing Scheme Updates for QUIC”,
> https://tools.ietf.org/html/draft-aboba-avtcore-rfc7983bis-00 <
> https://tools.ietf.org/html/draft-aboba-avtcore-rfc7983bis-00> , as the
> basis for a working group item, along with an appropriate milestone.
> >
> > As a summary for those unfamiliar with the document, it updates RFC 7983
> to document how QUIC can be demultiplexed from STUN, DTLS, RTP, and other
> protocols common in WebRTC and WebRTC-like systems.
> >
> > If you have opinions on whether this document should be adopted, please
> respond to the AVTCore mailing list by Friday, August 14th.
> >
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 30 Jul 2020 17:58:41 +0000

I support adoption by the WG.

Cheers,

Gonzalo

On Jul 30, 2020, at 10:18 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

(Note this mail is Cc’d to [email-masked]<mailto:[email-masked]>; please keep discussion on [email-masked]<mailto:[email-masked]>.)

This is a call for adoption in the AVTCore working group of the document “Multiplexing Scheme Updates for QUIC”, https://tools.ietf.org/html/draft-aboba-avtcore-rfc7983bis-00 , as the basis for a working group item, along with an appropriate milestone.

Thanks,

Jonathan Lennox
AVTCore co-chair

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt

---

From: Justin Uberti <[email-masked]>
Date: Thu, 30 Jul 2020 16:35:25 -0700

On Thu, Jul 30, 2020 at 10:58 AM Gonzalo Salgueiro (gsalguei) <gsalguei=
[email-masked]> wrote:

> On Jul 30, 2020, at 10:18 AM, Jonathan Lennox <[email-masked]>
> wrote:
>
> (Note this mail is Cc’d to [email-masked]; please keep discussion on
> [email-masked].)
>
> https://tools.ietf.org/html/draft-aboba-avtcore-rfc7983bis-00 , as the

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Fri, 31 Jul 2020 08:13:36 +0800

I support adoption of RFC 7983bis as a WG work item.

On Fri, Jul 31, 2020 at 7:35 AM Justin Uberti <juberti=
[email-masked]> wrote:

>> basis for a working group item, along with an appropriate milestone..
>>

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 31 Jul 2020 14:48:46 +1000

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.

On Fri, Jul 31, 2020, at 00:18, Jonathan Lennox wrote:
> This is a call for adoption in the AVTCore working group of the 
> document “Multiplexing Scheme Updates for QUIC”, 
> As a summary for those unfamiliar with the document, it updates RFC 
> 7983 to document how QUIC can be demultiplexed from STUN, DTLS, RTP, 
> and other protocols common in WebRTC and WebRTC-like systems.
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 31 Jul 2020 10:43:06 -0700

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

> 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.
>
> 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).