Multiplexed Application Substrate over QUIC Encryption (masque)
|WG||Name||Multiplexed Application Substrate over QUIC Encryption|
|Area||Transport Area (tsv)|
|Personnel||Chairs||Dennis Jackson, Eric Kinnear|
|Area Director||Martin Duke|
Charter for Working Group
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 or to apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client's IP address from a target server. Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT is currently limited to TCP.
The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection. The group has specified CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this functionality. MASQUE leverages the HTTP request/response semantics, multiplexes flows over streams, uses a unified congestion controller, encrypts flow metadata, and enables unreliable delivery suitable for UDP and IP-based applications.
The MASQUE working group will now develop HTTP extensions, which might be specific to the HTTP version, to the core client-initiated CONNECT-UDP and CONNECT-IP functionality. Services that a proxy initiates without any prompt from a client are out of scope.
Exercising the extension points defined by CONNECT-UDP and CONNECT-IP helps to make it easier to support new use cases or accommodate changes in the environment in which these protocols are deployed. The initial set of extensions will be in support of UDP listening, and CONNECT-UDP proxying optimizations when the UDP traffic is QUIC. Additional extensions that provide missing functionality, improve performance, or otherwise ease deployability for use cases may be adopted where there are multiple implementation and/or deployment proponents. The intended status is Standards Track, but the WG may downgrade if it believes that is appropriate for the ultimate document maturity level.
Extensions to HTTP Datagrams will be coordinated with HTTPBIS. Extensions that solely relate to generic proxying functionality, and are not specific to the core MASQUE documents, are out of scope.
Specifying proxy server discovery mechanisms is out of scope. New congestion control and loss recovery algorithms are also out of scope. However, the working group will consider implications of tunneling protocols with congestion control and loss recovery over MASQUE proxies, and may issue recommendations accordingly.
The working group will consider how the protocols it defines might operate over versions of HTTP that use TCP rather than QUIC, for use when QUIC is unavailable. This might include defining alternative extensions specifically for use in these HTTP versions.
IP multicast is out of scope. Designs need not explicitly preclude multicast, but they will not focus on multicast-specific features.
Impacts on address migration, NAT rebinding, and future multipath mechanisms of QUIC are not anticipated. However, the working group should document these impacts, or those of any other QUIC developments, if they arise.
The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with ICCRG and TSVWG on congestion control and loss recovery considerations, and intarea for IP Proxying.
MASQUE is not intended to be a long-lived working group.
|Last||Submit an extension optimizing CONNECT-UDP to carry QUIC|
|Next||Submit an extension for UDP listeners|