Re: HTTP proposal for UDP proxying: HELIUM

On Tue, Jul 10, 2018 at 7:48 AM Mirja Kühlewind <
mirja.kuehlewind@tik.ee.ethz.ch> wrote:

> Hi Ben,
>
> thanks for the writing this down. I find especially the congestion control
> use case interesting. It’s a cool idea to provide timing information from
> the proxy to the client such that the delay (variation) between the proxy
> and destination can be estimated as input for congestion control. However,
> in many cases I would assume that the bottleneck lies between the proxy and
> the client? Or what are the assumption there?
>

HELIUM is intended to run over a congestion controlled "substrate" between
client and proxy.  This means there are two congestion control contexts:
one between client and proxy, and one between the client and destination
(through the proxy).  As you know, when the client-proxy link is congested,
this can lead to classic "TCP over TCP" performance problems.  My
understanding is that the client-proxy congestion control converts loss
into delay, and this highly variable delay interferes with the inner
context.

It seems to me that we might be able to ameliorate these problems if we can
get the inner congestion control to ignore the client-proxy link, and only
apply to the proxy-destination link.  Specifically, by observing (a)
proxy-destination delay, (b) proxy-destination packet loss, and (c)
backpressure from the client-proxy link, I think we could produce a highly
performant inner congestion control.  For a delay-based inner congestion
control, it might be sufficient to replace the local packet arrival
timestamps with the timestamps from HELIUM "inbound" messages.

I apologize if this is unclear.  I'm not an expert on congestion control.

Also a completely different question: I think one part of the initial ideas
> was to remove dependencies on TCP. However, web sockets usually also runs
> over TCP, right? Can you further explain your choice of web sockets as
> framing protocol?
>

Yes, WebSockets run over TCP.  (Technically, if you
combine draft-ietf-httpbis-h2-websockets with HTTP/QUIC you can run them
over UDP but you'll still have in-order delivery.)  I chose WebSocket
because _if_ HELIUM is running over TCP, then WebSocket seems like the
easiest way to get all the substrate features we need and integrate easily
with HTTP.

I would like to have a path forward where HELIUM can have out-of-order
delivery when running over QUIC.  One way this could happen would be if
WebSocket over QUIC is extended to offer out-of-order semantics, which is
something I've heard proposed.  Another way would be to abandon WebSocket
and use Lucas's proposed new HTTP/2 frame type for HELIUM, which would
extend naturally to out-of-order delivery in HTTP/QUIC.

Of course, this is not really a completely different question from the one
above.  An in-order substrate (like TCP) has different implications for the
inner congestion control than an out-of-order substrate.


> Thanks!
> Mirja
>
> P.S.: HIP might also not be the best acronym as already taken by RFC7401
> which can be confusing.
>

Thanks, I didn't know about that.  Suggestions welcome.


>
> > On Mon, 25 Jun 2018 16:43 PM Ben Schwartz <bemasc@google.com> wrote:
> > Hello HTTPBIS,
> > In a thread a few months ago [1], there was call for interest in
> extending HTTP proxying (e.g. HTTP CONNECT) to support UDP traffic,
> motivated by the growth of QUIC and WebRTC. Since then, the people who
> expressed interest have brainstormed some possible use cases and solutions.
> I am emailing to present the first of what I hope will be several drafts
> that we will present on the topic and discuss at IETF 102. This draft
> presents one possible solution enabling HTTP proxying of UDP.
> > https://www.ietf.org/id/draft-schwartz-httpbis-helium-00.txt
> > Title:
> >   Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM)
> > Abstract:
> >   HELIUM is a protocol that can be used to implement a UDP proxy, a VPN,
> or a hybrid of these. It is intended to run over a reliable, secure
> substrate transport. It can serve a variety of use cases, but its initial
> purpose is to enable HTTP proxies to forward non-TCP flows.
> > Questions and reviews much appreciated.
> > --Ben Schwartz
> > [1] https://www.ietf.org/mail-archive/web/httpbisa/current/msg30667.html
>