Re: WGLC for Datagram Extension

Christian Huitema <> Fri, 17 September 2021 01:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A53983A14DB for <>; Thu, 16 Sep 2021 18:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GoQJawAjY9iX for <>; Thu, 16 Sep 2021 18:24:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B9EA3A14E3 for <>; Thu, 16 Sep 2021 18:24:52 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1mR2cT-000Eos-Vh for; Fri, 17 Sep 2021 03:24:51 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4H9bpl23ZSz9sV for <>; Thu, 16 Sep 2021 18:24:47 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1mR2cR-0001Jn-5E for; Thu, 16 Sep 2021 18:24:47 -0700
Received: (qmail 31001 invoked from network); 17 Sep 2021 01:24:46 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 17 Sep 2021 01:24:46 -0000
Subject: Re: WGLC for Datagram Extension
To: Tommy Pauly <>, Martin Thomson <>
References: <> <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Thu, 16 Sep 2021 18:24:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCDFZ KvVMIy06iZX7sqO/SuPmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaqlHdH9stIYSUOP2ajLGtTxQ6V51u76v35b1wNe/MvdKAGdwU TZKlze5ERymXAD3v2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NaP2gA77cO7WeI9Ftai6fuqPzQQlKIV+L7fcVy/4+mAhq LulSsyh2REG6HjP6FqcODRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuSW8D9t0kz0vlag+LRt89q4F8V7nVxi9dEgodSNSquwWmyuLfHqAnAj7rgKH7+eCmm3MBN SiDME4ulzFaJaA23x1ShcA6Xvva2QAVEjpqzANap+28aWyCRVT7YkY7LckVczD9d0PFsgWZftdod 1HY/i713qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF
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, 17 Sep 2021 01:24:58 -0000

The way I understand it, we want to say that QUIC makes no effort to 
partition the space of datagrams into subcategories. Applications send 
and receive datagrams, and the conceptual API is, "here is a datagram 
that should be sent or just arrived on this QUIC connection". I 
application want to treat some datagrams as duck calls and some other 
datagrams as music packets, they can do that, but they have to do it 
themselves by decorating the datagrams appropriately. And whether they 
do that using stream IDs or packet codes or sequence numbers is not 
QUIC's business.

On 9/16/2021 5:05 PM, Tommy Pauly wrote:
> Agreed that the word “strongly” can simply be removed.
> Applications using QUIC can choose to associate particular datagrams with data sent on a stream—like HTTP/3 choosing to add a value calculated based on stream IDs into the payload of the DATAGRAM frame—but such associations do not belong to the transport protocol.
> <>
> Thanks,
> Tommy
>> On Sep 16, 2021, at 4:48 PM, Martin Thomson <> wrote:
>> On Fri, Sep 17, 2021, at 07:00, Eliot Lear wrote:
>>>> DATAGRAM frames belong to a QUIC connection as a whole, and are not
>>>> strongly associated with any stream ID at the QUIC layer
>>> What does "strongly associated" mean in this context?  Apologies if this
>>> is well trodden ground.
>> This is unfortunately so well-trodden that this text was added without consideration for people who weren't involved in the trampling process.
>> I think that "strongly" can be struck here, it's working too hard.  And smart people will latch onto it.
>> Context:
>> When we use DATAGRAMs in HTTP (and likely in other contexts) there will be a need to bind each DATAGRAM to a (request) stream.  That's necessary to ensure that flows of DATAGRAMs can be routed by gateways and the like along with the stream.  There were lots of debates about how to manage that binding and the layer at which it would be documented.  This text is likely intended to record the conclusion that this document definitely isn't where that sort of binding occurs, but for someone without that history.  It doesn't really achieve that though and because it doesn't need to (why would you think that any association exists?), it ends up being distracting.