Re: WGLC for Datagram Extension

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]>
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.
>
> Cheers,
> Lucas
>
> [1] - https://datatracker.ietf.org/doc/draft-ietf-masque-h3-datagram
>