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.
Easy that: as long as it took IPv6 to be adopted into the mainstream.
Probably not that long. The problem with IPv6 is that too many entities are involved in a successful v6 deployment and too many changes have to happen at different levels.
OTOH, SCTP requires only a client and a server that want to use it.
Read about SYN Cookies. This is a method of avoiding SYN DOS attacks that has already been implemented in Linux (and probably elsewhere) for a while. I think SCTP just integrates the same concept into the official protocol specification. Once the SCTP server sends the INIT-ACK, it doesn't have to keep track of that association until the client sends a COOKIE-ECHO.
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...).
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.
Seems like there is an implementation for FreeBSD and Darwin (underlying OS used by MacOS X) too, according to this page.
Jumpstart the tartan drive.
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
I may run Linux myself, but in almost everything I do on my desktop (that isn't itself Linux-related) I am interacting with non-Linux machines. I'm forever "losing out" because I can't receive MSN special features. Sure I could do webcam with what was gnomemeeting (it looks awesome) but does anyone run it? Thankfully now I have friends riding Firefox and one using Jabber (googletalk).
But yes all my friends use windows!
So will such features help Desktop Linux?
Short answer: It might "help Desktop Linux" in general, but it will fix zero interoperability issues and it will do nothing to the problems you listed.
Long answer: You need to learn a few things about network protocols, my friend. Even if SCTP, TCP or UDP had anything to do with your problems, SCTP is not implemented on Windows. Most if not all of the programs you're using use TCP or UDP, and the issues of compatibility you're experiencing have nothing to do with these protocols. The programs you mention have their own protocols that run over TCP and UDP. Seriously, go and learn how to program BSD sockets and you'll understand where TCP and UDP are in the network protocol heirarchy. Once you've done that, maybe you could help out projects like Kopete and Gaim to fix your problems.
I have discovered a truly remarkable proof of this theorem that this sig is too small to contain.
DCCP and SCTP are not very related. DCCP is an improvement on UDP - DCCP is an unreliable protocol that improves upon UDP by being aware of, and throttling back upon, network congestion.
The first attempt in the IP world to add a protocol of this type was Reliable Data Protocol, in 1984. (See RFC 908). But that never went anywhere. Since then, nobody has really addressed this. There was ISO TP4, but that didn't go anywhere either, althoug it was fully supported in Windows NT.
SCTP has reasonable congestion behavior, like TCP, so it's an improvement over UDP-based protocols in that regard. Moving some UDP-based protocols to SCTP could be a step up. That's where it could be most useful. It might make sense to put remote procedure call type protocols that now use UDP onto SCTP. If a protocol has to do retransmission, it's better to do it at the transport layer than at the application layer.
The "multihoming" thing seems badly placed, because that's not properly a transport layer function. But I haven't really looked at that.
John Nagle
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.
Some of the protocols that could benefit from SCTP include:
now we need to go OSS in diesel cars