Subject: WGLC for Datagram Extension

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 Sep 2021 21:34:24 +0100

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.

Working Group Last Call will end on 30 September 2021, Anywhere on Earth.

Best Regards,
Matt & Lucas
QUIC WG Chairs

[1] https://github.com/quicwg/datagram/issues

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Sep 2021 23:00:10 +0200

Hi Lucas,

I just have one question:

> DATAGRAM frames belong to a QUIC connection as a whole, and are not 
> strongly associated with any stream ID at the QUIC layer

What does "strongly associated" mean in this context?  Apologies if this 
is well trodden ground.

Thanks,

Eliot

On 16.09.21 22:34, Lucas Pardue 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.
>
> <https://github.com/quicwg/datagram/issues>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Sep 2021 15:54:09 -0700

Eliot Lear wrote on 9/16/2021 2:00 PM:
> What does "strongly associated" mean in this context?  Apologies if 
> this is well trodden ground.

i'm pretty sure it's what in pre-QUIC times, would be called a "flow" or 
a "UDP 4-tuple".

vixie

-- 
Sent from Postbox <https://www.postbox-inc.com>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 17 Sep 2021 09:48:01 +1000

> What does "strongly associated" mean in this context?  Apologies if this 

This is unfortunately so well-trodden that this text was added without consideration for people who weren't involved in the trampling process.

I think that "strongly" can be struck here, it's working too hard.  And smart people will latch onto it.

Context:

When we use DATAGRAMs in HTTP (and likely in other contexts) there will be a need to bind each DATAGRAM to a (request) stream.  That's necessary to ensure that flows of DATAGRAMs can be routed by gateways and the like along with the stream.  There were lots of debates about how to manage that binding and the layer at which it would be documented.  This text is likely intended to record the conclusion that this document definitely isn't where that sort of binding occurs, but for someone without that history.  It doesn't really achieve that though and because it doesn't need to (why would you think that any association exists?), it ends up being distracting.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 16 Sep 2021 17:05:00 -0700

Agreed that the word “strongly” can simply be removed.

Applications using QUIC can choose to associate particular datagrams with data sent on a stream—like HTTP/3 choosing to add a value calculated based on stream IDs into the payload of the DATAGRAM frame—but such associations do not belong to the transport protocol.

https://github.com/quicwg/datagram/issues/52 <https://github.com/quicwg/datagram/issues/52>

Thanks,
Tommy

> On Sep 16, 2021, at 4:48 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 16 Sep 2021 18:24:45 -0700

The way I understand it, we want to say that QUIC makes no effort to 
partition the space of datagrams into subcategories. Applications send 
and receive datagrams, and the conceptual API is, "here is a datagram 
that should be sent or just arrived on this QUIC connection". I 
application want to treat some datagrams as duck calls and some other 
datagrams as music packets, they can do that, but they have to do it 
themselves by decorating the datagrams appropriately. And whether they 
do that using stream IDs or packet codes or sequence numbers is not 
QUIC's business.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Sep 2021 11:54:53 +0200

Hi Paul,

On 17.09.21 00:54, Paul Vixie wrote:
> i'm pretty sure it's what in pre-QUIC times, would be called a "flow" 
> or a "UDP 4-tuple".

Thanks.  I interpret it similarly, but perhaps there are conditions 
under which the authors anticipated a DATAGRAM being associated with a 
STREAM?  I dunno.

Eliot

---

From: Ian Swett <[email-masked]>
Date: Fri, 17 Sep 2021 06:37:04 -0400

On Fri, Sep 17, 2021 at 5:55 AM Eliot Lear <[email-masked]> wrote:

> That's what H3-datagram
<https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram> does,
but it's not in scope for this draft.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Sep 2021 12:54:38 +0200

Ok, thanks for this.

I would further suggest that an example flow be included; even if it is 
just two or three datagrams.  Showing it all in operation is always helpful.

Eliot

On 17.09.21 02:05, Tommy Pauly wrote:
> Applications using QUIC can choose to associate particular datagrams 
> with data sent on a stream—like HTTP/3 choosing to add a value 
> calculated based on stream IDs into the payload of the DATAGRAM 
> frame—but such associations do not belong to the transport protocol.
>
> https://github.com/quicwg/datagram/issues/52 
> <https://github.com/quicwg/datagram/issues/52>
>
> Thanks,
> Tommy
>
>> On Sep 16, 2021, at 4:48 PM, Martin Thomson <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> This is unfortunately so well-trodden that this text was added 
>> without consideration for people who weren't involved in the 
>> trampling process.
>>
>> When we use DATAGRAMs in HTTP (and likely in other contexts) there 
>> will be a need to bind each DATAGRAM to a (request) stream.  That's 
>> necessary to ensure that flows of DATAGRAMs can be routed by gateways 
>> and the like along with the stream.  There were lots of debates about 
>> how to manage that binding and the layer at which it would be 
>> documented.  This text is likely intended to record the conclusion 
>> that this document definitely isn't where that sort of binding 
>> occurs, but for someone without that history.  It doesn't really 
>> achieve that though and because it doesn't need to (why would you 
>> think that any association exists?), it ends up being distracting.
>>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 23 Sep 2021 12:51:36 -0500

Hi, Lucas and Matt,

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

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 23 Sep 2021 19:11:58 +0100

Hi Spencer,

> 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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 Sep 2021 12:45:37 -0700

> 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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 23 Sep 2021 18:32:56 -0500

Hi, Lucas,

I'm top-posting to say that I'm not talking about multiplexing datagrames
now (except to thank you and Christian for your replies), but I'm still
looking at the datagram draft, and noticed something odd. Could you put
your working group chair hat back on for a moment?

>From the Introduction:

*This document defines two new DATAGRAM QUIC frame types, which carry
application data without requiring retransmissions.*

And most of the document about "datagram frame types" (plural), but pretty
much all of
https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-datagram-frame-type
talks about "the datagram frame type" (singular) - even the section header
uses the singular phrasing, along with the caption to Figure 1.

I understand what the document is saying, to be

   - there are two datagram frame types, 0x30 and 0x31
   - the only difference between these two datagram frame types is that
   datagram frames with frame type 0x30 do not include a length field, while
   datagram frames with frame type 0x31 do contain a contain a length field,
   and
   - otherwise, whatever this document says about "datagrams" is true for
   both datagram frame types.

Is that about right?

I can dig that out from the document, but if that was clearer in Section 4
- "Datagram Frame Types", and a couple of clarifying sentences, that might
be a bit easier for the reader (and, of course, for the various review
teams that will be looking at this document for the first time during IETF
Last Call).

As long as I'm still typing, I might mention one other thing - I searched
for the string "reliabl" in the draft, and there are 24 occurrences, which
is fine, although perhaps repetitive, until you get down to
https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-behavior-and-usage,
which says

When an application sends an unreliable datagram over a QUIC connection,
QUIC will generate a new DATAGRAM frame and send it in the first available
packet. This frame SHOULD be sent as soon as possible, and MAY be coalesced
with other frames.

Could "unreliable" be dropped from the first sentence? It would belong
there if reliable datagrams were an option, but (after 20 occurrences
explaining that all datagrams are unreliable), maybe this is just inviting
confusion.

Thanks for considering my comments, of course. Do The Right Thing!

Best,

Spencer

On Thu, Sep 23, 2021 at 1:12 PM Lucas Pardue <[email-masked]>
wrote:

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

---

From: David Schinazi <[email-masked]>
Date: Thu, 23 Sep 2021 16:53:34 -0700

Hi Spencer,

Yes, your interpretation is correct. The language about whether it's
interchangeably one frame type or two frame types mirrors RFC 9000's
definition of the STREAM frame which is also one or eight frames depending
on how you look at it <
https://datatracker.ietf.org/doc/html/rfc9000#section-19.8>.

Regarding your editorial comments, could I ask you to send them our way as
a PR to <https://github.com/quicwg/datagram> ?

Thanks,
David

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 23 Sep 2021 20:07:50 -0500

Hi, David,

> https://datatracker.ietf.org/doc/html/rfc9000#section-19.8>.

Thank you for the background here (I was watching the base QUIC drafts, but
spent a lot of time looking at diffs, rather than re-reading carefully, so
your pointer was super helpful).

I did see a couple of places where the STREAM frame type was using plurals
(for example, https://www.rfc-editor.org/rfc/rfc9000.html#name-stream-frames,
plural,  versus
https://www.ietf.org/archive/id/draft-ietf-quic-datagram-04.html#name-datagram-frame-type,
singular), so I included that in the PR. I swear, if I wasn't looking for
the second datagram frame type in the second called "datagram frame type",
I wouldn't have noticed anything 🙂)

And it really was a couple of small changes. Thanks for considering my
comments.

Best,

SPencer

>> And most of the document about "datagram frame types" (plural), but
>> pretty much all of
>>    - otherwise, whatever this document says about "datagrams" is true
>>    for both datagram frame types.
>>
>> Is that about right?
>>
>> I can dig that out from the document, but if that was clearer in Section
>> 4 - "Datagram Frame Types", and a couple of clarifying sentences, that
>> might be a bit easier for the reader (and, of course, for the various
>> review teams that will be looking at this document for the first time
>> during IETF Last Call).
>>
>>>> On Thu, Sep 16, 2021 at 3:35 PM Lucas Pardue <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hello QUIC WG,
>>>>>
>>>> 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

---

From: David Schinazi <[email-masked]>
Date: Fri, 24 Sep 2021 09:46:28 -0700

Thanks Spencer! I've approved the PR - we can merge it at the end of WGLC
assuming no one objects.

David

On Thu, Sep 23, 2021 at 6:08 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Thank you for the background here (I was watching the base QUIC drafts,
> but spent a lot of time looking at diffs, rather than re-reading carefully,
> so your pointer was super helpful).
>
> (for example,
> https://www.rfc-editor.org/rfc/rfc9000.html#name-stream-frames, plural,
> versus
>> Regarding your editorial comments, could I ask you to send them our way
>> as a PR to <https://github.com/quicwg/datagram> ?
>>
>> Thanks,
>> David
>>
>>> I'm top-posting to say that I'm not talking about multiplexing
>>> datagrames now (except to thank you and Christian for your replies), but
>>> I'm still looking at the datagram draft, and noticed something odd. Could
>>> you put your working group chair hat back on for a moment?
>>>
>>> From the Introduction:
>>>
>>> As long as I'm still typing, I might mention one other thing - I
>>> searched for the string "reliabl" in the draft, and there are 24
>>> occurrences, which is fine, although perhaps repetitive, until you get down
>>> to
>>> When an application sends an unreliable datagram over a QUIC
>>> connection, QUIC will generate a new DATAGRAM frame and send it in the
>>> first available packet. This frame SHOULD be sent as soon as possible, and
>>> MAY be coalesced with other frames.
>>>
>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> 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!)
>>>>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 24 Sep 2021 11:48:40 -0500

On Fri, Sep 24, 2021 at 11:46 AM David Schinazi <[email-masked]>
wrote:

>> <https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram>
>>>>>
>>>>
Hi, David,

That sounds perfect, and thank you for your guidance on providing my
comments.

Best,

Spencer

---

From: Martin Duke <[email-masked]>
Date: Mon, 27 Sep 2021 12:06:56 -0700

As an individual, I believe that this document is ready for IETF Last Call.
I will file two exceedingly minor items in github.