Re: WGLC for Datagram Extension

Spencer Dawkins at IETF <> Fri, 24 September 2021 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B48AB3A0E17; Thu, 23 Sep 2021 18:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F42G20VH3mgn; Thu, 23 Sep 2021 18:08:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D97123A0E12; Thu, 23 Sep 2021 18:08:17 -0700 (PDT)
Received: by with SMTP id o13so5479394uat.6; Thu, 23 Sep 2021 18:08:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dCqLYOvBD3tpdz+Jm1IGYwgjcsmTTADF62/ocp+ZWqw=; b=X/cT3EZ/fPnTvR+7sxdRW3pFBto3cu3i4CiZn+ZnsYwL7n4gjx/7im8rW5VOiLd6MP r7XIG7C5tk/OSgsfqpxhBkyjSYEYR8Psaa7Sbz5SNgaAk77UW8dGtCbokuIBxn2LzjIj aQdWEhF2kIXeCdNnHCkUUfsQKXpQ3EByNXXMSNUhpwNQ2QuSBSeoVStK2ki2sIkFGb+5 lKFG0WIs86Junl0EJpDAxwUxYYIbDJZZkuLUa+wYBM5SGK50SJsAiOJ0Dqxg+cNjuoWw WsNY4OXWaC7SJ2gxC2iW0+m6jwG6/wkHxw+1P5u6VCzWaoJZam0RdOMkG8OKx1gkkqc9 7yjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dCqLYOvBD3tpdz+Jm1IGYwgjcsmTTADF62/ocp+ZWqw=; b=5EyOwL1FkhtFaC1nINtK6NyyFGh9yYgtKpSqIXOxO4pp5Uex8ngC86sOHt/phTgobW BOpXSOzwmBvxEqsXJJYfkaG02NGESLAg+mx9GRevbOUzUGf7/aL27UbYoX/W2M6oFw0w kLITomg4pO/y4XU03kbLGGYR/h0LU6aXAsCuDGnqA6CYEIIvny2Amt6nVtldglhsRYVP RQD1CuJVAgsJjqtb4zIYW7r47cunvLFuV40vmvxS2t7rRSxL0YTyVVqTT8RQTBxcXTh5 dv7CEdyvVSYk55V0qk3Vtjj0tT665b+tYQVGV980f1j+1XJ0dRuaefqJXjlOIeZQe37p 8xDw==
X-Gm-Message-State: AOAM531tb6mM7q3Gxf7ZIaMqpbAlek5lvNVqEAeXb00AwJH3aw+36rMw Ez8XKZC3wI2eNIXXK0EevheWMXh6/rQX0fw7LSE=
X-Google-Smtp-Source: ABdhPJxVdil9N/KzKWFH0me4QmxaQtFbOpIWKT2CWv9PmsUDU1QKB2gO3DljwOu62Wx0Oa9raOJ1ZbTQNr3ouqbQveU=
X-Received: by 2002:ab0:6d8b:: with SMTP id m11mr7233612uah.35.1632445696557; Thu, 23 Sep 2021 18:08:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 23 Sep 2021 20:07:50 -0500
Message-ID: <>
Subject: Re: WGLC for Datagram Extension
To: David Schinazi <>
Cc: Lucas Pardue <>, QUIC WG <>, QUIC WG Chairs <>
Content-Type: multipart/alternative; boundary="000000000000dbc41305ccb361ac"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Sep 2021 01:08:23 -0000

Hi, David,

On Thu, Sep 23, 2021 at 6:53 PM David Schinazi <>

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

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,,
plural,  versus,
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



> Regarding your editorial comments, could I ask you to send them our way as
> a PR to <> ?
> Thanks,
> David
> On Thu, Sep 23, 2021 at 4:33 PM Spencer Dawkins at IETF <
>> 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
>> 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
>> 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 <>
>> wrote:
>>> Hi Spencer,
>>> On Thu, Sep 23, 2021 at 6:52 PM Spencer Dawkins at IETF <
>>>> wrote:
>>>> Hi, Lucas and Matt,
>>>> On Thu, Sep 16, 2021 at 3:35 PM Lucas Pardue <
>>>>> wrote:
>>>>> Hello QUIC WG,
>>>>> This email starts the Working Group Last Call for "An Unreliable
>>>>> Datagram Extension to QUIC", located at:
>>>>> 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
>>>>, 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
>>>> .
>>>> 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] -