Re: [Masque] Updated proposed charter text

[Lucas Pardue <[e-mail]>]

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]. 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.

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

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

>
>
> On Mon, Apr 6, 2020 at 10:24 AM Mirja Kuehlewind <
> [e-mail]> wrote:
>
>> 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]> wrote:
>>
>>
>>
>> On Mon, Apr 6, 2020 at 8:43 AM Mirja Kuehlewind <mirja.kuehlewind=
>> 40ericsson.com@dmarc..ietf.org <[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
>>
>>
>>
>>
>>
>>