3 ms·

It doesn't matter if SCTP has good features if no one is willing to implement quality libraries for it. The protocol exists for a while and only one general pur

by Orphis 5y ago

It doesn't matter if SCTP has good features if no one is willing to implement quality libraries for it. The protocol exists for a while and only one general purpose library exists for it that's widely used. And it's not without a lot of flaws and limitations. There are good reasons no one wants to invest in it, and I'm sure they did consider it.

Sean-Der 5y ago
I am sure there are even more implementations that I am not aware of. * https://github.com/pion/sctp https://github.com/pion/sctp * https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsctptransport.py https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsct... * https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/net/dcsctp/ https://source.chromium.org/chromium/chromium/src/+/main:thi... * https://github.com/sctplab/usrsctp https://github.com/sctplab/usrsctp People don't make these decisions for technical reasons only. Career wise it is a bad choice to spend your time working on pre-existing technologies. You don't become a distinguished engineer by iterating on existing technologies. You become one by being the creator of something new. I think QUIC is great and does a good job solving the problems it was designed to solve. It is disingenuous to pretend these decisions were made only for technical reasons.
- Orphis 5y ago
  3 of those are related to DataChannels in WebRTC, which at this point is baked into the standard and can't be replaced by another protocol. The SCTP in DataChannels is quite limited, that subset is reasonable to implement somehow. Only the last one is really general purpose and has had a lot of security issues as well. Fun fact: I do work on one of those implementations and with another one, and it's out of necessity rather than a career choice.
  - Sean-Der 5y ago
    I know you understand libusrsctp Florent. I created Pion, I feel prety comfortable with SCTP and WebRTC in general as well. RtcQuicTransport tried to replace SCTP and it didn't work. It would be possible to replace SCTP if something better was available. SCTP has lots of great stuff like FORWARD-TSN. QUIC didn't offer anything compelling over it. Also would come with a huge cost of making WebRTC larger and losing interop with all the existing clients. libusrsctp has had security issues, but I don't think the protocol is the problem. The issue is C/C++. QUIC implementations are going to have the same class of bugs. Chrome/libwebrtc has plenty of security issues in other areas besides SCTP. Rust/Go doesn't fix everything, but one less thing to worry about at least.
unethical_ban 5y ago
If Google has a chance to use an industry standard or use their clout to create a new standard, you get one guess at what they're going to do.
- Orphis 5y ago
  Having a standard doesn't mean you're not allowed to innovate and create another one. SCTP dates from RFC2960, first draft was published in 1999. It had enough time to get traction, and it didn't. Why would anyone build something new with it now, knowing that it doesn't answer some of the issues with the current Internet? Even WebRTC's DataChannels were introduced at the IETF in 2012, that's 9 years ago (although ironically, the RFC just got published in January...).

by Orphis 5y ago

Sean-Der 5y ago

I am sure there are even more implementations that I am not aware of. * https://github.com/pion/sctp https://github.com/pion/sctp * https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsctptransport.py https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsct... * https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/net/dcsctp/ https://source.chromium.org/chromium/chromium/src/+/main:thi... * https://github.com/sctplab/usrsctp https://github.com/sctplab/usrsctp People don't make these decisions for technical reasons only. Career wise it is a bad choice to spend your time working on pre-existing technologies. You don't become a distinguished engineer by iterating on existing technologies. You become one by being the creator of something new. I think QUIC is great and does a good job solving the problems it was designed to solve. It is disingenuous to pretend these decisions were made only for technical reasons.

Orphis 5y ago
3 of those are related to DataChannels in WebRTC, which at this point is baked into the standard and can't be replaced by another protocol. The SCTP in DataChannels is quite limited, that subset is reasonable to implement somehow. Only the last one is really general purpose and has had a lot of security issues as well. Fun fact: I do work on one of those implementations and with another one, and it's out of necessity rather than a career choice.
- Sean-Der 5y ago
  I know you understand libusrsctp Florent. I created Pion, I feel prety comfortable with SCTP and WebRTC in general as well. RtcQuicTransport tried to replace SCTP and it didn't work. It would be possible to replace SCTP if something better was available. SCTP has lots of great stuff like FORWARD-TSN. QUIC didn't offer anything compelling over it. Also would come with a huge cost of making WebRTC larger and losing interop with all the existing clients. libusrsctp has had security issues, but I don't think the protocol is the problem. The issue is C/C++. QUIC implementations are going to have the same class of bugs. Chrome/libwebrtc has plenty of security issues in other areas besides SCTP. Rust/Go doesn't fix everything, but one less thing to worry about at least.

unethical_ban 5y ago

If Google has a chance to use an industry standard or use their clout to create a new standard, you get one guess at what they're going to do.

Orphis 5y ago
Having a standard doesn't mean you're not allowed to innovate and create another one. SCTP dates from RFC2960, first draft was published in 1999. It had enough time to get traction, and it didn't. Why would anyone build something new with it now, knowing that it doesn't answer some of the issues with the current Internet? Even WebRTC's DataChannels were introduced at the IETF in 2012, that's 9 years ago (although ironically, the RFC just got published in January...).