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

> On Jun 24, 2020, at 6:28 PM, Ben Schwartz <bemasc@google.com> wrote:
> 
> 
> 
> On Wed, Jun 24, 2020 at 5:33 PM David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>> 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.


Thanks,
Eric



> 
> David
> 
> On Wed, Jun 24, 2020 at 11:30 AM Ben Schwartz <bemasc@google.com <mailto:bemasc@google.com>> 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 <mnot@mnot.net <mailto:mnot@mnot.net>> 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 <mnot@mnot.net <mailto:mnot@mnot.net>> 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. <https://datatracker.ietf.org/wg/masque/about/ <https://datatracker.ietf.org/wg/masque/about/>>.
> > 2. <https://datatracker.ietf.org/wg/webtrans/about/ <https://datatracker.ietf.org/wg/webtrans/about/>>.
> > 3. 'An Unreliable Datagram Extension to QUIC', <https://tools.ietf.org/html/draft-ietf-quic-datagram <https://tools.ietf.org/html/draft-ietf-quic-datagram>>.
> > 4. <https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram <https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram>>.
> > 5. <https://github.com/httpwg/http-core/issues/44 <https://github.com/httpwg/http-core/issues/44>>.
> > 
> > --
> > Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
> > 
> > 
> 
> --
> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
> 
>