Slashdot Mirror
Better Networking with SCTP
5-0 writes to tell us that IBM DeveloperWorks has an interesting look at the key features of SCTP in the Linux 2.6 kernel and the ability to deliver multi-streaming. "SCTP is a reliable, general-purpose transport layer protocol for use on IP networks. While the protocol was originally designed for telephony signaling, SCTP provided an added bonus -- it solved some of the limitations of TCP while borrowing beneficial features of UDP. SCTP provides features for high availability, increased reliability, and improved security for socket initiation."
How long do you think it will be before this is adopted into the mainstream?
"I'm going to f***ing bury that guy, I have done it before, and I will do it again. I'm going to f***ing kill Google"
Multi-homing with a builtin heartbeat? Youd need a routing table the size of the planet if you wanted to do that over the backbone infrastructure- not to mention gigabytes of wasted bandwidth. Did I miss something?
From the article:
It seems that that you could still have DOS attacks based on INIT floods. The client has to open a socket, generate a cookie (slight increase in computing overhead), and then listen. I see no intrinsic mechanism to eliminate these types of attacks. Technicaly, they would not be SYN floods, but INIT floods.
This is about as useful a distinction as Bush apologists denying he was warned that the levees would be breached because the tapes show him being warned that the levees would be overtopped.
Interestingly, SCTP falls behind TCP in the majority of cases (more latency, less bandwidth).
... Someone in the know care to elaborate ?
The exception being the HTTP tests, where I guess they used only one tcp connection to the server with no keepalive (something that no web browser would do in the real world, most opening 2 or 4 tcp connections with keepalive).
I can't see a real advantage of multi-stream SCTP over multiple TCP connections
The Linux network stack is having tons of new things lately, SCTP is one, but how it compares with DCCP, which has also been implemented and merged in Linux?
The wikipedia assumes they share some properties, but it's SCTP a better DCCP, or what?
I can't see a real advantage of multi-stream SCTP over multiple TCP connections ... Someone in the know care to elaborate ?
Good question
Perhaps this provides a bit of insight: From the article:
"Multi-streaming is an important feature of SCTP, especially when you consider some of the control and data issues in protocol design. In TCP, control and data typically share the same connection, which can be problematic because control packets can be delayed behind data packets. If control and data were split into independent streams, control data could be dealt with in a more timely manner, resulting in better utilization of available resources."
I suspect (although it's not explicitly stated) that SCTP multi-streaming offers less resource consumption of the end points than multiple TCP connections do.
Can someone explain to me how the 4-way handshake is better than the 3-way handshake. I mean, sure the resource allocation has been moved down the process, but a client bent on DOS could still flood the server with INT packets and then just follow up with COOKIE-ACKs, all the while actually not allocating any resources on its side, and you would have the same end result.
Now, if the COOKIE-ACKs required some signficiant processing (like encryption with a public key) then I could understand how this would reduce DOS potential.
...En að Besta Sem Guð Hefur Skapað Er Nýr Dagur
Unfortunately the current mainline Linux kernel SCTP implementation (LKSCTP) has some serious performance problems. On platforms with mature SCTP implementations (FreeBSD, OpenSolaris), SCTP performs *much* better.
See http://sctp.fh-muenster.de/Performance/index.html
That's not necessarily fair to MS.
Linux is a very popular platform for researchers to try out new kernel ideas in a real-world system, like networking protocol ideas. This is for a number of reasons (it's well-written, it's easy to hack on, it's open source and doesn't have any weird restrictions, it's free, it's already popular among CS folk, etc.
I'm not familiar with the particulars of SCTP, but just the fact that this is available under Linux (and perhaps that some (all?)) distros make it available by default does not mean that MS is trying to squash the standard. They just have different interests.
Microsoft is a business, and a very conservative one (for the technology industry, at any rate). Unless they have demands from their large corporate customers for a feature, or they think it's going to expand their market, they have little reason to include said feature. It's irrelevant to them whether their own acceptance of something is essential to it catching on -- if you can't make a business case for it, they aren't going to put something into the kernel. That doesn't happen because Microsoft is being particularly antisocial. They're just a business, and they function with certain limitations, as such.
Linux (well, Linus's tree -- I'm sure Novell has their own kernel tree) is built by a bunch of engineers who, as a whole, have no business constraints to worry about. They're interested in making the best technical system possible. Sure, maybe IBM's not going to fund engineers to add Coda support to Linux, but if Linus says "yes, this is technically good", it can go into Linux if someone else wants to write it.
Thus, you have a suit at the highest echelon in one system, and an engineer at the highest echelon (in one tree -- another way in which Linux ensures competition) in the other system.
The case that a libertarian or other hard-core free-markets-no-matter-what advocate would probably make would have is that nobody can have an influential monopoly on the market (not true in this case) and so if someone does something sub-optimal for the customer, they will quickly lose business to the competition.
Now, I don't know whether SCTP is a good idea or not. I'm just pointing out that there are times that having *any* business control the bulk of the market is going to lead to suboptimal handling of consumer interests -- that business need not be Microsoft.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
It reads as though they just decided the whole layered protocol thing was overrated and shoved every new feature into this one layer.
I couldn't disagree more. SCTP moves a lot of things that should be done in the transport layer there, instead of making applications re-implement heartbeats and failover and message boundaries and so forth for the 1000th time.
I spent last semester taking a class about the nuts and bolts "Upper layer protocols" class with one of the leading SCTP researchers, so I've heard a good bit about this protocol. It's quite good, better than TCP in almost every respect. The one problem is (as you probably guessed) overcoming the fact that TCP is ubiquitous and has a gigantic code base.
So I asked - why not have an API for translating TCP calls into SCTP? He told me that this is called a "shim" and that one already exists. He also said the primary area of interest regarding the shim was getting the shim working on windows and deployed by default with windows. That would significantly reduce the gap.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
This concept has potential but there are some problems. First, SCTP does not support half open connections like TCP, so some applications will not work without modifications.
Second, trying SCTP first and then falling back to TCP later causes considerable delay. To fix that problem the shim would need to insert itself in the name resolution process (getnameinfo) so that it could intelligently decide which protocol to try first. Of course name servers would have to carry SRV extension records to indicate that SCTP was supported on a port / ULP basis.
Multithreading should be treated rather like rabid dogs -- something to be avoided if at all possible.
A wonderful post. I usually say it a little more concisely: "can you draw me the complete state machine? no? then you don't know what your code's doing."
What would Lemmy do?
SCTP sounds like a kitchen sink solution; it has some nice features and some useless features.
What's useless to one application is useful to another. Most of the features can be turned on and off, so the application developer can pick what's suitable for their use.
For example, manually opening multiple connections through different interfaces and then having the SCTP implementation figure out which one to send through is nonsense; if the system has multiple routes to the Internet, then that can be taken care of at the IP level.
This is one thing that I almost agree with you on - multihoming should probably be done at the IP level. But that requires that intermediate routers be modified to introduce the required functionality and we have already seen that many ISPs have no interest in adjusting their infrastructure to support new technologies (multicast, IPv6, etc). SCTP's multihoming support has the advantage that only the end points of the connection need to care, to the rest of the network it's just plain old IPv4.
Similarly, preservation of write boundaries is a useless gimmick that is rarely needed, and when it is needed, can be easily implemented in user code.
I'm not sure why you think this is a "useless gimmick". Very few applications want a byte stream - almost everything works on the datagram level. Think about HTTP - you send the server a bunch of headers (these are separate datagrams), the server returns a bunch of headers (again, separate datagrams) and the actual object data (one massive datagram). At the moment this is done over a byte stream and in order to maintain the boundaries between the datagrams you have to delimit them at the sending end and then parse them at the receiving end. With almost every application wanting to send multiple datagrams instead of a byte stream isn't it better to have this handled at the protocol level rather than reimplementing it for every application? Almost the only things which benefit from byte streams rather than datagram streams are interactive stuff like telnet and SSH (even SSH would benefit from SCTP when you're multiplexing multiple tunnels)
The four-way handshake during setup is possibly useful, but you can trivially get the same with TCP in a backwards compatible fashion if you configure your kernel to protect against SYN spoofing.
TCP SYN cookies are weak in comparison to the SCTP 4-way handshake.
Altogether, I'm not quite sure what problem SCTP is supposed to solve. SCTP has made its way into some other standards, so it will probably be unavoidable, but it's not a well-designed protocol in my opinion.
SCTP was originally designed for telephony applications (it is used to transport SIGTRAN traffic and can also be used to transport SIP). It is designed to combine the benefits of TCP (reliable ordered delivery with congestion control) with the benefits of UDP (preservation of message boundaries and unordered delivery). But while designing a new protocol it was worthwhile addressing other problems that have shown up with TCP and UDP. I would hazard a guess that the _only_ reason TCP is so widely used is because it's the only widely available transport that provides congestion control and reliable ordered delivery - most applications are _not_ suited to communicating through byte streams and many do not even require the data to arrive in order. If SCTP is widely available as an alternative protocol I can see it being used for new applications purely because the preservation of message boundaries removes the need for a chunk of parsing code.
http://blog.nexusuk.org