5 ms·

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

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.
        Sean-Der 6y ago
        Ah ok. So the question is more ‘does WebRTC need the complexity’. I think so, reliable transport is pretty useless without backpressure. So here are the recent projects I have worked with that need the complexity. * Teleoperation - Robot control went over reliable stream. Metadata goes over lossless stream, we don’t care about sensor readings 3 seconds ago. * File Transfer - If you send too fast you will cause complete loss. You also need to measure constantly since link quality will fluctuate. * Large Image Transfer - SCTP also handles breaking up messages to fit MTU. If you just send UDP Datagram you need to probe how big of packers you can actually send. * Unreliable Large Image Transfer - If you don’t care if an image arrives and you lose packet 1 you shouldn’t send the rest of the Datagram. This was big for a project, saved a lot of bandwidth making sure we didn’t complete corrupted messages.
        tptacek 6y ago
        These are all extreme niche cases for WebRTC, aren't they? Niche, here, relative to actual usage, not "number of apps". If the overwhelming majority of daily invocations of WebRTC protocols is due to simple videoconferencing applications, and all those invocations have to pay a complexity and security tax in order to potentially enable someone else's "teleoperation", that's a misallocation, isn't it?
        jmgao 6y ago
        Congestion control seems pretty important for videoconferencing, especially given that these are mobile apps that are especially prone to signal degradation/tower switching that will drastically affect throughput. I'd argue that being able to fall back to reliable text chat when your network is imploding and video/audio is unusable is a core feature of web conferencing tools.
- strbean 6y ago
  But we didn't have any option to use UDP from the web stack prior to Data Channels. I guess worries about security trump "make the web stack do everything" though.
  - tptacek 6y ago
    I'm not debating whether Data Channels are useful. I'm debating whether they should be backed by SCTP.
    - strbean 6y ago
      Curious about your axe to grind with SCTP. Is it just that you feel the features of SCTP would be better implemented a la carte by applications? Are there other issues? I haven't really used the protocol, the extent of my knowledge was reading about it back in 2011 and thinking "cool".

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.
      - Sean-Der 6y ago
        Ah ok. So the question is more ‘does WebRTC need the complexity’. I think so, reliable transport is pretty useless without backpressure. So here are the recent projects I have worked with that need the complexity. * Teleoperation - Robot control went over reliable stream. Metadata goes over lossless stream, we don’t care about sensor readings 3 seconds ago. * File Transfer - If you send too fast you will cause complete loss. You also need to measure constantly since link quality will fluctuate. * Large Image Transfer - SCTP also handles breaking up messages to fit MTU. If you just send UDP Datagram you need to probe how big of packers you can actually send. * Unreliable Large Image Transfer - If you don’t care if an image arrives and you lose packet 1 you shouldn’t send the rest of the Datagram. This was big for a project, saved a lot of bandwidth making sure we didn’t complete corrupted messages.
        tptacek 6y ago
        These are all extreme niche cases for WebRTC, aren't they? Niche, here, relative to actual usage, not "number of apps". If the overwhelming majority of daily invocations of WebRTC protocols is due to simple videoconferencing applications, and all those invocations have to pay a complexity and security tax in order to potentially enable someone else's "teleoperation", that's a misallocation, isn't it?
        jmgao 6y ago
        Congestion control seems pretty important for videoconferencing, especially given that these are mobile apps that are especially prone to signal degradation/tower switching that will drastically affect throughput. I'd argue that being able to fall back to reliable text chat when your network is imploding and video/audio is unusable is a core feature of web conferencing tools.
strbean 6y ago
But we didn't have any option to use UDP from the web stack prior to Data Channels. I guess worries about security trump "make the web stack do everything" though.
- tptacek 6y ago
  I'm not debating whether Data Channels are useful. I'm debating whether they should be backed by SCTP.
  - strbean 6y ago
    Curious about your axe to grind with SCTP. Is it just that you feel the features of SCTP would be better implemented a la carte by applications? Are there other issues? I haven't really used the protocol, the extent of my knowledge was reading about it back in 2011 and thinking "cool".