4 ms·
> SCTP never caught on for a reason, What is that reason, exactly? I know why I never use it. The use cases where it really shines aren't that common, and it'
by xorcist 8y ago
> SCTP never caught on for a reason,
What is that reason, exactly?
I know why I never use it. The use cases where it really shines aren't that common, and it's a very heavy, telco-style, protocol.
However those things are (mostly) true for QUIC as well.
- wmf 8y agoSCTP does not work through NAT and Windows does not support it.
- gsich 8y agoSCTP has port numbers, so NAT is not a problem. But because of the second point, why should someone implement it? (iptables can do it of course)
- deathanatos 8y agoI'm assuming the parent meant that NAT, as implemented in SOHO routers, does not support SCTP. They could implement it, but don't, and thus, NAT breaks it. > But because of the second point, why should someone implement it? I'm reading this as "SCTP has ports, why should someone implement it?" There is way more to SCTP than ports. For example, SCPT can deliver data on multiple independent streams, something HTTP/2 in many ways reinvents.
- gsich 8y agoAh sorry. Second point was Windows.
- gsich 8y agoWindows
- ahoka 8y agoFrom the article: Why not SCTP-over-UDP SCTP is a reliable transport protocol with streams, and for WebRTC there are even existing implementations using it over UDP. This was not deemed good enough as a QUIC alternative due to several reasons, including: SCTP does not fix the head-of-line-blocking problem for streams SCTP requires the number of streams to be decided at connection setup SCTP does not have a solid TLS/security story SCTP has a 4-way handshake, QUIC offers 0-RTT QUIC is a bytestream like TCP, SCTP is message-based QUIC connections can migrate between IP addresses but SCTP cannot