[Masque] Comments on draft-pauly-masque-quic-proxy-01.txt

[Eric Rescorla <[e-mail]>]

Hi folks,

I've reviewed this document. At a high level, I'm unconvinced of the
requirements that lead to this design. I agree that QUIC in QUIC
is going to be common, but ISTM that

First, the Forwarded mode. I have two concerns here:

1. The general thrust of QUIC is to encrypt everything and having the
   non-handshake data in the clear goes against that. It is also much
   more difficult to analyze.

2. This document offers performance as the reason for forwarding mode,
   but I think we should be quite suspicious of such claims without
   strong evidence. The cost of symmetric encryption and decryption in
   modern systems is extraordinarily low [0] especially with hardware
   support, so removing the encryption seems unlikely to materially
   change the performance profile of most proxies.


Second, I'm not really convinced of the need to reuse local host/port
values. We have plenty of experience with TCP proxies that use a
separate port for each connection (this is, after all, what a CDN is
on the back end), and AFAIK that works out mostly OK. You don't
really explain why this is necessary, but I can imagine two
reasons:

1. Port scarcity -- this seems like mostly an IPv4 issue, as you can
   use IPv6 to have an arbitrary number of addresses.

2. Implementation issues around having multiple sockets open -- this
   seems like something that is fixable at the OS level (and again,
   we'll want to for QUIC CDNs), so we don't need to add protocol
   machinery.


Given that much of the complexity of this proposal comes from these
two requirements, ISTM that they require fairly close examination.

If we were to relax both requirements, it seems to me that we could
have a much simpler protocol which was basically QUIC-specific header
compression. I can imagine a number of different ways to implement
this, including pre-registration (the sender tells the receiver about
CIDs in advance) or notification (the receiver tells the sender "I now
know CID X and you can compress it with label Y"). Note that we could
probably just fold such a compression scheme into whatever (if
anything) we did for IP header compression.

If we only relax the forwarding requirement, then we would still
need some mechanism to mux multiple clients on the same host/port
quartet. I can imagine a number of angles here:

1. The design you have in which the client has to pre-register
   each receiving CID.
2. A design in which the proxy provides part of the CID or
   tells the client how to construct them. This would have
   the advantage that the proxy never told the client "no",
   which simplifies the client logic [1].
3. Require the clients to use high entropy CIDs (made easier
   with header compression) and just assume that conflicts
   are errors.

-Ekr

[0] It's quite old, but see:
https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

[1] And testing, as CID collisions will be very rare.