7 ms·

What's wrong with SCTP?

ivoras 8y ago
Probably the "it's not userland" syndrome. Apparently, moving things to the userland is the new black.
altmind 8y ago
most system administrators are only aware of tcp and udp(that quic uses). its really hurts protocol adoption if it does not work for 3rd parties blocking/not handling it on th e network gear.
- mikedilger 8y ago
  SCTP packets would need to be allowed through the networks. And networks don't bother if nobody is using it. So it's a chicken-and-egg problem. But google is big enough to push through that problem, IMHO, as long as browsers fail back to HTTP/2 or HTTP/1.1, the widespread acceptance of SCTP would be a boon to e.g. VoIP and game developers. But alas it's too late. QUIC has been in development for six years now.
  - ldng 8y ago
    > But alas it's too late. QUIC has been in development for six years now. So what ? We standardize on a hack because Deep Pocket ? Not even mentioning competitive advantage for big cloud companies ...
  - zAy0LfpBZLC8mAC 8y ago
    > But google is big enough to push through that problem Not really. There are hundreds of millions of home routers deployed that all do NAT. And they all don't support NAT for SCTP. And many do NAT with hardware support, so it's probably not even fixable with a firmware upgrade, which isn't even an option for a ton of unsupported devices anyway. So, I think encapsulating in UDP is the only realistic option if you want to gain any adoption any time soon. Also, SCTP has the same problem that TCP has in that the network can look inside the protocol, and thus you would get protocol ossification. While Google does this for selfish reasons, I think it is a really good idea to establish a protocol that is completely opaque to telcos and should ultimately benefit the public. Telcos really don't want to be dumb pipes, and they tend to abuse any power they get, as they have demonstrated time and time again, and the only way to force this issue is by simply making it impossible for them to see or manipulate anything at all. So, while we may have to live with the UDP encapsulation forever, and as stupid as that is, this at least ensures that anyone in the future can trivially invent and deploy new protocols, as it is trivial to masquerade anything at all as QUIC. The adoption of QUIC for the web has the potential to get all ISPs to fix things so that QUIC actually works reasonably reliably over their network. And the fact that as far as the network is concerned it's just UDP packets filled with random data ensures that as long as your new protocol is UDP packets filled with random data, that will work as well, even if you use completely different mechanisms for framing or flow control or multiplexing or whatever.
    - gmueckl 8y ago
      It has taken 20 years to get IPv6 adoption to where it is now. This takes amazing dedication and is a much more fundamental change. Why can't SCTP adoption be a similar long term project? A home router probably has a life span of less than a decade. So it would be realistic to get a majority adoption of SCTP within approximately 15 years if there were a bit of a push in that direction. QUIC has been in the making for 6 years now? SCTP was standardized in 2000. So we could be 6 years into this 15 year project by now instead. And that is not comsidering the time it will take to finish QUIC, build compatible implementations and deploy them.
      - zAy0LfpBZLC8mAC 8y ago
        > It has taken 20 years to get IPv6 adoption to where it is now. This takes amazing dedication and is a much more fundamental change. It doesn't take any dedication at all, it only takes address exhaustion. Which is precisely why it took so long. > Why can't SCTP adoption be a similar long term project? Because there is zero incentive for Telcos. > QUIC has been in the making for 6 years now? And QUIC (the Google "prototype") has probably been successfully deployed to more devices than IPv6 by now?
        jamespo 8y ago
        hmm Facebook run their entire internal network on IPv6
        zAy0LfpBZLC8mAC 8y ago
        Why are you mentioning this?
    - tathougies 8y ago
      Why do people keep bringing this up. Here is how you encapsulate any network protocol in UDP. void encaps_udp(void *out_buf, void *old_pkt, size_t old_pkt_sz) { struct udphdr udp; udp.dport = UDP_DEST_PORT; udp.sport = UDP_SRC_PORT; memcpy(out_buf, &udp, sizeof(udp)); memcpy(out_buf + sizeof(udp), old_pkt, old_pkt_sz); } (Accounting for memory overflow in the real world of course). Of course, this encapsulation for SCTP is even standardized in case it wasn't obvious that this is how you encapsulate protocols.
- tathougies 8y ago
  SCTP can be encapsulated within UDP, has kernel support, and is already implemented in most major web browsers, because of WebRTC, for which it is the standards mandated protoclo.
EvanAnderson 8y ago
I know-- right? Especially in light of UDP encapsulation of SCTP being "a thing"[1]. Instead, we're stuck with this hack. [1] - https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/rfc6951
ldng 8y ago
It needs industry's adoption. It's probably the better long term solution. But why bother when you can hack a wrapper around UDP and pretend you're long term planning for the "greater good" ?

Probably the "it's not userland" syndrome. Apparently, moving things to the userland is the new black.

most system administrators are only aware of tcp and udp(that quic uses). its really hurts protocol adoption if it does not work for 3rd parties blocking/not handling it on th e network gear.

mikedilger 8y ago
SCTP packets would need to be allowed through the networks. And networks don't bother if nobody is using it. So it's a chicken-and-egg problem. But google is big enough to push through that problem, IMHO, as long as browsers fail back to HTTP/2 or HTTP/1.1, the widespread acceptance of SCTP would be a boon to e.g. VoIP and game developers. But alas it's too late. QUIC has been in development for six years now.
- ldng 8y ago
  > But alas it's too late. QUIC has been in development for six years now. So what ? We standardize on a hack because Deep Pocket ? Not even mentioning competitive advantage for big cloud companies ...
- zAy0LfpBZLC8mAC 8y ago
  > But google is big enough to push through that problem Not really. There are hundreds of millions of home routers deployed that all do NAT. And they all don't support NAT for SCTP. And many do NAT with hardware support, so it's probably not even fixable with a firmware upgrade, which isn't even an option for a ton of unsupported devices anyway. So, I think encapsulating in UDP is the only realistic option if you want to gain any adoption any time soon. Also, SCTP has the same problem that TCP has in that the network can look inside the protocol, and thus you would get protocol ossification. While Google does this for selfish reasons, I think it is a really good idea to establish a protocol that is completely opaque to telcos and should ultimately benefit the public. Telcos really don't want to be dumb pipes, and they tend to abuse any power they get, as they have demonstrated time and time again, and the only way to force this issue is by simply making it impossible for them to see or manipulate anything at all. So, while we may have to live with the UDP encapsulation forever, and as stupid as that is, this at least ensures that anyone in the future can trivially invent and deploy new protocols, as it is trivial to masquerade anything at all as QUIC. The adoption of QUIC for the web has the potential to get all ISPs to fix things so that QUIC actually works reasonably reliably over their network. And the fact that as far as the network is concerned it's just UDP packets filled with random data ensures that as long as your new protocol is UDP packets filled with random data, that will work as well, even if you use completely different mechanisms for framing or flow control or multiplexing or whatever.
  - gmueckl 8y ago
    It has taken 20 years to get IPv6 adoption to where it is now. This takes amazing dedication and is a much more fundamental change. Why can't SCTP adoption be a similar long term project? A home router probably has a life span of less than a decade. So it would be realistic to get a majority adoption of SCTP within approximately 15 years if there were a bit of a push in that direction. QUIC has been in the making for 6 years now? SCTP was standardized in 2000. So we could be 6 years into this 15 year project by now instead. And that is not comsidering the time it will take to finish QUIC, build compatible implementations and deploy them.
    - zAy0LfpBZLC8mAC 8y ago
      > It has taken 20 years to get IPv6 adoption to where it is now. This takes amazing dedication and is a much more fundamental change. It doesn't take any dedication at all, it only takes address exhaustion. Which is precisely why it took so long. > Why can't SCTP adoption be a similar long term project? Because there is zero incentive for Telcos. > QUIC has been in the making for 6 years now? And QUIC (the Google "prototype") has probably been successfully deployed to more devices than IPv6 by now?
      - jamespo 8y ago
        hmm Facebook run their entire internal network on IPv6
        zAy0LfpBZLC8mAC 8y ago
        Why are you mentioning this?
  - tathougies 8y ago
    Why do people keep bringing this up. Here is how you encapsulate any network protocol in UDP. void encaps_udp(void *out_buf, void *old_pkt, size_t old_pkt_sz) { struct udphdr udp; udp.dport = UDP_DEST_PORT; udp.sport = UDP_SRC_PORT; memcpy(out_buf, &udp, sizeof(udp)); memcpy(out_buf + sizeof(udp), old_pkt, old_pkt_sz); } (Accounting for memory overflow in the real world of course). Of course, this encapsulation for SCTP is even standardized in case it wasn't obvious that this is how you encapsulate protocols.
tathougies 8y ago
SCTP can be encapsulated within UDP, has kernel support, and is already implemented in most major web browsers, because of WebRTC, for which it is the standards mandated protoclo.

EvanAnderson 8y ago

I know-- right? Especially in light of UDP encapsulation of SCTP being "a thing"[1]. Instead, we're stuck with this hack. [1] - https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/rfc6951

ldng 8y ago

It needs industry's adoption. It's probably the better long term solution. But why bother when you can hack a wrapper around UDP and pretend you're long term planning for the "greater good" ?