Better Networking with SCTP 233
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... (Score:2, Interesting)
multihoming? (Score:2, Interesting)
INIT floods (Score:1, Interesting)
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.
Comment removed (Score:3, Interesting)
Re:How long... (Score:5, Interesting)
How long do you think it will be before this is adopted into the mainstream?
Probably never main stream. Maybe for some telco types in niche applications... but it is too easy for 99% of the world to just open 2 sockets if you want 2 streams, or rpc's and threads... both of which are well supported and seasoned. Sctp is new, new bugs, not supported everywhere and as a result will go not go far.
One might argue it is supposed to be more secure, I argue it is not. If it was it would be tied to kerberos and ipsec and use AES at the transport layer.
Sctp has only one advantage, and this too could be done using TCP or UDP with not too much effort. That is you can open one socket and have mutiple streams inside, reducing the socket count on servers, a problem if you are routing more than 48000 calls or so. But yor could also do this with "TCP connecting pooling", a common way around this issue.
But like ATM, it is the telco business push. ATM anyone?
Sctp to me looks like a problem looking for a home for 99% of us. But at least an informative post so when I see the compile option I will turn it off.
Re:SCTP vs TCP benchmarks (Score:2, Interesting)
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
How this compares WRT DCCP? (Score:4, Interesting)
The wikipedia assumes they share some properties, but it's SCTP a better DCCP, or what?
Re:SCTP vs TCP benchmarks (Score:2, Interesting)
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.
Re:How long... (Score:5, Interesting)
Nope. I worked on SCTP implementation in year 2000.... Nortel had it in 1999.
New as in it is just making it into some kernels. And it most of us have never seen an application use it. And it may be years before we do. However, as stated it exists in a niche telco market.
Nortel (used to work there) and the industry still has the "central office" mentality. Nortel had one thing right, VoIP is the future. What the telco business as a whole has wrong is how this will be done.
In the future there will no need for a central office, all calls will NOT route through central servers and thus negate a heavy need for sctp altogether! sctp is like a T1-T2-Txxx to sockets, allowing n channels of calls through one IP connection. If VoIP (not strictly defined) goes point to point direct there is no need for a central office. End user devices only need 1 to 4 channels. (Audio/Video/Control/MP3 Movies).
What will happen is someone like Linksys (or a Chinese company) will get enough momentum to produce a $99 device you hook to your internet, some LDAP server out there will be your directory and call routing will go direct device to device over TCP/IP. The MOBILE protocol has a better chance of surpasing SCTP as being in common use. You might even run call conferencing right off your own device.
Central office technology has seen it's peek hayday. SS7, BSSMAP, ISDN, SONET and others are far too complex, expensive, patented and cumbersome - and will be religated to legacy wireline only. SCTP might be used in this niche area to concentrator like a RLCM to wireline services. Hardly end user equipment.
The Internet is slowly eatting the telco business alive. As the traditional telco business market is evaporating.
Wireline needs to quite the bickering, quite tripping on DCLEC cables and get decent inexpensive DSL services or they can say good-bye to their business. DSL is the only hope for the wireline side of the telco business and most are screwing it up big time.
Cisco, if they keep innovation going high are going to put Nortel out of business. Central offices are being replaced with Network Access Point (NAP) and Cisco is king. Nortel might be best to spend their efforts on making the biggest, fastest, cheapest internet router possible. A DMS10000, 10000 as it can take 10000 IP based fibers.
BTW, I loved working for Nortel, but left as I was a grossly underpaid Canadian and could see Stern was going to wreck the company.
4-way handshake (Score:2, Interesting)
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.
Benchmarks measure LKSCTP not SCTP (Score:2, Interesting)
See http://sctp.fh-muenster.de/Performance/index.html [fh-muenster.de]
Linux is a popular research platform (Score:3, Interesting)
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.
Re:read the RFC (Score:2, Interesting)
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.
SCTP in need of a working shim (Score:3, Interesting)
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.
TCP - SCTP shim requirements (Score:2, Interesting)
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.
Re:Multithreaded code (Score:3, Interesting)
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."
Re:kitchen sink (Score:4, Interesting)
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.