Re: HTTP proposal for UDP proxying: HELIUM

That's very interesting.

Cullen Jennings also made some very supportive comments after the session.
He seems to be interested in this "powerful" approach, as opposed to a very
limited protocol like some participants proposed.

On Mon, Jul 16, 2018 at 5:46 PM Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:

> 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>
> wrote:
>
> On Wed, Jul 11, 2018 at 1:13 AM Ben Schwartz <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.
>
> ---------------------
>