Re: [Masque] Proposed draft charter

[Spencer Dawkins at IETF <[e-mail]>]

I'm finally reading this charter, as opposed to looking at the words ...
mostly, this looks fine to me.

A couple of things inline.

On Thu, Feb 6, 2020 at 6:05 AM Eric Kinnear <ekinnear=
[e-mail]> wrote:

> Awesome, thanks all for the feedback!
>
> Updating with the changes proposed by Ekr and Lucas, thanks for the great
> suggestions.
>
> ===============
>
> Many network topologies lead to situations where transport protocol
> proxying is
> beneficial. For example, proxying enables endpoints to communicate when
> end-to-end connectivity is not possible and can apply additional encryption
> where desirable (such as a VPN).
>
> QUIC is a good candidate protocol for tunneling these types of traffic, as
> QUIC
> provides secure connectivity, multiplexed streams, and connection
> migration.
> Further, HTTP/3 supports an established request/response semantic that can
> be
> used to set up and configure services.
>

The definition of QUIC as practiced in 2020 is "HTTP/3 over QUIC", although
we certainly see proposals for other application protocols over something
QUIC-like. Would something like

"HTTP/3, carried over QUIC, is a good candidate protocol for tunneling
these types of traffic, as QUIC
provides secure connectivity, multiplexed streams, and connection migration.
Further, HTTP/3 supports an established request/response semantic that can
be
used to set up and configure services."

make that clearer?


> Using QUIC as a tunneling technology allows for proxying of both reliable
> stream
> (TCP) and unreliable datagram (UDP) flows. For stream flows, QUIC streams
>

I'm a little confused here, about whether (HTTP/3-)QUIC is also in scope as
a proxied protocol. Does everyone else know whether it is, and I'm just
catching up?

Best,

Spencer


> provide reliable in-order delivery across the client-proxy link. QUIC
> datagrams
> provide for unreliable data transmission, which allows for transporting
> UDP and
> other unreliable flows via a proxy without introducing potentially
> redundant or
> unnecessary recovery mechanisms. In addition, QUIC can carry both types of
> flows
> over the same connection while taking advantage of a unified congestion
> controller.
>
> This working group will work on MASQUE (Multiplexed Application Substrate
> over
> QUIC Encryption), a framework that allows concurrently running multiple
> proxied
> flows inside a QUIC connection. The MASQUE framework will specify a
> signaling
> protocol that is used between the endpoint(s) and the MASQUE server to
> negotiate
> proxy services that establish tunneled connectivity. The initial
> functionality
> will be limited to client-initiated proxy tunnels. The WG may subsequently
> recharter to consider other applications.
>
> Proxy services that extend the signaling of the base MASQUE protocol can be
> adopted by the group by creating a new milestone with AD review.
>
> If MASQUE requires any extensions to existing protocols, the group will
> coordinate closely with the respective group responsible for maintaining
> that
> protocol, such as the HTTPBIS, QUIC, or TLS working groups.
>
> ===============
>
>
> Thanks,
> Eric
>
>
>
> On Feb 4, 2020, at 5:23 PM, Mirja Kuehlewind <
> mirja.kuehlewind=[e-mail]> wrote:
>
> Hi Eric,
>
> thanks for narrowing this down. The proposed text below looks like a good
> starting point for a working group!
>
> Mirja
>
>
> *From: *Masque <[e-mail]> on behalf of Eric Kinnear <
> ekinnear=[e-mail]>
> *Date: *Tuesday, 4. February 2020 at 16:30
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *Re: [Masque] Proposed draft charter
>
> Hi all,
>
> There’s been some good discussion on this thread, which has led to some
> potential improvements in the draft charter.
>
> Here’s some proposed text which tightens things up quite a bit and tries
> to clarify many of the parts that caused concern. Thoughts and feedback
> welcome!
>
> Thanks,
> Eric
>
>
>
> ==================
>
> Many network topologies lead to situations where transport protocol
> proxying is
> beneficial. For example, proxying enables endpoints to communicate when
> end-to-end connectivity is not possible and can apply additional encryption
> where desirable (such as a VPN).
>
> QUIC is a good candidate protocol for tunneling these types of traffic, as
> QUIC
> provides secure connection establishment, multiplexed streams, and
> connection
> migration. Further, HTTP/3 provides an existing request/response syntax
> that can
> be used to set up and configure services.
>
> Using QUIC as a tunneling technology allows for proxying of both reliable
> stream
> (TCP) and unreliable datagram (UDP) flows. For stream flows, QUIC streams
> provide reliable in-order delivery across the client-proxy link. QUIC
> datagrams
> provide for unreliable data transmission, which allows for transporting
> UDP and
> other unreliable flows via a proxy without introducing potentially
> redundant or
> unnecessary recovery mechanisms. In addition, QUIC can carry both types of
> streams over the same connection while taking advantage of a unified
> congestion
> controller.
>
> This working group will work on MASQUE (Multiplexed Application Substrate
> over
> QUIC Encryption), a framework that allows concurrently running multiple
> proxied
> flows inside a QUIC connection. The MASQUE framework will specify a
> signaling
> protocol that is used between the endpoint(s) and the MASQUE server to
> negotiate
> proxy services that establish tunneled connectivity. The initial
> functionality
> will be limited to client-initiated proxy tunnels. The WG may subsequently
> recharter to consider other applications.
>
> Proxy services that extend the signaling of the base MASQUE protocol can be
> adopted by the group by creating a new milestone with AD review.
>
> If MASQUE requires any extensions to existing protocols, the group will
> coordinate closely with the respective group responsible for maintaining
> that
> protocol, such as the HTTPBIS, QUIC, or TLS working groups.
>
> ==================
>
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>