Re: Interest in a UDP equivalent to the CONNECT method

Thanks for clarification Ben.

 

The WebRTC QUIC CONNECT topic is a bit clearer to me know, but writing up a draft will of course help even more. I still am pondering the question about a WebRTC API impact, but that is a discussion best suited for the WebRTC API WG I think.

 

Looking forward to this discussion developing further.

 

Best Regards

Göran

 

On 2018-02-06, 17:18, "Ben Schwartz" <bemasc@google.com> wrote:

 

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.