Re: WGLC for Datagram Extension

[Christian Huitema <[e-mail]>]

On 9/23/2021 11:11 AM, Lucas Pardue wrote:
> 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.

Another possibility is to use FEC with Datagrams. If an application does 
that, it could very well apply FEC before demuxing.

Or, use segmentation/reassembly of datagrams to mitigate MTU issues. 
Again, if an application does that, it could very well process a 
reassembly header before any demuxing.

Or, use both segmentation/reassembly and FEC.

And of course, if the application needs to stick a flow-id in front of 
the datagram packets, it can do that easily, no transport support needed...

-- Christian Huitema