Re: WGLC for Datagram Extension

[Lucas Pardue <[e-mail]>]

Hi Spencer,

On Thu, Sep 23, 2021 at 6:52 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

> Hi, Lucas and Matt,
>
> On Thu, Sep 16, 2021 at 3:35 PM Lucas Pardue <[e-mail]>
> wrote:
>
>> Hello QUIC WG,
>>
>> This email starts the Working Group Last Call for "An Unreliable Datagram
>> Extension to QUIC", located at:
>>   https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html
>>
>> Please take time to review it carefully and raise any remaining issues
>> you see either on the GitHub repo issues list[1] or on this mailing list.
>>
>
> I've re-read the discussion in https://github.com/quicwg/datagram/issues/6,
> and now better understand the points of view that resulted in the lack of
> datagram multiplexing in this specification (I was following that
> discussion when it was happening, but hindsight during re-reading helped a
> lot!)
>
> I especially appreciate the addition of the text in
> https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-multiplexing-datagrams
> .
>
> I accept the wisdom of getting more experience with various people using
> application-defined multiplexing in various ways before adding any flavor
> of multiplexing at the transport layer, and agree that holding this
> specification up while that experience is gathered, would not be The Right
> Thing To Do.
>
> I'm aware of at least two "RTP over QUIC" proposals that assume that
> they'll need to multiplex datagrams, so I won't be surprised if we return
> to this question in the future, but for now, the chairs are Doing The Right
> Thing, and I support requesting publication of -04 (modulo any changes that
> pop up in WGLC, of course).
>

Thanks for your comments.

Chair hat off, speaking as an individual. To add to the examples, the
MASQUE working group is working on a draft to define HTTP's use of QUIC
DATAGRAM frames and it includes multiplexing [1]. The working group's 00
draft started with a single variable-length integer multiplexing identifier
called the Flow ID. After some fruitful WG implementation and discussion,
in draft 01 it switched to an identifier tuple (Quarter Stream ID, Contenxt
ID). I'd say that we're still figuring out exactly how the things the
__use__ datagrams, want to use datagrams. I think it's too early to
understand the right common transport solution at this time, and that
leaving it undefined does not prevent people from using datagram frames for
their own precise needs and purpose.

Cheers,
Lucas

[1] - https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram