Re: [Masque] Updated proposed charter text

[Mirja Kuehlewind <[e-mail]>]

Hi Lucas,

see below.

From: Lucas Pardue <[e-mail]>
Date: Monday, 6. April 2020 at 19:52
To: Eric Rescorla <[e-mail]>
Cc: Mirja Kuehlewind <[e-mail]>, Christopher Wood <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Masque] Updated proposed charter text

I think there is some philosophical difference and view of the layering here.
Another way to look at it is that we want to use the HTTP semantic over one QUIC connection to bootstrap proxied stream- or datagram-based flows within that connection[1].

[MK] Yes I think we agree here.

HTTP/3 is today the specification of HTTP over QUIC, and it uses the "h3" ALPN. It might be desirable to define a different HTTP over QUIC mapping, e.g. "masque", that uses the same serialization as HTTP/3 but includes some extra features, constraints etc.

[MK ]And I guess we will need to have some discussion about this in the working group. So coming back to the original point about the wording in the charter: I still think saying QUIC connection (as you just did above) would be more generic/correct and would also be more clear about allowing this discussion to happen in the working group rather than prematurely precluding it now.



This seems like a good point to consider BCP56bis[2] and decide where on the spectrum of HTTP/non-HTTP MASQUE falls.

Lucas

[1] Without specifying the same connection, one could imagine using an HTTP/3 connection to bootstrap a new QUIC connection that uses some other ALPN ID. I don't think that is what we want.
[2] https://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#used<https://protect2.fireeye.com/v1/url?k=7d7ed50c-21aadd4f-7d7e9597-86a1150bc3ba-fe685d39dbe6fef0&q=1&e=5f8eaa70-762d-4d24-ad87-cb1c21b4c56f&u=https%3A%2F%2Fhttpwg.org%2Fhttp-extensions%2Fdraft-ietf-httpbis-bcp56bis.html%23used>

On Mon, Apr 6, 2020 at 6:37 PM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:


On Mon, Apr 6, 2020 at 10:24 AM Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>> wrote:
Hi Lucas, hi Ekr,

see inline.

From: Lucas Pardue <[e-mail]<mailto:[e-mail]>>
Date: Monday, 6. April 2020 at 17:59
To: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Cc: Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>>, Christopher Wood <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Masque] Updated proposed charter text



On Mon, Apr 6, 2020 at 4:48 PM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

On Mon, Apr 6, 2020 at 8:43 AM Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc..ietf.org<mailto:[e-mail]>> wrote:
Hi Chris,

In draft-schinazi-masque-protocol I would say that the QUIC, UDP, and IP proxying services run directly on top of QUIC without any HTTP in between (HTTP is only used only for the negotiation part but not for the forwarding/multiplexing).

Philosophy aside, do we agree that these messages would be carried in QUIC Datagram frames (https://tools.ietf.org/html/draft-ietf-quic-datagram-00)?

[MK] Yes, for datagram-based flows. And QUIC stream frames for stream-based flows.

OK.

Therefore I think it would be more correct to actually change this one occurrence of HTTP3 back to  QUIC in the following sentence:

"The primary goal of this working group is to develop mechanisms that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside a HTTP/3 connection"

I'm not sure that this is right. If you use the H3 ALPN token and then use H3 to negotiate but also negotiate datagram, this seems like an H3 connection to me.

[MK] I guess it gets a bit philosophical now: If we would have an own ALPN token for masque (which is reasonable for some use cases) but still use the HTTP-based scheme as proposed in draft-schinazi-masque-protocol by POSTing for configuration parameters, would that still be H3?
Well, ISTM that if we are using H3 for negotiation, then we should be using the H3 ALPN token.

-Ekr



[MK] I mean I think we are aligned here what we want. I just don’t want to be over-restrictive in the charter by calling it there a H3 connection while calling it a QUIC connection would be fine as well.



-Ekr


I would find using "QUIC" in place of "HTTP/3" confusing. QUIC requires an authenticated negotiation of the application protocol and we use ALPN for that today. There is no mechanism to my knowledge that would allow the creation of just a QUIC connection, and I don't even think MASQUE requires that.

IMO it be more accurate for us to say, "The primary goal of this working group is to develop HTTP mechanisms that allow configuration of QUIC transport features inside an HTTP/3 connection, with the aim to concurrently run multiple proxied stream- and datagram-based flows."

[MK] I think we need more than just “configuration of QUIC transport features“ as the forwarding part itself and any operations needed for the forwarding part e.g. address translation or some kind of header compression are not a QUIC transport feature.

[MK] However basically asking you the same again: draft-schinazi-masque-protocol proposed a POST-based mechanism to exchange configuration parameter. Is that really a HTTP mechanism for you? For me that a new protocol that uses HTTP underneath.

Mirja