4 ms·

DataChannels themselves are hugely important. Projects like Tor Snowflake and WebTorrent really inspire me. I don’t think there was really an alternative at th

DataChannels themselves are hugely important. Projects like Tor Snowflake and WebTorrent really inspire me. I don’t think there was really an alternative at the time if you wanted feature rich DataChannels. Maybe we could stuck with the simpler RTP Datachannel. All that conversation was before I was aware of WebRTC though. I personally don’t find SCTP that complex. You can implement a basic version pretty easily. Implementing the full spec is overwhelming for sure. I feel pretty confident saying any alternative protocol that is feature rich written in C/C++ will have issues as well.

tptacek 6y ago
Can you say more about how DataChannels are "hugely important" to the common-case use of WebRTC? Adding a whole additional (complicated!) transport protocol just to get WebTorrent seems like the definition of "marginal returns".
- Sean-Der 6y ago
  In 2018 Google claimed they were seeing 3 Petabytes weekly from DataChannel usage. This is from the 2018 KrankyGeek talk. For me personally I use DataChannels pretty extensively for Teleoperation work. Also project like https://github.com/nurdism/neko https://github.com/nurdism/neko and https://github.com/giongto35/cloud-game https://github.com/giongto35/cloud-game are pretty compelling. 3 out of 8 ‘official use cases’ depend on it. https://www.w3.org/TR/webrtc-nv-use-cases/ https://www.w3.org/TR/webrtc-nv-use-cases/ as well. Oh I also think great for E2E security. It is better to exchange metadata and keys via a DataChannel. If you push that stuff through signaling there is a good amount of information leaking.
  - tptacek 6y ago
    The question isn't why WebRTC has a DataChannel feature. It's why the DataChannel feature is as complicated as it is. Why not just use UDP? What's the return on all the complexity the protocol suite is spending?
    - Sean-Der 6y ago
      Ah, sorry missed the question :( I think just so users don’t have to solve the same problem themselves. SCTP gets you multiple streams and they can be ordered/reliable if you want. The congestion control is pretty impressive. You can jump the TSN forward if you send a bunch of data but lose one Datagram in the middle. Cool stuff like that.
      - tptacek 6y ago
        That's why literally every feature exists. The question is what the return on that feature is. If most applications don't get any value from the additional complexity of SCTP, and SCTP itself causes implementation flaws that harm users, the feature is not benign.
- strbean 6y ago
  Having an unreliable transport option is essentially for real time networked multiplayer games. But really, why the hell did it have to take almost a decade to get data channels, when you could jump through a bunch of hoops and essentially build a software dial up modem and transmit data over audio streams? Reminds me of the "minutes vs. texts vs. data" billing nonsense with cell phones. You trying to tell me audio and video aren't data?
  - tptacek 6y ago
    Sure, which is why games tend to use UDP for this. UDP is much simpler than SCTP, and, more importantly, it's already built into the stack.
    - cjbprime 6y ago
      Yeah, I think it's actually the reverse: the SCTP is being tunneled inside UDP anyway, and adding in SCTP allows for a reliable channel to be built on top of the unreliable primitive. i.e. SCTP is used by DataChannels to add the option of reliable transport (and congestion and flow control) to them.
      - tptacek 6y ago
        SCTP doesn't simply add reliability; you can get reliability from UDP trivially.
        Sean-Der 6y ago
        I really don't think it is that trivial! * SCTP allows multiple independent streams * Each streams have different rules on reliability/ordering * SCTP does congestion control and reports back to the user your estimated bandwidth so your application can change what it is doing.
        tptacek 6y ago
        Yes, those are all features beyond reliability. If all you need is reliable transport of some sort, you don't need these. If all we can do is list reasons why SCTP is an interesting and useful protocol, we're at an impasse, because I like SCTP. I just don't know that it belonged in this design, where most applications that want WebRTC for simple use cases are paying a complexity and security cost to make it simpler (not even "feasible", just "easier") to build things like WebTorrent.

tptacek 6y ago

Can you say more about how DataChannels are "hugely important" to the common-case use of WebRTC? Adding a whole additional (complicated!) transport protocol just to get WebTorrent seems like the definition of "marginal returns".

Sean-Der 6y ago
In 2018 Google claimed they were seeing 3 Petabytes weekly from DataChannel usage. This is from the 2018 KrankyGeek talk. For me personally I use DataChannels pretty extensively for Teleoperation work. Also project like https://github.com/nurdism/neko https://github.com/nurdism/neko and https://github.com/giongto35/cloud-game https://github.com/giongto35/cloud-game are pretty compelling. 3 out of 8 ‘official use cases’ depend on it. https://www.w3.org/TR/webrtc-nv-use-cases/ https://www.w3.org/TR/webrtc-nv-use-cases/ as well. Oh I also think great for E2E security. It is better to exchange metadata and keys via a DataChannel. If you push that stuff through signaling there is a good amount of information leaking.
- tptacek 6y ago
  The question isn't why WebRTC has a DataChannel feature. It's why the DataChannel feature is as complicated as it is. Why not just use UDP? What's the return on all the complexity the protocol suite is spending?
  - Sean-Der 6y ago
    Ah, sorry missed the question :( I think just so users don’t have to solve the same problem themselves. SCTP gets you multiple streams and they can be ordered/reliable if you want. The congestion control is pretty impressive. You can jump the TSN forward if you send a bunch of data but lose one Datagram in the middle. Cool stuff like that.
    - tptacek 6y ago
      That's why literally every feature exists. The question is what the return on that feature is. If most applications don't get any value from the additional complexity of SCTP, and SCTP itself causes implementation flaws that harm users, the feature is not benign.
strbean 6y ago
Having an unreliable transport option is essentially for real time networked multiplayer games. But really, why the hell did it have to take almost a decade to get data channels, when you could jump through a bunch of hoops and essentially build a software dial up modem and transmit data over audio streams? Reminds me of the "minutes vs. texts vs. data" billing nonsense with cell phones. You trying to tell me audio and video aren't data?
- tptacek 6y ago
  Sure, which is why games tend to use UDP for this. UDP is much simpler than SCTP, and, more importantly, it's already built into the stack.
  - cjbprime 6y ago
    Yeah, I think it's actually the reverse: the SCTP is being tunneled inside UDP anyway, and adding in SCTP allows for a reliable channel to be built on top of the unreliable primitive. i.e. SCTP is used by DataChannels to add the option of reliable transport (and congestion and flow control) to them.
    - tptacek 6y ago
      SCTP doesn't simply add reliability; you can get reliability from UDP trivially.
      - Sean-Der 6y ago
        I really don't think it is that trivial! * SCTP allows multiple independent streams * Each streams have different rules on reliability/ordering * SCTP does congestion control and reports back to the user your estimated bandwidth so your application can change what it is doing.
        tptacek 6y ago
        Yes, those are all features beyond reliability. If all you need is reliable transport of some sort, you don't need these. If all we can do is list reasons why SCTP is an interesting and useful protocol, we're at an impasse, because I like SCTP. I just don't know that it belonged in this design, where most applications that want WebRTC for simple use cases are paying a complexity and security cost to make it simpler (not even "feasible", just "easier") to build things like WebTorrent.