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.