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

Eric Kinnear <> Thu, 25 June 2020 01:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D3C33A1228 for <>; Wed, 24 Jun 2020 18:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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 i7GR03ztGbxC for <>; Wed, 24 Jun 2020 18:51:46 -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 C6F8E3A0D2A for <>; Wed, 24 Jun 2020 18:51:46 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1joH0j-0007ks-0a for; Thu, 25 Jun 2020 01:49:05 +0000
Resent-Date: Thu, 25 Jun 2020 01:49:05 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1joH0h-0007k2-E7 for; Thu, 25 Jun 2020 01:49:03 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1joH0e-0006ZG-V4 for; Thu, 25 Jun 2020 01:49:03 +0000
Received: from pps.filterd ( []) by ( with SMTP id 05P1jYS0047631; Wed, 24 Jun 2020 18:48:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=RnAwCaL7kVbPFTXx6lETqglvf5ufnyLHsSCNkYc+YX0=; b=q3ySV4BQGSXuwhdiwGIStGAWXIheK5HS4yTsTi3YpwtV+WAyJocMaB55h8ba6U/UEGQv FobQXYIY/+WKR3G1Mh9Jm2IrVN+MnNKynfJ1fu0lugyQb3Y1Zs2Ba8tV0Rqt9znAVzfc Yp1cnzxiwTqem+1fL13CpX0AM3qxAJ7dMw8OlGYg52ayOQ/RDZK1CUk9IrAEwKf0dT0Z FcWlwxAKqsgPK86wp5Ds2ZLXt3ZIH0KEijC8hpWeHO0YTPgxHtcCGP5UPDb3eQtD9VSF S3r4dVkE4XRAhG8OCbul5YyCHa/g0W/2UZDPfLb9T7SLxsktw408dWP4MezESP5Avvr/ 8A==
Received: from ( []) by with ESMTP id 31uurwpx0n-19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Jun 2020 18:48:39 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPS id <>; Wed, 24 Jun 2020 18:48:37 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) id <>; Wed, 24 Jun 2020 18:48:37 -0700 (PDT)
X-Va-T-CD: 4b0bfa8f1a6b3ccd2c5faa4ae3785f0b
X-Va-E-CD: dd7afce3cb18ae116b1e1eaa8cda6d82
X-Va-R-CD: 1a2410d7b03cb60ecfa034465e7e1efe
X-Va-CD: 0
X-Va-ID: 8592fea8-30bd-4a22-a512-33d535f7c8b0
X-V-T-CD: 4b0bfa8f1a6b3ccd2c5faa4ae3785f0b
X-V-E-CD: dd7afce3cb18ae116b1e1eaa8cda6d82
X-V-R-CD: 1a2410d7b03cb60ecfa034465e7e1efe
X-V-CD: 0
X-V-ID: bb11d16b-9732-4a1b-96e9-14cc0c8cb608
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-24_19:2020-06-24,2020-06-24 signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Mar 12 2020)) with ESMTPSA id <>; Wed, 24 Jun 2020 18:48:37 -0700 (PDT)
From: Eric Kinnear <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_DBD0BC78-1C24-45C7-A473-B1EC9E7ED350"
MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 24 Jun 2020 18:48:36 -0700
In-reply-to: <>
Cc: David Schinazi <>, Mark Nottingham <>, " Group" <>
To: Ben Schwartz <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.687 definitions=2020-06-24_19:2020-06-24,2020-06-24 signatures=0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1joH0e-0006ZG-V4 7a87d2be88baf2c86cb0e4e721339c16
Subject: Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Archived-At: <>
X-Mailing-List: <> archive/latest/37824
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Jun 24, 2020, at 6:28 PM, Ben Schwartz <> wrote:
> On Wed, Jun 24, 2020 at 5:33 PM David Schinazi < <>> wrote:
> @Ben I don't think reusing extended CONNECT is an option for CONNECT-UDP, because of backwards compatibility: if a proxy were to receive a CONNECT request with ":protocol" set to "udp", it might ignore the ":protocol" header and create a TCP connection to the host and port instead of UDP.
> I don't think that's true.  Support for :protocol has to be signaled at startup with SETTINGS_ENABLE_CONNECT_PROTOCOL, so it cannot be sent to a server that does not understand it.  RFC 8441 also says "On requests bearing the :protocol pseudo-header field ... the server MUST NOT create a tunnel to the host indicated by the :authority as it would with a CONNECT method request that was not modified by this extension.", so it's quite explicit that extended-CONNECT does not silently fall back to old-fashioned CONNECT.
> I think it's important that CONNECT-UDP to a non-supporting proxy fail instead of fallback to TCP.
> I believe Extended-CONNECT gives you this behavior.

We used Extended-CONNECT in one of the iterations of the WebTransport drafts in almost exactly this way, and I do think it was not un-reasonable if only looking at the text as written. 

However, as Mark mentioned general direction over implementation mechanism at the moment, I think one of the main questions around H3 datagrams is how they differ from QUIC datagrams and whether that’s something that should have semantic meaning in HTTP. 

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.

That doesn’t lead me towards any objection to folding in H3 datagrams and CONNECT-UDP, although I would echo David when he says:
>> My main concern is that if we come up with a new HTTP mechanism that would like to use datagrams but couldn't be solved by extending CONNECT-UDP, then we'd be in a bind because it might be impossible to use both CONNECT-UDP and this new mechanism over the same connection.


> David
> On Wed, Jun 24, 2020 at 11:30 AM Ben Schwartz < <>> wrote:
> One direction I think could be interesting is to embrace the Extended CONNECT as used by WebSocket-H2 (RFC 8441).  If we define ":protocol = tcp" as a synonym for the old-fashioned CONNECT, then ":protocol = udp" could represent the basic MASQUE case nicely, and ":protocol = webtransport" might go naturally as well (if we can't reuse ":protocol = websocket").
> The combination of :protocol and transport (H3 vs. H2) might be sufficient to indicate whether datagrams are allowed.
> On Tue, Jun 23, 2020 at 4:49 AM Mark Nottingham < <>> wrote:
> My personal .02 on this (and I'd be very curious to hear others' reactions) --
> We don't have a good track record of creating extensions or new capabilities that don't map into HTTP semantics. Server Push is probably the poster child here. As such, creating a version-specific extension for DATAGRAMs without mapping them into a method (or whatever) seems like it's leaving an attractive nuisance around; how will it show up in APIs? How will it interact with intermediaries? Etc.
> We also don't have a lot of precedent for a HTTP version-specific extension that does something completely separate to the HTTP interaction that's happening on the connection. I'm not sure that it would be something we want to encourage.
> All that said, we're not the protocol police; I don't think we should _stop_ this, but I do think that if we want this to succeed, it might work better as something packaged together with CONNECT-UDP (or however it gets expressed in HTTP).
> AIUI the one big argument for factoring it out into a separate draft is that MASQUE might want to use it *without* a method (etc.) for IP proxying. So that might be a conversation to have (although that use case has been delayed, I think).
> Another potential consumer could be a header on CONNECT (or even other methods?) that allows unreliable delivery but degrades gracefully to reliable delivery on hops that don't provide it. Even then, it seems like such a spec could reference the wire formats, etc., in CONNECT-UDP once that's defined.
> Overall - I have a preference for this to be rolled into a CONNECT-UDP (or similar) spec, but can live with it as a separate doc, provided that some thought is put into warning potential users about some risks.
> What do other folks think?
> > On 23 Jun 2020, at 9:40 am, Mark Nottingham < <>> wrote:
> > 
> > Hi all,
> > 
> > The new MASQUE[1] and WEBTRANS[2] working groups both wish to define new protocols using QUIC DATAGRAM frames[3] that are not conveying (existing) HTTP semantics, but are intended to be usable over (at least some versions of) a HTTP connection.
> > 
> > MASQUE's purpose is to proxy UDP and potentially IP (like a VPN) over a HTTP/3 connection. For WEBTRANS, the purpose is to create a browser-exposed, WebSocket-like protocol that allows unreliable delivery (which may also use CONNECT-UDP). These summaries are just my understanding; for a more complete picture, see the respective charters and related WG discussion.
> > 
> > It's not yet clear how or even if these protocols will map into HTTP semantics. Some have proposed something like a CONNECT-UDP method; others seem to favour negotiating a new protocol using SETTINGS or a similar version-specific mechanism directly, avoiding the definition of any generic HTTP semantics.
> > 
> > So far, the most concrete proposal we have is draft-schinazi-quic-h3-datagram,[4] which defines how QUIC DATAGRAM frames are surfaced in HTTP/3 without any mapping them into generic HTTP semantics (like a method, status code, header, etc.). Thus, a specification using them has the choice of defining a generic HTTP extension (like CONNECT-UDP, mapping them into HTTP semantics) or a version-specific extension(like SETTINGS, bypassing generic semantics).
> > 
> > Before these groups get too far down the road, we have an opportunity to give them some guidance about how to extend both HTTP's semantics overall, and specific versions of HTTP -- keeping in mind recent core discussions.[5] 
> > 
> > The most relevant question is whether new, non-HTTP protocols on a HTTP connection should be bootstrapped by generic HTTP semantics (e.g., a method), version-specific semantics (e.g., SETTINGS), or something else. 
> > 
> > There's also a question as to whether something like draft-schinazi-h3-datagram is the right approach, or whether it should also include generic HTTP semantics "bundled in."
> > 
> > Do folks have any thoughts about this? 
> > 
> > Cheers,
> > 
> > 
> > 1. < <>>.
> > 2. < <>>.
> > 3. 'An Unreliable Datagram Extension to QUIC', < <>>.
> > 4. < <>>.
> > 5. < <>>.
> > 
> > --
> > Mark Nottingham <>
> > 
> > 
> --
> Mark Nottingham <>