[dispatch] HTTP, QUIC, proxies, and HELIUM

[Ben Schwartz <[e-mail]>]

At the DISPATCH session in Montreal, the chairs suggested reaching out to
this list with a taxonomy of the problems that HELIUM is trying to solve.
Here’s a quick attempt at that. (For more information, see Lucas Pardue’s
“HiNT” draft and slides.)

The starting point is the observation that HTTP/QUIC can forward HTTPS
(with HTTP CONNECT), but cannot forward HTTP/QUIC (because CONNECT is
TCP-only).  The baseline requirement, then, is to enable an HTTP/QUIC
server to forward a QUIC connection.

Although this is the starting use case, it is not the only property that
one might desire.  Some additional goals that we’ve considered include

   -

   extending the supported contents to include WebRTC, DNS, or even
   arbitrary IP
   -

   extending the supported substrates to include HTTP/2 or even HTTP/1.1
   -

   extending the performance goals (beyond merely “functional”) to include
   minimizing setup latency, or even enhancing congestion control performance
   on difficult paths (e.g. high loss, high latency, or variable latency)


HELIUM attempts to cover all of these extended goals, at least to some
extent, which results in an unconventional, extremely flexible design.

Some participants asked for sketches of solutions with reduced scope that
enable a more familiar approach.  Here are a few:

   -

   If we require that the proxied contents are end-to-end congestion
   controlled (e.g. only QUIC is allowed), then the substrate could safely
   disable congestion control (and reliability and flow control) for those
   packets.  This would require some modifications to HTTP/QUIC (creating a
   DTLS-like mode) but would make congestion control stability much easier to
   achieve.
   -

   If we require that contents are plain UDP only (no IP options like DSCP
   or TTL) and exclude support for server-like behavior, then we can use a
   protocol that maps 1:1 with TURN, for familiar semantics.
   -

   If we require that the server has full “raw IP sockets” access, then we
   can remove all mention of UDP and simply define a VPN-type IP tunnel.


In my view, a protocol that solves one of these restricted problems would
still be a worthwhile advance.

Finally, I’ll note that the level of performance achievable with HELIUM’s
current design is not entirely clear, due to the worrying presence of
layered congestion control.  A more ambitious approach to performance
enhancement might allow the proxy to peek into the content’s congestion
control information. This could enable optimizations like retransmission
from the middle (in both directions) in the event of packet loss.


My question to DISPATCH participants is: what would it take for a solution
to be useful to you?


--Ben