Subject: [dispatch] HELIUM at Dispatch

From: Ben Schwartz <[email-masked]>
Date: Wed, 11 Jul 2018 13:27:15 -0400

Hi Dispatch,

One of the drafts on the Dispatch agenda for next week is HELIUM:
https://tools.ietf.org/html/draft-schwartz-httpbis-helium-00.

There has been some discussion on the HTTP list (e.g.
https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0041.html),
but the most detailed presentation on this proposal will be here in
Dispatch.

HELIUM has relevance to privacy protection, P2P through NAT, VPNs, advanced
IP features, QUIC, and congestion control, among other topics.  I hope
anyone who's interested will read the draft (or at least the introduction)
before our session on Monday.

Thanks,
Ben

---

From: Adam Roach <[email-masked]>
Date: Wed, 11 Jul 2018 14:15:44 -0500

[as an individual]

This is small, but it's going to be a recurring papercut if this works 
gains traction: I'm having a really hard time reading a document talking 
about "HIP" that is in no way related to 
https://datatracker.ietf.org/wg/hip/about/ -- please consider renaming 
this protocol.

It would probably also be worthwhile explaining how the features of 
HELIUM are significantly different than RFC 1928. I see raw IP tunneling 
and WebSocket support as differentiators, but it's not clear that this 
requires restarting the protocol from ground zero rather than extending 
an existing extensible protocol.

Lest my suggestion above be perceived as tongue-in-cheek, I'm dead 
serious: RFC 1928 is used extensively by the Tor network, and there is a 
fair body of deployed code in modern use, at least in that context.

/a

On 7/11/18 12:27 PM, Ben Schwartz wrote:
> HELIUM has relevance to privacy protection, P2P through NAT, VPNs, 
> advanced IP features, QUIC, and congestion control, among other 
> topics.  I hope anyone who's interested will read the draft (or at 
> least the introduction) before our session on Monday.
>
> Thanks,
> Ben
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 11 Jul 2018 16:02:30 -0400

> https://datatracker.ietf.org/wg/hip/about/ -- please consider renaming

OK, will do.

It would probably also be worthwhile explaining how the features of HELIUM
> are significantly different than RFC 1928. I see raw IP tunneling and
> WebSocket support as differentiators, but it's not clear that this requires
> restarting the protocol from ground zero rather than extending an existing
> extensible protocol.
>

I've written a lot of code for RFC 1928 (SOCKS 5) myself, including the
rarely used SOCKS5-UDP support, so I fully appreciate this.  Alternatively
TURN also supports UDP, and with RFC 6062 can proxy TCP too.  I do feel
that a clean-slate design is worthwhile in this case, but you're right that
I haven't really tried to argue that in the draft.  I'll think about the
right way to make that claim.

> advanced IP features, QUIC, and congestion control, among other topics.  I
> hope anyone who's interested will read the draft (or at least the
> introduction) before our session on Monday.
>
> Thanks,
> Ben
>
>
> dispatch mailing [email-masked]://www.ietf.org/mailman/listinfo/dispatch
>
>
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 11 Jul 2018 17:47:33 -0400

> right way to make that claim.

For completeness, I also want to mention the current SOCKS 6 proposal:
https://tools.ietf.org/html/draft-olteanu-intarea-socks-6