Hi, David, On Thu, Sep 23, 2021 at 6:53 PM David Schinazi <[email protected]> wrote:
> 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>. > 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 > 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 >>> >>
