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 On Thu, Sep 23, 2021 at 4:33 PM Spencer Dawkins at IETF < [email protected]> wrote: > 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 protected]> > wrote: > >> Hi Spencer, >> >> On Thu, Sep 23, 2021 at 6:52 PM Spencer Dawkins at IETF < >> [email protected]> wrote: >> >>> Hi, Lucas and Matt, >>> >>> On Thu, Sep 16, 2021 at 3:35 PM Lucas Pardue <[email protected]> >>> 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 >> >
