RE: HTTP proposal for UDP proxying: HELIUM

To paraphrase a comment that I received after the DISPATCH session:

Could the addition of timing data to a tunnelling solution solve some of the problems that the QUIC spin bit work is attempting to fix? For example, a customer in an ISP, experiencing problems, could be explicitly directed to a debugging proxy to expose timing information to both parties.

Regards
Lucas

From: Ben Schwartz [mailto:bemasc@google.com]
Sent: 11 July 2018 02:33
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>; HTTP Working Group <ietf-http-wg@w3.org>
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.

---------------------