TURN servers running over webtransport

[unicomp21]

We need a TURN server spec which runs over webtransport, right?

[fippo]

Why?

If yes, that would be a matter for the IETF to discuss, it will probably end up with something like ?transport=webtransport in the url so no action for the webrtc-api is required.

[unicomp21]

@fippo is there another repo where I can open an issue w/ IETF?

With respect to asking why, isn't this the same as asking why is webtransport better than TCP? There are a number of reasons. While there are not a lot of hardware offloads "yet", there will be in the future. And as "packet shaders" on the gpu evolve along w/ packet processing on fpga's, I would suggest the performance opportunities are considerable.

@voluntas why the objection?

[aboba]

@unicomp21 Not sure what use case you are contemplating, but this doesn't seem like a WebRTC issue (although it might relate to the WebTransport API or protocol). To understand where WebTransport protocols are headed, you might want to attend the IETF WebTransport WG meeting on May 20.

WebTransport is a client/server API, not a P2P API like WebRTC-QUIC. As a result, WebTransport is not designed to handle NAT traversal; the server is assumed to have a globally reachable IP address. So as to be able to handle use cases where UDP and QUIC might be blocked, WebTransport API is contemplating adding support for HTTP/2 failover. Assuming that this is added, the API would still fail in enterprises which block UDP and and TCP except for HTTP versions 1.0/1.1.

[unicomp21]

From a scalability perspective, ie for cases involving thousands of TURN servers, is there a performance argument for having TURN running over webtransport? Given webtransport runs over user space udp, combined with newer capabilities like AF_XDP or DPDK, I'm wondering if there is a substantial performance optimization opportunity staring at us.

I've no idea who would be the "expert" for this question. Simply posting here in the hope I can get pointed in the right direction.

[aboba]

If we're talking about TURN over HTTP/3 datagrams, you'd lose most of the benefits of QUIC reliable streams (e.g. fewer false RTOs, better response to loss, etc.). So it's not clear to me why you would expect better performance than TURN/UDP. Also, even though zero-copy QUIC libraries are available, QUIC in Chrome is not zero-copy on receive (it has two copies at present).

[unicomp21]

Good point. Other than the firewall being open, there isn’t much of an argument.

…

On Sun, May 16, 2021 at 1:52 PM Bernard Aboba ***@***.***> wrote: If we're talking about TURN over HTTP/3 datagrams, you'd lose most of the benefits of QUIC reliable streams (e.g. fewer false RTOs, better response to loss, etc.). So it's not clear to me why you would expect better performance than TURN/UDP. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2651 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEFL7MFAZ4KRDEWKEJAKQLTOAH5NANCNFSM44ROALSQ> .

[misi]

AFAIU TURN or relaying may could add some benefit still here too in some edge case. (I don't knwo maybe it is not so edge.)
Think about such a use case where the local ISP of the user has limited (crowded, bad quality) commodity uplink network (capacity limitation to International directions), but very good connection to local Internet exchange. If TURN servers are sitting very close to these Internet Exchanges(IX) and your TURN servers has good reliable connection, then TURN still could add some help to the user's media traffic to reach the reliable internet "highway" faster, and so it may gives for them lower latency, or better reliability, (or both) etc.. Somehow it adds an alternative route through the local IX.
And we saw from the presentation on Kranky Geek this year, that ISPs (even more the smallest ISPs) routing is not always based on low latency but much more on the cost of the commodity traffic. (demo was about an edge case where multihop SFU routed traffic was ~1s faster then direct connection)
So in such use case the direct connection from the client to server is not always the fastest path, and using a relay (TURN or SFU) still make sense.

[fippo]

the only advantage i can see is that firewalls might not block quic/webtransport when they do block (or attempt to) STUN/TURN. https://datatracker.ietf.org/doc/html/draft-hutton-rtcweb-nat-firewall-considerations-03#section-4.3 has some words on that.

I think the TRAM WG is closed but the mailing list still works so might be a good place to ask.

[unicomp21]

@fippo that's exactly what I was trying to say, many thanks for clearing it up. I'll ping the mailing list. Appreciate it!

[dontcallmedom]

since this is not an API issue at the moment, and since there is a path forward for where the discussion needs to happen, closing this here.

[hakarim740-com-ra]

If we're talking about TURN over HTTP/3 datagrams, you'd lose most of the benefits of QUIC reliable streams (e.g. fewer false RTOs, better response to loss, etc.). So it's not clear to me why you would expect better performance than TURN/UDP. Also, even though zero-copy QUIC libraries are available, QUIC in Chrome is not zero-copy on receive (it has two copies at present).

Some firewalls block UDP therefore TURN over HTTP/3 datagrams or QUIC would help penetrate these firewalls.

[murillo128]

oohhh the good old days https://datatracker.ietf.org/doc/html/draft-chenxin-behave-turn-websocket-01

[hakarim740-com-ra]

oohhh the good old days https://datatracker.ietf.org/doc/html/draft-chenxin-behave-turn-websocket-01

WebSocket does not support datagrams

[juberti]

if you're going to run TURN over HTTP/3, might as well clean up the ad hoc auth stuff in the TURN protocol and allow standard HTTP auth to be used. Even in 2024, we're still doing things like https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/relay-token