Subject: RE: HTTP proposal for UDP proxying: HELIUM

From: Lucas Pardue <[email-masked]>
Date: Mon, 2 Jul 2018 22:23:18 +0000

To follow Ben’s previous email, I have published another draft in the UDP proxying family.

This one takes a broader look at today’s TCP tunnelling that uses the HTTP CONNECT method. It generalises the tunnelling concepts and surveys options that may be suited toward UDP or IP tunnels. Design considerations are captured, and some technical solutions are specced out for illustrative purposes. Four candidate solutions are proposed to help direct discussion, although the matrix of options supports many permutations.

Title:
   HTTP-initiated Network Tunnelling

Abstract:

   The HTTP CONNECT method allows an HTTP client to initiate, via a

   proxy, a TCP-based tunnel to a single destination origin.  This memo

   explores options for expanding HTTP-initiated Network Tunnelling

   (HiNT) to cater for diverse UDP and IP associations.

https://tools.ietf.org/html/draft-pardue-httpbis-http-network-tunnelling-00

Questions and reviews are welcomed. Ben and I will are scheduled to present our drafts at the HTTPbis session on Tuesday 17 July.

Kind regards
Lucas

From: Ben Schwartz [mailto:[email-masked]]
Sent: 25 June 2018 21:44
To: HTTP Working Group <[email-masked]>
Subject: HTTP proposal for UDP proxying: HELIUM

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

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Sun, 8 Jul 2018 23:20:01 +0000

Hi Ben,

First, thank you for the nicely written and very clear document.

A few comments:

  *   I think this document would enjoy greatly from a discussion on the assumed trust model.  It seems to me it's sort of implied that trust must be mutual for this to work.  But maybe the assumption could be relaxed in some scenario?  The problem is this is not explicitly spelled out, which leaves the reader in a slightly suspended state :-)

  *   Sec 2.3: with regards to metadata of type integer (id, dns, errors, timestamp), not sure why you are not constraining the type to unsigned integer straight away (which CBOR supports) rather than imposing a separate "SHOULD treat negative as errors"?

  *   I think I understand the reasoning behind not sending unsolicited meta message, but there might be a more balanced approach that allows proxy to inform the client about anything dodgy going on without requiring the client to request feedback on each and every packet just in case?  Maybe an explicit "error/warning" message type?

  *   Permission-less extensibility is great, but I’m a bit uncomfortable that sender semantics is silently ignored at the receiver (fourth from last para in Sec. 2.3). The text seems to also imply that in principle there is no guarantee that any metadata key is going to be honoured? I think it'd be nice to have a way to express the fact that a key MUST be understood at the receiver (e.g., give them even, or odd, key indexes) and allow an explicit error to be sent back if needed.  Note that a similar situation arises in the last para of 2.4.

  *   There is no mention about the treatment of UDP options - I'm thinking in particular regarding PLPMTUD [1].  I guess if you want options to work in UDP tunnel mode, they should be conveyed in a new metadata key?

  *   Maybe I'm not understanding correctly, but it seems to me that in 2.5.1 first para you could simply say that the client always clears the src address of the tunnelled packet and the proxy populates it?

  *   Sec 2.1: "Context: the identity […]",  s/identity/instance/ maybe?

Cheers!

[1] https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-03

On 25/06/2018, 21:47, "Ben Schwartz" <[email-masked]<mailto:[email-masked]>> wrote:

Hello HTTPBIS,

Title:

--Ben Schwartz

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 10 Jul 2018 11:09:27 -0400

On Tue, Jul 10, 2018 at 7:48 AM Mirja Kühlewind <
[email-masked]> 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 <[email-masked]> 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.
> >   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.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 10 Jul 2018 12:21:36 -0400

> First, thank you for the nicely written and very clear document.

And thank you for your nicely written and very clear comments!

>
>
> A few comments:
>
>
>
>    - I think this document would enjoy greatly from a discussion on the
>    assumed trust model.  It seems to me it's sort of implied that trust must
>    be mutual for this to work.  But maybe the assumption could be relaxed in
>    some scenario?  The problem is this is not explicitly spelled out, which
>    leaves the reader in a slightly suspended state :-)
>
> OK, I agree.  I'll plan to add a section on that.

I'm not sure exactly how to describe the trust relationship.  In a sense,
the amount of trust required is very weak, similar to the trust between a
client and a nearby IP router or NAT gateway.  The major risks I see for a
proxy are spam, resource costs, and exploitable bugs.  The major risks I
see for a client are metadata privacy, content privacy (if the content is
not encrypted, which it really should be), and denial of service.

>
>    - Sec 2.3: with regards to metadata of type integer (id, dns, errors,
>    timestamp), not sure why you are not constraining the type to unsigned
>    integer straight away (which CBOR supports) rather than imposing a separate
>    "SHOULD treat negative as errors"?
>
> Section 2.3 is about the abstract "HIP" protocol, which might be encoded
in ways other than CBOR.  For example, Lucas has proposed an  encoding of
HIP in HTTP/2 frames that does not use CBOR.

>
>    - I think I understand the reasoning behind not sending unsolicited
>    meta message, but there might be a more balanced approach that allows proxy
>    to inform the client about anything dodgy going on without requiring the
>    client to request feedback on each and every packet just in case?  Maybe an
>    explicit "error/warning" message type?
>
> That's an interesting idea.  We could say:

If an "outbound" message encounters an error that prevented it from being
sent, and does not have an "id", the proxy SHOULD (MAY?) respond with a
"meta" message that also lacks an "id".

Would that work for you?

>
>    - Permission-less extensibility is great, but I’m a bit uncomfortable
>    that sender semantics is silently ignored at the receiver (fourth from last
>    para in Sec. 2.3). The text seems to also imply that in principle there is
>    no guarantee that any metadata key is going to be honoured? I think it'd be
>    nice to have a way to express the fact that a key MUST be understood at the
>    receiver (e.g., give them even, or odd, key indexes) and allow an explicit
>    error to be sent back if needed.  Note that a similar situation arises in
>    the last para of 2.4.
>
> It seems to me that this is about trying to predict the kinds of options
that we might want in future versions of this protocol, which is always
challenging.  It's not clear to me that we'll need this, but I can see the
appeal.  Maybe we could have the "meta" message include a list of
unrecognized options?

>
>    - There is no mention about the treatment of UDP options - I'm
>    thinking in particular regarding PLPMTUD [1].  I guess if you want options
>    to work in UDP tunnel mode, they should be conveyed in a new metadata key?
>
> I wasn't aware of the UDP Options draft (
https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-04), but that's
actually not a problem.  I think it's sort of a case in point of how the
HELIUM design works.  HELIUM says nothing about UDP Options, and a given
proxy might forward the options successfully, strip them, modify them, or
drop the packet as malformed.  However, the message format is capable of
representing them, and as a client you're always welcome to try to use
them.  The "meta" reply will unambiguously indicate whether it worked, or
how it failed.

>
>    - Maybe I'm not understanding correctly, but it seems to me that in
>    2.5.1 first para you could simply say that the client always clears the src
>    address of the tunnelled packet and the proxy populates it?
>
> Those two behaviors (client and proxy) are valid and allowed, but they're
not required.  Alternatively, the client can choose to use different source
address values for different outbound packets, and the proxy can choose to
map different source addresses to different "network source addresses".
This allows the use of multiple source addresses in a single HELIUM
session.  For example, I could imagine this being useful to a browser that
wants to use a different IPv6 address for each tab or profile.

>
>    - Sec 2.1: "Context: the identity […]",  s/identity/instance/ maybe?
>
> OK.

> On 25/06/2018, 21:47, "Ben Schwartz" <[email-masked]> 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.
>
>
>

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Tue, 10 Jul 2018 20:30:11 +0000

Hi Ben, replies inline.
cheers

On 10/07/2018, 17:21, "Ben Schwartz" <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Jul 8, 2018 at 7:20 PM Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ben,

A few comments:

·  I think this document would enjoy greatly from a discussion on the assumed trust model.  It seems to me it's sort of implied that trust must be mutual for this to work.  But maybe the assumption could be relaxed in some scenario?  The problem is this is not explicitly spelled out, which leaves the reader in a slightly suspended state :-)
OK, I agree.  I'll plan to add a section on that.

I'm not sure exactly how to describe the trust relationship.  In a sense, the amount of trust required is very weak, similar to the trust between a client and a nearby IP router or NAT gateway.

I’m not sure I agree with the statement that the trust to nearby IP routers or NAT gateways is necessarily weak.  In fact, I think I tend to trust it maybe too much with my packets...  And the converse is also true, in the sense that I’m typically one of the few clients sitting at the back of its NAT / forwarding tables, and I’m using WPA2 with a reasonably secure password to authenticate to it.

The major risks I see for a proxy are spam, resource costs, and exploitable bugs.

Yes, I agree, especially if the proxy needs to satisfy the “tightly bounded memory usage.” requirement.  I’m not sure if you want to spell the DoS relay risk explicitly or you count that into the “spam” bucket?

The major risks I see for a client are metadata privacy, content privacy (if the content is not encrypted, which it really should be), and denial of service.

I agree.

·  Sec 2.3: with regards to metadata of type integer (id, dns, errors, timestamp), not sure why you are not constraining the type to unsigned integer straight away (which CBOR supports) rather than imposing a separate "SHOULD treat negative as errors"?
Section 2.3 is about the abstract "HIP" protocol, which might be encoded in ways other than CBOR.  For example, Lucas has proposed an  encoding of HIP in HTTP/2 frames that does not use CBOR.

Oh, I see!  So maybe it’s worth suggesting the use of unsigned int types in HIP-CBOR?

·  I think I understand the reasoning behind not sending unsolicited meta message, but there might be a more balanced approach that allows proxy to inform the client about anything dodgy going on without requiring the client to request feedback on each and every packet just in case?  Maybe an explicit "error/warning" message type?
That's an interesting idea.  We could say:

If an "outbound" message encounters an error that prevented it from being sent, and does not have an "id", the proxy SHOULD (MAY?) respond with a "meta" message that also lacks an "id".

Would that work for you?

It would, thanks.

·  Permission-less extensibility is great, but I’m a bit uncomfortable that sender semantics is silently ignored at the receiver (fourth from last para in Sec. 2.3). The text seems to also imply that in principle there is no guarantee that any metadata key is going to be honoured? I think it'd be nice to have a way to express the fact that a key MUST be understood at the receiver (e.g., give them even, or odd, key indexes) and allow an explicit error to be sent back if needed.  Note that a similar situation arises in the last para of 2.4.
It seems to me that this is about trying to predict the kinds of options that we might want in future versions of this protocol, which is always challenging.  It's not clear to me that we'll need this, but I can see the appeal.  Maybe we could have the "meta" message include a list of unrecognized options?

Yes, this is always trickier than expected.  I think CoAP got that quite right though.  (You might want to have a look at the critical/elective options thing in RFC 7252, which is very efficiently encoded as a binary signal (even/odd) in the codepoint itself.)

·  There is no mention about the treatment of UDP options - I'm thinking in particular regarding PLPMTUD [1].  I guess if you want options to work in UDP tunnel mode, they should be conveyed in a new metadata key?
I wasn't aware of the UDP Options draft (https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-04), but that's actually not a problem.  I think it's sort of a case in point of how the HELIUM design works.  HELIUM says nothing about UDP Options, and a given proxy might forward the options successfully, strip them, modify them, or drop the packet as malformed.  However, the message format is capable of representing them, and as a client you're always welcome to try to use them.  The "meta" reply will unambiguously indicate whether it worked, or how it failed.

Sorry, I hadn’t understood that even in UDP mode the whole IP datagram is sent in the outbound message (I incorrectly thought it was just the UDP datagram).  Then you are right, the options will be visible to the proxy in any case.

·  Maybe I'm not understanding correctly, but it seems to me that in 2.5.1 first para you could simply say that the client always clears the src address of the tunnelled packet and the proxy populates it?
Those two behaviors (client and proxy) are valid and allowed, but they're not required.  Alternatively, the client can choose to use different source address values for different outbound packets, and the proxy can choose to map different source addresses to different "network source addresses".  This allows the use of multiple source addresses in a single HELIUM session.  For example, I could imagine this being useful to a browser that wants to use a different IPv6 address for each tab or profile.

·  Sec 2.1: "Context: the identity […]",  s/identity/instance/ maybe?
OK.

Cheers!

Hello HTTPBIS,

Title:

--Ben Schwartz

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 10:03:59 +1000

On Wed, Jul 11, 2018 at 1:13 AM Ben Schwartz <[email-masked]> 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.  The question here is whether you
care to grapple with the problems, and do what lengths you are
prepared to go in doing that.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 10 Jul 2018 21:32:43 -0400

On Tue, Jul 10, 2018 at 8:04 PM Martin Thomson <[email-masked]>
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.
>
> performance degradation of a kind.

Yes, although it's generally good for throughput.

> The question here is whether you

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.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 11 Jul 2018 04:15:02 +0000

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 [[email-masked]]
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 <[email-masked]<mailto:[email-masked]>> wrote:

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.
-----------------------------

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jul 2018 14:40:29 +1000

Not Lucas' main point, but...

> 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.…

If you take the rules from h2 directly, then yes, there is no option
to coalesce, because the client remains ignorant of the DNS records
that might point to the same IP address.  However, the ORIGIN frame
relieves the client of that constraint and would allow for coalescing
in that case.

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 13 Jul 2018 14:24:30 +0000

Martin Thomson:

>If you take the rules from h2 directly, then yes, there is no option to coalesce,
>because the client remains ignorant of the DNS records that might point to the
>same IP address.  However, the ORIGIN frame relieves the client of that
>constraint and would allow for coalescing in that case.

That's a great observation thanks. The ability to coalesce a HTTP connection, that itself could be used to carry "non-HTTP" traffic (subject to a mechanism that allows that to happen) is a pretty powerful capability.

Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 16 Jul 2018 21:46:01 +0000

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:[email-masked]]
Sent: 11 July 2018 02:33
To: Martin Thomson <[email-masked]>
Cc: Mirja Kühlewind <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: HTTP proposal for UDP proxying: HELIUM

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

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.

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

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 16 Jul 2018 17:50:55 -0400

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 <[email-masked]> wrote:

> 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:[email-masked]]
> *Sent:* 11 July 2018 02:33
> *To:* Martin Thomson <[email-masked]>
> *Cc:* Mirja Kühlewind <[email-masked]>; HTTP Working
> Group <[email-masked]>
> *Subject:* Re: HTTP proposal for UDP proxying: HELIUM
>
>
>
>
>
> 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.
>
>
>
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.