Re: WGLC for Datagram Extension

Spencer Dawkins at IETF <> Thu, 23 September 2021 23:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F59B3A0898; Thu, 23 Sep 2021 16:33:26 -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 efZuq66mNJLh; Thu, 23 Sep 2021 16:33:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D2263A0891; Thu, 23 Sep 2021 16:33:23 -0700 (PDT)
Received: by with SMTP id n17so8226367vsr.10; Thu, 23 Sep 2021 16:33:23 -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=UAv5gphorX2DyLLVGrSSlO6LJfrOt+ncseUIN7ZZpVo=; b=SJ0an3h+8XimEx+rC3aZUb+oAfzYjiSEIzW1d9XusC9y6supbOaok/TwLuDMQ+qpWN fWkGzh9RBx3ibLx1+9vhlnOGsiiZD3mfUy6FsBC6WrQp3J6hDYooXswJcakq7+lGl1Eh b/TQY83Rr+tj1w3m3GGTRI65dUqndc8RM3hctuhHkikNKGXbpYKvlTJSfECLAsY7t9tj Gjo7mvx3xhnABG6Yd92dSSxP3EWAWgzj8gRq9C7CUpR94hWGSvQnGm70vVEwmCY78K1y l6BJaXDzu+wfx+YDQ4DbdSQC2EA0gRZ8kbTGydH35weJCMfa1cHH4EPYfU4HzTm6wXyL TwVg==
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=UAv5gphorX2DyLLVGrSSlO6LJfrOt+ncseUIN7ZZpVo=; b=C2U012gCbp0Y5PT3RoDu3x20AJWXKhbvR/m6idAUrUHRgWdTny8i00OFjF6uxTX4/k x68Cap1e+uR4KCnsNd9KO0bC/JitK34SMvIcrYIDkyhgoU4qknssqxWUEKXk6yD+su95 pBjn3sAs/eBjP7VrnkiIhP9rH/KpOK5LOdxZzRUBx1s1n9a6tKaMJPF3kZ0duVUa7u9A 8ojQMWyWni3pXVoWRMY2k0XK6Zv0vwMqsgG62KkKZdZb8VOg7hYYYwWUcO/DFazuIGYS 2CfXGjwldU8tqihFTsvPVBFYtLqbdBhUeXG+Pe0fsO42LJkGhZsC9Vbq6AXAdYbSape/ UKAQ==
X-Gm-Message-State: AOAM5338iZ+DjJnFcUeAYfDrAzhN5cGFGISJwznnMq81Ap8EDRoZjWnz 0GPKV+6CS0fYkBeZClhkRVI7Koqz1+VyGAHtbByd7vP2XHk=
X-Google-Smtp-Source: ABdhPJysDldpgLlj04XRE74o9xOuKE6CEVAJRJVCxtjysAlgllLoBMOlaqurJtVY4W6qHqe9SQzEvnjDV/agStBqMko=
X-Received: by 2002:a67:2d8d:: with SMTP id t135mr4205158vst.7.1632440002338; Thu, 23 Sep 2021 16:33:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 23 Sep 2021 18:32:56 -0500
Message-ID: <>
Subject: Re: WGLC for Datagram Extension
To: Lucas Pardue <>
Cc: QUIC WG <>, QUIC WG Chairs <>
Content-Type: multipart/alternative; boundary="00000000000074e30005ccb20ec7"
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: Thu, 23 Sep 2021 23:33:26 -0000

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

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



On Thu, Sep 23, 2021 at 1:12 PM Lucas Pardue <>

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