21–30 of 48 posts
Earlier quoted context omitted.
That's a bit hard for me to fathom, because the overwhelming vast majority of users don't have multiple Internet connections, and serverside applications can make use of multiple Internet connections without protocol-level multihoming.
> because the overwhelming vast majority of users don't have multiple Internet connections your shiny iphone/andriod etc. are all multihomed...
"However, by far the biggest showstopper to SCTP adoption is the lack of session layer in TCP/IP and the broken Socket API. If you want to use SCTP with the Socket API, you have to indicate the protocol to use in the socket call, which means that every application that would benefit from SCTP support must be changed, recompiled and tested. There is no way that you could take existing applications, add SCTP support in…
I don't think that's what Ivan means at all. He's simply saying that applications that now are using TCP are not easily adopted to SCTP, even if SCTP would have been a better fit.
I agree with you though, at the point SCTP was at a usable protocol the internet was already solidly invested in TCP and there was no going back. Not for software reasons but because there is also a lot of hardware infrastructure that's simply built to only support TCP and UDP, always making SCTP a second class citizen.
"However, by far the biggest showstopper to SCTP adoption is the lack of session layer in TCP/IP and the broken Socket API. If you want to use SCTP with the Socket API, you have to indicate the protocol to use in the socket call, which means that every application that would benefit from SCTP support must be changed, recompiled and tested. There is no way that you could take existing applications, add SCTP support in…
> SCTP was never intended to be a TCP replacement or a basis for TCP or whatever Ivan Pepelnjak thinks it to be. It is a separate protocol which is designed to provide a different set of features to a different set of applications. I don't think that's what Ivan means at all. He's simply saying that applications that now are using TCP are not easily adopted to SCTP, even if SCTP would have been a better fit. I agree…
Earlier quoted context omitted.
It's a problem that apps have, but they just shift it onto the user.
That's a bit hard for me to fathom, because the overwhelming vast majority of users don't have multiple Internet connections, and serverside applications can make use of multiple Internet connections without protocol-level multihoming.
Earlier quoted context omitted.
> because the overwhelming vast majority of users don't have multiple Internet connections your shiny iphone/andriod etc. are all multihomed...
So, the problem is not shifted onto the user?
It's shifted on the application developer, who is the "user" of the network stack.
SCTP should have been promoted and is actually pretty nice on paper. Every time I see someone re-implement multi-plexing and datagram/message parsing out of a TCP stream I think of SCTP. Every time I see custom 'reliable delivery on top of UDP' I think of SCTP. We might not have had QUIC or HTTP/2 in the current form if SCTP was ubiquitous.
The original article was written 6 years ago and wasn't a novel position at the time. It's hard to say anything's changed since then because app developers are still blocked waiting on mainstream middle-box support and I don't see that really happening without some sort of pressure on the vendors.
Earlier quoted context omitted.
SCTP uses 32 bit checksums rather than 16. It may be the case that your hardware can do 16 bit checksums in hardware, but for SCTP it has to do the checksum in software. (I think it used to be the case and maybe still is that SCTP vs TCP benchmarks would disable hardware checksums so that the results weren't biased unfairly in favor of TCP.)
even at gigabit speeds, unless the implementation is really, really bad, checksumming will absolutely not be the issue here as far as my experience goes. Benchmarks should be consulted before preformance issues are debated.
" However, by far the biggest showstopper to SCTP adoption is the lack of session layer in TCP/IP and the broken Socket API. If you want to use SCTP with the Socket API, you have to indicate the protocol to use in the socket call, which means that every application that would benefit from SCTP support must be changed, recompiled and tested. There is no way that you could take existing applications, add SCTP support i…
SCTP should have been promoted and is actually pretty nice on paper. Every time I see someone re-implement multi-plexing and datagram/message parsing out of a TCP stream I think of SCTP. Every time I see custom 'reliable delivery on top of UDP' I think of SCTP. We might not have had QUIC or HTTP/2 in the current form if SCTP was ubiquitous.
The big problem is that that promotion really needs to be aimed at a highly specific community: operating system and network equipment vendors. The original article was written 6 years ago and wasn't a novel position at the time. It's hard to say anything's changed since then because app developers are still blocked waiting on mainstream middle-box support and I don't see that really happening without some sort of pr…
SCTP support has just been removed from DragonFly. The code had been present for 15 years (inherited from FreeBSD) and in these 15 years there wasn't even a single known user.
If there really are people using it it's effectively in a very very small niche and they will have to do everything themselves. There is no way generic operating system developers can work on this protocol.