Re: Interest in a UDP equivalent to the CONNECT method

On Mon, Feb 5, 2018 at 4:28 PM, Göran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

>
>
> On 2018-02-05, 18:55, "Lucas Pardue" <Lucas.Pardue@bbc.co.uk> wrote:
>
>     Martin Thomson wrote:
>
>     >I'm surprised that no one has mentioned TURN yet.  So let me be the
> first.
>
>     I'm not overly familiar with TURN. Are you saying that the
> capabilities of this new method are already fulfilled by TURN,  that TURN
> could be enabled by this method, or that there are design elements to crib
> from TURN.
>
>
> Since Ben added "WebRTC" to the discussion, Martins comment make perfect
> sense. Personally, I would be waiting for Ben to detail the "WebRTC" case
> he has in mind, which would include TURN of course, (.
>

My feeling is:
1. It would be nice for HTTP/QUIC to be self-proxying, in the same way that
HTTP/2 and its predecessors are.
2. The obvious way to do this is to add a UDP proxy method to HTTP.
3. If we're going to define a UDP proxy method, it might as well support
the other common UDP-based protocols.

As for interaction with WebRTC, I would note that right now, running WebRTC
over an HTTP proxy greatly limits the use of UDP candidates, impairing
media quality and often causing suboptimal routing (through TURN/TCP).  If
HTTP proxies could support UDP traffic (on the external interface), this
could be improved.

    The main use case I had, HTTP/QUIC, does not suffer from peer
> communication issues so I find it hard to see where TURN comes in.
>
> +1. The HTTP/QUIC case is pretty straightforward (even though use cases
> are always useful of course). "WebRTC" will require an effort to clarify
> scope and proposed solution.
>

I agree, HTTP/QUIC seems like a simpler case.  A "connection-oriented" UDP
proxy protocol (i.e. a single-destination tunnel) might suffice for
HTTP/QUIC, but it would not be convenient for WebRTC, because WebRTC (i.e.
ICE) works best when clients can receive packets from unexpected sources.
This has implications for the client<->proxy protocol.