WebRTC: Tracking Issue

[sukunrt]

Tasks

Beta Give feedback

1. Implement FIN_ACK spec: webrtc: add FIN_ACK to close datachannels without data loss specs#582
2. webrtc: potential problem with the Pion state machine #2614
   kind/bug +1
3. webrtc: investigate resource usage #1917
   P0 +1
4. Integrate WebRTC with Perf test
5. Remove Experimental tag: Make WebRTC non experimental #2657
6. Implement reuseport support for dialing (not necessary for non-experimental): webrtc: Figure out a way to discover webrtc-direct addresses #2592
7. WebRTC Private to Private: webrtc: private/browser-to-private/server #2009
8. Share the same UDP socket with QUIC webrtc: run on the same UDP socket as QUIC #2446, docs: clarify WebRTCDirect cannot reuse the same port as QUIC ipfs/kubo#10228

[SgtPooki]

@sukunrt any update here?

[sukunrt]

We are on track for a release in v0.34(roughly end of the month) that's good enough to be non experimental. We will still keep it experimental in v0.34 and see if any issues arise. After than v0.35 should have it non experimental.

The current master is pretty good performance wise. When run with the pion/webrtc branch here: pion/webrtc#2696 I see decent memory usage. I'll share the exact numbers soon but for 10 connections each doing 1000 streams and a ping pong of 1MB we see a memory usage of roughly 30MB after the streams are closed and all the connections are open.

On the CPU usage, the performance doesn't look great. Again I'll share more understandable numbers soon, but the CPU usage is roughly 1.5 - 2x of what quic has under similar load. This seems okay to me. quic-go is highly optimised. Single connection throughput is also only 50MB/s but that's also good enough for clients on the web who most likely will be on wifi networks. It's not ideal but we can do perf improvements much better once we see some adoption. On the bright side, the CPU usage is proportional to the total data being transferred on the connection so that's a nice property.