data connection performance

[Bill Thorp]

I've recently tested data connections in Chrome against real-world, high-throughput use cases.  LAN to LAN is decent: >500mbps.  Long fat networks are miserable.

I wrote a simple stochastic hill-climber to test the myriad of suggestions you see out there.  Below are the results of my testing between two Docker + Chrome + tc instances, configured with a 20ms delay.  I've also tested adding an artificial 20ms delay via code with similarly poor results, to ensure that Docker + wasn't doing anything pathological.

Best absolute result: 6.8 MiB/s.  Am I missing something?  I know data channels aren't WebRTC's primary use, but I'm more than surprised.  I can hit 10x that using QUIC + Rust + 20ms delay with zero tuning.

  - peerConnectionCount: 4
  - channelCount: 4
  - chunkBytes: 229376 / 224 KiB
  - highWaterBytes: 262144 / 256 KiB per lane
  - lowWaterBytes: 131072 / 128 KiB
  - ordered: true
  - reliability: reliable
  - payloadType: arraybuffer
  - dataChannelPriority: default
  - sdpBandwidth: none
  - warmupPackets: 0
  - mockAudio: true, speech

  Settings that seem to matter:

  - Multiple peer connections matter most. 4 PCs clearly beat 1 PC.
  - Keep per-lane buffering small. Around 256 KiB high water was the useful region.
  - Chunk size around 224 KiB kept showing up near the top.
  - Use arraybuffer. It keeps winning enough to be the default.

  Settings that do not seem worth caring about much:

  - priority: high: no clear win; default won.
  - SDP bandwidth munging: none won; AS/TIAS did not help.
  - Warmup packets: no reliable gain.
  - Exact low-water value: 96 KiB, 128 KiB, 164 KiB were close; use 128 KiB.
  - Mock audio/contentHint: noisy and not shippable.
  - SDP strip media: irrelevant unless testing the mock-audio hack, and it looked worse.
  - uint8array/blob payloads: no reason to prefer them over arraybuffer.

[guest271314]

Interesting. Is the complete write-up, with steps to reproduce published in the public somewhere?

>  I can hit 10x that using QUIC + Rust + 20ms delay with zero tuning.

Did you test Direct Sockets TCPSocket and UDPSocket, and WebSocketStream?

[Victor Boivie]

Hello,

Data channels use SCTP over DTLS, and SCTP as implemented in RF9260 has a congestion control algorithm very similar to TCP Reno, from ~2000. A significant amount of research from the last 25 years has not yet made it into SCTP - at least the implementation that WebRTC is using, which is quite close to the original RFC. I don't know what algorithm your QUIC example was using, but it's probably BBR or CUBIC, and I would expect them to perform much better in this scenario.

If you want to improve the performance, please experiment and figure out what's wrong. Perhaps there is a bug specific to your scenario, or a limitation in the current congestion control algorithm. You mentioned Rust: there is a Rust port of the SCTP implementation we're using (https://github.com/webrtc/dcsctp) that we will migrate to eventually if that's easier for you. 

Thanks,

Victor

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/dda8f16f-b03d-4db5-92a0-a2129e2e4045n%40googlegroups.com.

[Sean DuBois]

Hey Bill,

Do both sides have to be Chrome? Would you mind trying out [0]

Pion has RACK support so I would love to know if that helps! Or maybe have Pion be the sender and Chrome the receiver only?

If you don’t see a improvement would like to understand why/make it better!

[0] https://github.com/pion/webrtc/tree/main/examples/data-channels

[1] https://pion.ly/blog/sctp-and-rack/

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/CAFaRDoKK6utekr50HSNYpLUUUn4GP9S1%2BT1LnsX_tbb4firPXg%40mail.gmail.com.

[Bill Thorp]

I've extracted my WebRTC latency tests to https://github.com/exnimbus/webrtc.

I ran into the issue with handwritten code + real network latency, but these tests are AI-written.
I'd be very grateful to anyone who takes a look.