Re: [Masque] Proposed draft charter

[Mirja Kuehlewind <[e-mail]>]

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.

==================