Subject: [Masque] Scope

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Mar 2020 16:27:44 -0700

Following up to my point on the call.

I think the MVP here is basically CONNECT for {UDP, TCP} and maybe IP, and
I don't think we should build protocol-specific mechanisms for QUIC, DNS,
etc. until we have seen how the generic CONNECT thing shakes out. I'm happy
to debate that during the WG, but the point is that the charter text says
otherwise so we should remove that text (or hash it out now).

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Mar 2020 16:31:42 -0700

Just to follow up: I do think that this is in general a good thing to build
and something I would have a use for.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 Mar 2020 16:53:01 -0700

On 3/24/2020 4:31 PM, Eric Rescorla wrote:
> Just to follow up: I do think that this is in general a good thing to
> build and something I would have a use for.
>
> -Ekr
>
>
> On Tue, Mar 24, 2020 at 4:27 PM Eric Rescorla <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I think the MVP here is basically CONNECT for {UDP, TCP} and maybe
>     IP, and I don't think we should build protocol-specific mechanisms
>     for QUIC, DNS, etc.. until we have seen how the generic CONNECT
>     thing shakes out. I'm happy to debate that during the WG, but the
>     point is that the charter text says otherwise so we should remove
>     that text (or hash it out now).
>

I agree that "TCP CONNECT" and "UDP CONNECT" would be easy to define,
and that UDP CONNECT would allow implementation of QUIC-in-QUIC. If you
do that, there will however be three issues:

1) Overhead. You will end up repeating the Quic header in every UDP
packet. Adding some kind of header compression would reduce overhead.

2) Multiplexing. The simple UDP CONNECT requires to have a single five
tuple reserved for a UDP connection. It would be nice if we could
multiplex a lot of proxied UDP connections on a single port.

3) Proxied servers. This requires pretty much the entire work specified
in Martin Duke's draft on managing incoming connections in server farms.

The first 2 issues are optimization issues, and they can certainly be
deferred -- no early optimization. The proxied server may or may not be
the same protocol.

-- Christian Huitema