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."
I don't know if you missed something - I didn't RTFA.
Heartbeats are optional. Some real-time applications probably want to use heartbeats every 10 seconds, while other can disable them completely.
The multihoming has nothing to do with routing table size. The multihoming feature is used for providing better connectivity.
Imagine your laptop with WiFi. If the application (say, FTP download) used SCTP instead of TCP then the download would not break when your laptop moves from one access point to another and switches ip-address. SCTP survives that.
That's because IPv6 is *IP*. SCTP builds on top of IP (v4 if you want), just like UDP and TCP.
Just like many applications (mostly streaming servers and games, I suppose) use UDP without anybody caring, you can use SCTP without any host between client and server caring.
It's something for applications to use, not something that requires a different internet infrastructure, replacing routers, software etc. (IPv6 address syntax is different from the v4 one...).
lets change the quote scope a little:
SCTP protects against this type of attack through a four-way handshake and the introduction of a cookie. In SCTP, a client initiates a connection with an INIT packet. The server responds with an INIT-ACK, which includes the cookie (a unique context identifying this proposed connection). The client then responds with a COOKIE-ECHO, which contains the cookie sent by the server. At this point, the server allocates the resource for the connection and acknowledges this by sending a COOKIE-ACK to the client.
Funny how things suddenly makes sense when you read the entire paragraph.
Did I miss something?
This is an transport layer, not a network layer. It is only necessary in endpoints, such as clients and servers, and it might be a good thing if firewalls understood it. But the routers don't interpret it, so there won't be any change on backbones, except a slight increase in traffic with a few more keep-alive packets.
FYI,
p hp
http://www.altoriopreto.com.br/mestrado/index_en.
There's also Scalable-TCP, High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP. Each with their own advantages. Check out the site. These guys are doing interesting evaluations. H-TCP is specifically what they work on:
TCP Evaluation Discussion
Interesting plots too
The end result is that TCP is not particularly suited to high-speed networks.
In fact, that's pretty close to how it's done according to SCTP for beginners
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.
SCTP does have an option for using name resolution to do multihoming, however for practical reasons it is almost universally unimplemented. SCTP multihoming works just fine without it. IP address lists for multihoming are exchanged during the standard connection (association) establishment process.
State cookies are not stored on the server at all, but rather are echoed from the client back to the server as a effective means of SYN flood style DoS attack prevention.
SCTP (properly implemented) is radically superior to TCP for a large class of applications, basically anything that needs low latency reliable message exchange. The lack of message boundary information in TCP causes considerable pain for implementers of upper layer protocols - notably RDMA/RDDP and iSCSI. The running solution for efficient hardware implementation of RDMA and iSCSI over TCP involves *inserting* markers every 512 bytes or so in the middle of a data stream so that the receiver can re-synchronize it efficiently.
The primary SCTP RFC is RFC 2960 for those who are wondering.