Re: WGLC for Datagram Extension

David Schinazi <> Thu, 23 September 2021 23:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 505FA3A0A73; Thu, 23 Sep 2021 16:53:51 -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 QgzjGgA6ozMG; Thu, 23 Sep 2021 16:53:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 987D43A0A6F; Thu, 23 Sep 2021 16:53:46 -0700 (PDT)
Received: by with SMTP id k23-20020a17090a591700b001976d2db364so6062463pji.2; Thu, 23 Sep 2021 16:53:46 -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=R3kYPJz7MMhlOwOWottC00qO1JFC8XCPVfWx+u4PP4o=; b=ZUbhFaMq9GzYnVWeEHH85RXi9gOco37avGA6OaW53sy37K+XtFX+kN6clqpY4LKedZ tBQiznfQhT8VKt4mGqz2Cip+saxhoFpnAkVaCUoGHyejwzGF/eHigSgvAQb3Q4RhDDWh 8OIcsUZmMx5KoreQzIeVyf0JAAmiDT0LpDkjZ1mhlDosQYxjSPjzjBIt7901HAEY0gyl rx7IpB+/TGrqCJ9HB62HINO34J3HxLY6EKdhxQjj+5HcWzETQdO9hJ9fI0t2wUlNAIUe +fwYjVTQnTHWXcmABGhtLpTgziA/b8lPI0hr5zegl5M/Gv3lP9hroSyBQ2MTrWVo/oDy xzwA==
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=R3kYPJz7MMhlOwOWottC00qO1JFC8XCPVfWx+u4PP4o=; b=J89N6Nx+9ueGqu21/tMdwvPpKlbfqhlpAd/jCBQE0THD3Du36BEWKmJg5l1MrmT5o3 6cUgvr3t6kbC2jwJ/bEjDTPztup7qNLDClq8X1waRoENFP0w1vtx/eI8ZRuv1FEWpwWQ 0qca2E3v21jB22mtjJoN53XlVzbTDQ4uFfnuEACA4DJziGphfER83E6nRtapz+BAA/Mm IqwqrHgt0dr5fgO3etxEcgX7i2KpevQ5zd3wx7X74VxZ+NFYC/TnmZHTXkSaLj5GAKFq 8WaxQB9VkFq+9mGsl4fkui/FVfxyMnt8YfbaK9P6qizgD70QOdGEcQTiEwvs/ysQMtpP fkWA==
X-Gm-Message-State: AOAM531KIGTSkB8iH9OHMyqo2yoSRXApWrmJ8yqTK3RaDYWe0mqNQ3SC PiXv5BwnWxhBToIwDWvZ4X0wQRG0E40mTHyoLZux0Sh6PwA=
X-Google-Smtp-Source: ABdhPJyXNAv8av8OB+aG4p+EynCj87tCLl3IJ4lHbmNc5XvgXwIwk/8JotgKz/2gWX8DIiIpCcVMzV5AAVt2vUVpo3I=
X-Received: by 2002:a17:90a:1944:: with SMTP id 4mr19935012pjh.221.1632441225589; Thu, 23 Sep 2021 16:53:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Thu, 23 Sep 2021 16:53:34 -0700
Message-ID: <>
Subject: Re: WGLC for Datagram Extension
To: Spencer Dawkins at IETF <>
Cc: Lucas Pardue <>, QUIC WG <>, QUIC WG Chairs <>
Content-Type: multipart/alternative; boundary="0000000000005e364505ccb257b1"
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:53:52 -0000

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

Regarding your editorial comments, could I ask you to send them our way as
a PR to <> ?


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