WebRTC

[olizilla]

What is WebRTC: https://hpbn.co/webrtc/

WebRTC performance

WIP: @olizilla - need more sources, and numbers on the performance issue

• Why: WebRTC is the in-browser p2p api, but connections are prohibitively resource intensive, and establishing new connections is slow.
• Workaround: None.
• Discussion:
  • Webtorrent WebRTC DHT WebRTC DHT webtorrent/webtorrent#288

  • As far as we could tell, the main compatibility issue for WebRTC and KAD is that persistent connections between browsers are very resource intensive.

  • I would add to this that the time it takes to establish new connections is also a major prohibiting factor with WebRTC as it's implemented in browsers today. Unfortunately it looks like in the 1.5 years since tracking this issue WebRTC has made no visible (to me at least) movement towards either of these issues.

• Status
  • Firefox - > Let's collect all the things related to us being able to measure quality and performance progress in WebRTC.

Add support for WebRTC Data Channel in WebWorkers & ServiceWorkers

• Why: WebRTC connections are expensive; we need to use them from WebWorkers & ServiceWorkers to reduce their UX impact.
• Workaround: None.
• Discussion:
  • w3c: Add support for WebRTC Data Channel in Workers w3c/webrtc-pc#230
  • Firefox: P4 - https://bugzilla.mozilla.org/show_bug.cgi?id=922363
  • Chromium waiting on spec - https://bugs.chromium.org/p/chromium/issues/detail?id=302019
• Status: Needs a champion
  • Add support for WebRTC Data Channel in Workers w3c/webrtc-pc#230 (comment)

    I believe this can (and should) be reopened now.
    To everyone interested: I assume you will reach a broader audience if you write to the mailing list public-webrtc@w3.org (not all of them are following GH issues) that we want to reopen the discussion on worker support for data channels. I will support this intention.

  • Make RTCDataChannels Transferable w3c/webrtc-pc#317

    If you start working on this again please loop domenic and I in. There have been some changes (mostly for the better in terms of what you needed last time this was discussed).

WebRTC in WebExtensions

• Why: New p2p protocol handlers have to be implemented as WebExtensions; they need access to WebRTC to make p2p connections.
• Workaround: None.
• Discussion:
  • https://github.com/web-ext-experiments/webrtc
• Status: ?

Unreliable RTCDataChannels

• Why: @lgierth can you explain what this unlocks
• Workaround: None.
• Discussion:
• Status: https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel#Browser_compatibility
  • Chrome: Supported from v56
  • Firefox: Not available yet
  • Edge: ?
  • Safari: Not available yet

WebRTC+QUIC

• https://github.com/w3c/webrtc-quic
• https://developers.google.com/web/updates/2019/01/rtcquictransport-api

[olizilla]

• need WebRTC in WebWorkers, ServiceWorkers and WebExtensions 1 2 3 4 5 6

via ipfs/in-web-browsers#56 (comment)

[olizilla]

@lgierth when you have a moment can you help me understand what "Unreliable RTCDataChannels" unlocks... is this a means to get UDP like / application layer control of the transport layer?

[olizilla]

@dignifiedquire @diasdavid Do you know of any performance metrics we can use to make the WebRTC performance requirement more specific? Can you help me shape that topic please.

[dignifiedquire]

1. where is it supported?

• regular tab
• webworker
• shared worker
• offline worker

2. resource usage

• how does the resource usage scale with use

3. stability

• how many connections can be opened before things crash

[dignifiedquire]

4. raw perf

• how fast can transfers be, compared to regular http transfers on the same connection

[ghost]

@lgierth when you have a moment can you help me understand what "Unreliable RTCDataChannels" unlocks... is this a means to get UDP like / application layer control of the transport layer?

Yes, that :) We'll start work on packet switching in go-libp2p soon, and we'll need unreliable datachannels to do the same in JS (unless there's some other avenue we have overlooked so far).

[olizilla]

@lgierth would getting access to a TCP/UDP socket api supersede the need for unreliable RTCDataChannels and webrtc perf improvements?

[ghost]

UDP sockets yes - but that is soooooo unlikely

[olizilla]

WebRTC performance

The results reveal that current WebRTC data channel
implementations do not adjust the SCTP window size from the
default setting. This results in bad performance when network
conditions and especially latency is not close to perfect. Changing
the window size results in significantly better performance on
high latency links, but the observed throughput performance is
still not ideal. We can conclude from the test results that current
WebRTC data channel implementations are not yet ready for
high performance requirements nor mobile environments where
battery life is important. The browsers need their WebRTC data
channel implementations optimized in order for the technology
to become truly useful.
https://pdfs.semanticscholar.org/040d/9be1b3daae3abbce347ab81ca37fa64df812.pdf

WebRTC DataChannel throughtput is CPU bound, and single threaded.

High throughput over data channels seems to be very heavy
on CPU usage, and the CPU load is largely single threaded.
On a recent high-end PC, throughput readings of up to 30.0
MB/s could be observed in local testing from one browser
process to another. At this point both browsers each put full
load on their respective CPU cores. So at very high throughput
we are CPU bound currently, even on a fast modern PC.
https://pdfs.semanticscholar.org/040d/9be1b3daae3abbce347ab81ca37fa64df812.pdf

WebRTC DataChannels using a small and fixed SCTP window size causes throughput to be very sensitive to network delay and significantly lower than using larger or flexible window sizes.

at constant window sizes
the maximum throughput is inversely proportional to the RTT.
Doubling the RTT value will halve the maximum throughput.

We can see that doubling the simulated RTT indeed does
halve the observed throughput. We also can see that the
measured throughput rates stay fairly close to the theoretical
maximum rates. The table shows that throughput performance
gets unacceptably low with anything but the lowest latency
links for any kind of bulk data transfer. Worse yet, the observed
throughput performance at RTT values near those of cellular
technologies such as 3G and 4G is much lower than the
bandwidth available using these technologies in our testing.
This has reprecussions in energy consumption on mobile
devices because for bulk data transfer the radio has to stay
on for longer than would otherwise be needed.
https://pdfs.semanticscholar.org/040d/9be1b3daae3abbce347ab81ca37fa64df812.pdf

[olizilla]

https://test.webrtc.org/

Open WebRTC issues

Chromium

All open WebRTC issues > https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3ABlink%3EWebRTC+&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids

Some gems

• DataChannel stops working after receiving message larger than 99076 bytes
• Implement RTCSctpTransport
• RTCPeerConnection objects are released too slowly and reallocating causes exception: Cannot create so many PeerConnections

Firefox

All open WebRTC issues > https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&component=WebRTC&component=WebRTC%3A%20Networking&component=WebRTC%3A%20Signaling

[olizilla]

Edge

All open WebRTC issues > https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/?page=1&q=WebRTC%20status%3Acodereview%20status%3Aconfirmed%20status%3Aexternal%20status%3Ainprogress%20status%3Arootcause

Safari

All open WebRTC issues > https://bugs.webkit.org/buglist.cgi?component=WebRTC&product=WebKit&resolution=---

Brave

WebRTC issues are mostly what ever electron's version of chromium suffered from. Soon to be whatever a more recent version of chromium suffers once they swap out muon...

of note brave/browser-laptop#10631 I should follow up on that.

[lgrahl]

Hi everyone. I'm the author of RAWRTC and I also recently worked on Mozilla's data channel implementation.

WebRTC performance

Why we are CPU bound is still a mystery to me and the guys that develop usrsctp (the library pretty much everyone uses for data channels). This needs investigation and would make a great topic for a thesis/paper. I would love to investigate this further but progress will be slow since I have other things I need to take care of.

Add support for WebRTC Data Channel in WebWorkers & ServiceWorkers

This is under investigation as part of WebRTC Next Version. You're not alone. 🙂

Unreliable RTCDataChannels

I'm a little puzzled by this. We have unreliable data channels for years now. 😀

pc.createDataChannel('blah', { maxRetransmits: 0 })

[reklatsmasters]

Hello, I’m author of NodeRTC. NodeRTC is a pure js WebRTC DataChannel implementation. The final goal of this project is to make WebRTC a more developer-friendly.

[backkem]

Just to flesh out our options here: pion/webrtc is a pure Go WebRTC stack. The entire stack is implemented in user-space on top of UDP. It is developer friendly and has decent DataChannel transfer speeds.
It has an active community that is open to experimenting. If you want to prototype any of the solutions mentioned above, Pion may provide great testing grounds.