Re: [Masque] Updated proposed charter text

[Mirja Kuehlewind <[e-mail]>]

Hi Lucas, hi Ekr,

see inline.

From: Lucas Pardue <[e-mail]>
Date: Monday, 6. April 2020 at 17:59
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



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.


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?

[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