Slashdot Mirror

← Back to Stories (view on slashdot.org)

Better Networking with SCTP

Posted by ryuzaki0 on from the viva-la-sctp dept.

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."

7 of 233 comments (clear)

  1. Re:multihoming? by isj · · Score: 5, Informative

    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.

  2. Re:How long... by Ulrich+Hobelmann · · Score: 5, Informative

    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...).

  3. Re:multihoming? by romiz · · Score: 5, Informative

    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.

  4. SCTP vs TCP benchmarks by Anonymous Coward · · Score: 5, Informative

    FYI,

    http://www.altoriopreto.com.br/mestrado/index_en.p hp

  5. Other possible future TCPs by rev_karol · · Score: 5, Informative

    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.

  6. Re:INIT floods by lagfest · · Score: 5, Informative
    Who says you have to track the cookies? Just make a hash of the client's ip address, port, and a key that changes every 20 seconds. Now you only have to save a history of the three latest keys.

    In fact, that's pretty close to how it's done according to SCTP for beginners
    The server receives an association setup request (an INIT chunk) usually in the CLOSED state, and analyzes the data contained in that chunk. From that it generates all the values needed at its side to enter an established association, and generates a secure hash of these values and a secret key (e.g. with the MD5 or SHA-1 algorithms). The values are then put into the so-called COOKIE, along with the derived message authentication code (MAC). This COOKIE is returned to the sender of the INIT chunk in an INIT-ACK chunk. The server remains in the CLOSED state, and forgets all about the received INIT chunk.
  7. Kernel space name resolution not required by butlerm · · Score: 5, Informative

    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.