Re: WGLC for Datagram Extension

Lucas Pardue <> Thu, 23 September 2021 18:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D1293A1641; Thu, 23 Sep 2021 11:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 dnVLCzYVVKt7; Thu, 23 Sep 2021 11:12:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E60E23A1640; Thu, 23 Sep 2021 11:12:11 -0700 (PDT)
Received: by with SMTP id v10so21477802edj.10; Thu, 23 Sep 2021 11:12:11 -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=WsN48O8v7zc8b4iPehd70QMAWzySRz+3e/qJKT5rONA=; b=h1lz+11qrY+9Xez21dNggY7JItbnrimr418Z2t6Y6FJCisWg8OBkZVI6VoAnhZdO3u oeb5T52bk4QYyGtqAzoHP16ZOIk2r+O6FuF+uRP1jby2luqqIBs3cCsrFcMrtFmCdVZp CcFqd/E4JvLscwwYCTjCLuaarZoccClWETuagPqaHyvuI4fFNnFvzzB29HiPsk+usJa4 TJb9jIWCjqR9xxCquTjhcqF/KZmWvUe2XJW1T0fLwKKO/7w10HWfHu9T5blhmxQetl0p JO2i83WM5iLdbB5qwwlEPByGeMRbU6c7gvIfMH8YHtngLE8PF4y4mzkbt23ieZaFguuW n5uA==
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=WsN48O8v7zc8b4iPehd70QMAWzySRz+3e/qJKT5rONA=; b=3V5Z7RB4nnDexPXBHznllxUFYNul8+uxDfW2fYkkLpzRrw7SM+hOQ+OZt9l/Iwzh+E zodqfyV4v+NI04v0wzL1/gXrYjLR+u0TXJwAergQ3RoPnOwRN6XJbAMBhuza48qYKDTI 852/gUCEaAw0oxFP+a+Ju/V06cjO4lSfPo8G4kOV3ilprzPoX6OgSpveJbmntqd0uJlk Q0VYSKkrjD6MSnEx307x9W1FSC99BHd+G62A3w3OfXq9W0ndEwQPl5z+4bEEEfPHf9w5 fICk+9VYH0viav6VyiMi/O/dbMZN+XvUPeIQE5SHnuYqfb7ry5Y0VVyMor1eHTL0ZIjA 375g==
X-Gm-Message-State: AOAM532ABML08wdygFY/fWEqJIxPiOhPDOgl14ozZmR4Jh/iQMCbmn8S d5ZzEF49Uh2oQY9z7LOc/egbZ5dJqt3Q7SHfYrdg+rkeuUM=
X-Google-Smtp-Source: ABdhPJyYrsUyRfmq291yPNHnbdYsnP8wT1z3NJGiCNixq9xW5zmfZftU0zrdA7bpNKarojxSUOU1sTu4xvwdW3SopAw=
X-Received: by 2002:a17:906:3486:: with SMTP id g6mr6739382ejb.71.1632420730083; Thu, 23 Sep 2021 11:12:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 23 Sep 2021 19:11:58 +0100
Message-ID: <>
Subject: Re: WGLC for Datagram Extension
To: Spencer Dawkins at IETF <>
Cc: QUIC WG <>, QUIC WG Chairs <>
Content-Type: multipart/alternative; boundary="000000000000bd9e4f05ccad915a"
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 18:12:17 -0000

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.


[1] -