RE: HTTP proposal for UDP proxying: HELIUM

This is an interesting area of discussion.

Something I think worth mentioning is the concept on "fan out", or conversely, coalescing.

CONNECT is what I call a fixed tunnel mode, with the end-to-end tunnel always pointing at the same request-target (DNS or load balancing trickery can of course occur but ignore that). AIUI a client loading a web page consisting of assets on different origins will form multiple tunnels operating on independent TCP connections (or streams in the case of HTTP/2 or HTTP/QUIC) between client and proxy. These naturally have variable congestion control end-to-end, and may have some interesting combination more locally to the client. 

There seems no option for H2 connection coalescing in the above case, since the client is not responsible for performing DNS resolution but is responsible for creating the HTTP/2 over TLS session. The same applies for HTTP/QUIC session.

HELIUM permits a more agile approach, it is possible to multiplex messages to/from different destinations with the same client-to-proxy substrate association. Effectively the fan out is taking place  at the proxy. Congestion control in this case needs to factor in the multiplexing. The client could choose not to multiplex everything, HELIUM does expose IP and so could allow coalescing. There will be some interesting implementation choices here.

The above behaviours, when combined with a design goal of "traffic that does not stand out" would cause me to lean in favour of HELIUM over a non-WebSocket substrate, i.e. native H2 or HQ frames.

Lucas
________________________________________
From: Ben Schwartz [bemasc@google.com]
Sent: 11 July 2018 02:32
To: Martin Thomson
Cc: Mirja Kühlewind; HTTP Working Group
Subject: Re: HTTP proposal for UDP proxying: HELIUM

On Tue, Jul 10, 2018 at 8:04 PM Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On Wed, Jul 11, 2018 at 1:13 AM Ben Schwartz <bemasc@google.com<mailto:bemasc@google.com>> wrote:
> 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's possible that flow control is as much of a problem as congestion
control.  The end-to-end connection follows a longer path, and while
it might be subject to two pinch points, only one of those is real in
the sense that only one of them holds back the overall throughput.

The problem arises when the proxy needs to buffer in reaction to
congestion on the second part of either link; it then needs to exert
back pressure using flow control, or drop.  Dropping is easy in a
sense (or marking - where you might decide an ECN analogue is needed),
but that you might use flow control implies that you have buffering,
which is a great way to destroy latency.

We sort of pretend that we don't have these problems with CONNECT, and
let implementations deal with the consequences.  That's usually
performance degradation of a kind.

Yes, although it's generally good for throughput.

The question here is whether you
care to grapple with the problems, and do what lengths you are
prepared to go in doing that.

I think these are very interesting questions.  Personally, my hope is to be competitive with the existing solutions (e.g. CONNECT, TURN, L2TP) in their respective domains, eventually.  That might require waiting for HTTP/QUIC, and it might require some nontrivial congestion control research.  On the other hand, it might not be so hard.  HELIUM's timestamps should be sufficient to allow the client to detect growing flow-control queues at the proxy, in either direction.


-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and 
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in 
error, please delete it from your system.
Do not use, copy or disclose the 
information in any way nor act in reliance on it and notify the sender 
immediately.
Please note that the BBC monitors e-mails 
sent or received.
Further communication will signify your consent to 
this.
-----------------------------

Received on Wednesday, 11 July 2018 04:15:34 UTC