Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS

Lucas Pardue <> Thu, 25 June 2020 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7434E3A0FD3 for <>; Thu, 25 Jun 2020 12:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 oGfEb9ZfVSKg for <>; Thu, 25 Jun 2020 12:07:21 -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 44C053A0FD4 for <>; Thu, 25 Jun 2020 12:07:20 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1joXAi-0008QQ-EA for; Thu, 25 Jun 2020 19:04:28 +0000
Resent-Date: Thu, 25 Jun 2020 19:04:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1joXAf-0008Pe-N5 for; Thu, 25 Jun 2020 19:04:25 +0000
Received: from ([2a00:1450:4864:20::32d]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1joXAd-0004HD-Dj for; Thu, 25 Jun 2020 19:04:25 +0000
Received: by with SMTP id t194so7043508wmt.4 for <>; Thu, 25 Jun 2020 12:04:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=txxUq7llHMSLwrnBRSsd3aDIey3RWf8gloYLeu9PwEY=; b=kJvT/RzIWtw4zmKxqyWrad5hUj6flMMgRbRXOxBOVvwoyrBCi4+ePl3YlJDzN1xKVn Ubm/FlH1XiohCAAtoa6+f5Ne10UKtzQLzyg77tQ7RTFX7LZwAjObc1Bhiw4BAoRQMeGg ZIaGghNnLkBA2jHqEUTv0/mHgk1ivz3Yawehq3UbW55VqcfJ90JcSNkCO4yfpsVZNwG3 /+6yi/unebu/tij0r56vu3fpxC+fPoERiFnpqQgZDEo8PrKT5Mgtw4x8JztgbLGTjxVV CnlQyvtiqOt6FU68/gTLBYkYCwC+4IM4x0RunEonWGk8MO+BgGOHV5/o0dflHcBIdx7k 804w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=txxUq7llHMSLwrnBRSsd3aDIey3RWf8gloYLeu9PwEY=; b=SxEisN/FKTcTJcyXDKWiXVgFABBfvKtjAQGpuhReQLANvG9W4208JWBsiVsP2YKvFJ Gi2OUmnkioCwjgtQBSgD2xROXSNsS4qTEvpv2gOGKwm9WScDOv+xl1U33ERksrIukc0U Xqnz21U0G8U7szcTslhx2JhEqKKAx5MUQLnsnF9d3HekClOFMhZWCCU2YZbhXjihtfiU gCEF2Pv3+qgcjLwH/4BPflXz1JVgC1mqrvIdBkSyacrn4rsmtDRNUoKyL8dpl0UUASMm agCamkNX4pIf57tqixoz167z1z09gQ2LFZxOGIdDsYPEdV/UKgp3lcWcBnocNypyEAvN w90w==
X-Gm-Message-State: AOAM531VEdBTGdgBP774uvzR2mSpmf5Q4ItFeqDDinOVrJ7PiWHxx4G/ zA6X4jztXCaDCTtbfkJnG04kdQRH5Eg369fd3dA=
X-Google-Smtp-Source: ABdhPJyF7p0lUAhCVuejUsTCrx3bcpu6AQtVkPrSdJEO2/IkbxxO/S1g8txd+a7w+j4hMvEwir30K86HHKaxHt6uiBM=
X-Received: by 2002:a7b:cb98:: with SMTP id m24mr5002240wmi.98.1593111851577; Thu, 25 Jun 2020 12:04:11 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Thu, 25 Jun 2020 20:04:00 +0100
Message-ID: <>
To: Eric Kinnear <>
Cc: Ben Schwartz <>, David Schinazi <>, Mark Nottingham <>, " Group" <>
Content-Type: multipart/alternative; boundary="00000000000000363b05a8ed42d5"
Received-SPF: pass client-ip=2a00:1450:4864:20::32d;;
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Scan-Sig: 1joXAd-0004HD-Dj 00d66dc6adfa0489f68d6891a0c26612
Subject: Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Archived-At: <>
X-Mailing-List: <> archive/latest/37827
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Lots a food for thought in this thread, I'll pick on one aspect for now:

On Thu, Jun 25, 2020 at 2:52 AM Eric Kinnear <> wrote:

> I know that one of the reasons to split out into H3 datagrams was to have
> a flow ID present to allow multiple different flows of data to coexist, and
> there was quite lively discussion at the time which was fairly split as to
> the utility vs. dangers of such flow IDs.
> The biggest questions in my mind in that area are: How much do we care
> about sharing an HTTP connection that is using HTTP semantics on some
> streams with these other frames? And does that, in turn, mean that we need
> to define HTTP semantics for the datagrams (H3 or H2 or otherwise)?
> My personal gut reaction would be (a) yes, we do care and (b) probably not
> necessary as long as we can correctly demux what information is intended
> for what extension/protocol living at the other end.

Over on the datagram spec repo [1] we are still discussing the topic of
flow IDs. From that I've been more deeply considering my implementation of
QUIC DATAGRAM and looking ahead to HTTP/3 DATAGRAM, especially how that
layering would work and the API presented by the layers*. So, devil's
advocate, I'm wondering why we need the abstract notion of a flow ID in
HTTP/3 - draft-schinazi-quic-h3-datagram-03 [2] defines the requirement
"Implementations of HTTP/3 that support the DATAGRAM extension MUST provide
a flow identifier allocation service.", which as a library implementer I
struggle to satisfy. It also offers little guidance on things like security
considerations or DoS analysis, which is really where a common definition
would help because it would force the issue of determining if we need to
communicate things such as limiting the number of total concurrent flows,
how to retire a flow etc, how to report limit violations/error, how to
gracefully close an HTTP/3 connection with active flows etc. The closest
parallel for me is HTTP/3's management of server push via push ID, it fixes
an accounting loophole that exists in HTTP/2 and provides explicit guidance
for use with GOAWAY. If HTTP/3 DATAGRAM were to stay generic then IMO it
needs to think about some factors like that. However, if the use of
DATAGRAMs is always required to be defined alongside by an HTTP semantic
then it might be able to play by the rules of that semantic; for example,
consider that we define a tight binding between DATAGRAM and CONNECT-UDP -
an implementation could apply the security considerations and resource
management that it already does for HTTP requests. Thus the number of
concurrent flows is bound by the number of concurrent requests and flow ID
fate fate is tied to request ID fate, which is tied to connection fate.
Furthermore it would support the carriage of per-flow limits expressed as

So to address the OP, I think we need to fully consider semantics up front:
either true version-independent HTTP semantics or, as the QUIC charter
likes to call them version-specific semantics. The danger is not doing so
is that people start deploying things that we have to retroactively attempt
to describe e.g. "A payload within a CONNECT request message has no defined
semantics;   sending a payload body on a CONNECT request might cause some
existing implementations to reject the request"


* in quiche, we present both QUIC and HTTP/3 API layers and document how
applications are expected to use them when using one or both of the layers.

[1] -