Forgot your password?
typodupeerror

Better Networking with SCTP 233

Posted by ScuttleMonkey
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."
This discussion has been archived. No new comments can be posted.

Better Networking with SCTP

Comments Filter:
  • How long... (Score:2, Interesting)

    How long do you think it will be before this is adopted into the mainstream?
    • by Rosco P. Coltrane (209368) on Sunday March 05, 2006 @08:41AM (#14853243)
      How long do you think it will be before this is adopted into the mainstream?

      Easy that: as long as it took IPv6 to be adopted into the mainstream.
      • Re:How long... (Score:5, Informative)

        by sjames (1099) on Sunday March 05, 2006 @09:15AM (#14853320) Homepage

        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.

        • Re:How long... (Score:5, Insightful)

          by KiloByte (825081) on Sunday March 05, 2006 @09:27AM (#14853348)
          OTOH, SCTP requires only a client and a server that want to use it.

          And no overzealous firewalls on the way.
          • And no overzealous firewalls on the way.

            Compared to your chances of convincing an ISP to upgrade their routers and buy a prefix from ARIN, getting the firewall fixed is child's play even if the admin wears a huge tinfoil napolean hat and hides behind 'the commitee'

            • Well... if you say that, I envy you the ISPs around the place where you live.

              I don't even dream about IPv6 support upstream -- the place where 192.88.99.1 gets routed to is... Switzerland (and I'm in Poland). Fortunately, at least prot 41 is not blocked.

              While not terribly clueful about networking myself, I'm the guy who gets called by two of four local ISPs when they want any non-trivial changes to their firewalls -- so, I at least made them provide what IPv6 could be done, and I'm making sure the firewall
              • That sounds like a pretty bad situation, but I'll still bet you could get SCTP/IP easier that IPv6 since v6 would require them to actually spend money and perhaps replace old routers. SCTP/IP requires only that they don't block it. It may even be that they DON'T block it since they probably haven't even thought about it. To a router, it's just an IP packet with an unusual protocol number.

                I don't even dream about IPv6 support upstream -- the place where 192.88.99.1 gets routed to is... Switzerland (and I'

        • That's not the problem.

          The problem with IP6 is that it isn't backwards compatible with IPv4.

          IPv6 will *never* happen.

          http://cr.yp.to/djbdns/ipv6mess.html [cr.yp.to]

          • Um... but it is backwards compatible. At least as long as you have a translation layer (Firewall, NAT, etc) between the part of the network that uses it and the part that doesn't. Comcast or some such large ISP could migrate all their customers to IPv6 tomorrow, and maintain perfect interopperability with the rest of the net.
      • Re:How long... (Score:5, Informative)

        by Ulrich Hobelmann (861309) on Sunday March 05, 2006 @09:31AM (#14853356) Journal
        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...).
    • Re:How long... (Score:3, Interesting)

      by Neo-Rio-101 (700494)
      As soon as bittorrent gets vastly imporved from it's ability to multi stream data.

      Obvious implementation of the protocol, really.
      • Multi streaming does not mean multicast. Multi streaming means multiple substreams in one connection. Good for voice trunks (each stream is a voice channel), no benefit for torrents (each connection between two peers usually carries data from only one source.)

        Multicast would rock for a P2P distribution system, even "explicit multicast" which has a rather low limit on the number of destinations, as opposed to IP multicast which has no limit on the number of destinations but presents a nightmare for backbon
    • Re:How long... (Score:5, Interesting)

      by canuck57 (662392) on Sunday March 05, 2006 @10:19AM (#14853454)

      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:How long... (Score:2, Informative)

        by zm (257549)
        > Sctp is new

        Nope. I worked on SCTP implementation in year 2000.... Nortel had it in 1999.

        zm
        • Re:How long... (Score:5, Interesting)

          by canuck57 (662392) on Sunday March 05, 2006 @12:05PM (#14853660)

          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.

          • The Internet is slowly eatting the telco business alive. As the traditional telco business market is evaporating.

            Not really. Its changing, most all of the backbone internet providers are telco people: Sprint, AT&T, MCI, Verizon. At my house, my telephone comes from my cable TV and internet provider. Many companies do this: Time-Warner cable, Comcast, and Cox.

            I would say the telco business is alive and well.

      • "Sctp is new, new bugs, not supported everywhere and as a result will go not go far."

        Oh, so anything new goes nowhere. I can see your point, we are still trying to make those things as fire and the well mainstream...

    • As long as it takes for MSFT to make it work in Windows.
  • Goodbye TCP? (Score:3, Insightful)

    by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Sunday March 05, 2006 @08:43AM (#14853247)
    The article makes SCTP sound like it's the greatest thing since sliced bread. It's as fast as UDP, reliable as TCP, and is not susceptible to SYN floods like TCP. It's amazing! It's the fastest, it's the quickest, it's the best!

    Really?
    • Re:Goodbye TCP? (Score:4, Insightful)

      by Jonner (189691) on Sunday March 05, 2006 @09:19AM (#14853327)
      It sounds to me like SCTP was designed to allow the same capabilities as both TCP and UDP within the same protocol. The designers had the benefit of seeing the advantages and disadvantages of both protocols over the many years of application implementation. Using SCTP won't necessarily make any particular application better than it could be done with either TCP or UDP or a combination of two, but it will probably make the implementation simpler and easier, especially when you would otherwise need to use both TCP and UDP in the same application or when you need failover.
      • This will make those of us who host and manage firewalls easier... one less little click in the netscreen, 50% more efficiency.
    • not susceptible to SYN floods like TCP

      Init and cookie floods instead, the basic problem still exists.

      • Re:Goodbye TCP? (Score:2, Informative)

        by KDR_11k (778916)
        The SYN flood happens because the server has to keep track of the connection until it times out and there's a limit to the number of connections the server can keep track of, with the cookie method the server gets an INIT, sends out the cookie and forgets about the connection. Only when that is returned the server opens a connection. Sure, you could go through the proper protocol for starting the connection but that forces you to tell the server the real IP of your DoSing client instead of putting a number
  • multihoming? (Score:2, Interesting)

    by Loconut1389 (455297)
    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?
    • Re:multihoming? (Score:2, Redundant)

      by Jonner (189691)
      Yes, I think you did miss something. Why would hearbeat require a bigger routing table? Perhaps you're confusing multi-homing with multicasting. And who's this Youd character?
    • Re:multihoming? (Score:5, Informative)

      by isj (453011) on Sunday March 05, 2006 @09:12AM (#14853312) Homepage
      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.
      • 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.

        This only works when all potential ip-addresses of your laptop are known at the start of connection (example: one cabled IP address, and one (fixed) Wifi address).

        Indeed, list of addresses is included in the init chunk, and not updated later.

        In the case of "roaming" where you get a different, dynam

    • Re:multihoming? (Score:5, Informative)

      by romiz (757548) on Sunday March 05, 2006 @09:36AM (#14853367)
      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.
    • The 'multihoming' they are referring to is an entirely different beast than the 'BGP multihoming' you are thinking of. They are just talking about when a box has two interfaces, each with a different IP address. TCP forces a connection to be bound to a specific interface, this SCTP doesnt. There are no changes to the network IP routing functions. (The remote end sends to the other IP, the network doesnt route the first IP to the second network)

      Its an unfortunate re-use of the same term.
  • WOW! (Score:4, Funny)

    by jav1231 (539129) on Sunday March 05, 2006 @09:13AM (#14853314)
    Second City Transport Protocol!? John Candy would be proud!
  • Does this mean all the IANA ports are now open for SCTP?

    Please add the following to your /etc/services:

    tallmatthew 25/sctp

  • by Anonymous Coward on Sunday March 05, 2006 @10:14AM (#14853442)
    • by six (1673) *
      Interestingly, SCTP falls behind TCP in the majority of cases (more latency, less bandwidth).

      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 ... Someone in the know care to elaborate ?
      • 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 spli
      • SCTP falls behind TCP in the majority of cases

        The why is far ore interresting. Is this a implementation that is still subtoptimal, or is this because features will cost latacey by default. (i see a 4 way handshake over a 3 way handshake will cost you a little bit more latnecy to start with)

        I can't see a real advantage of multi-stream SCTP over multiple TCP connections .
        Managememnet int the STCP protocol instead of doing that manually? Specailly if quality of service is involved? YOu can program that all man
    • 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 [fh-muenster.de]
    • Interestingly, I had just run across these yesterday--note these used OpenSS7 implementation and call out issues w/LKSCTP mentioned in other posts:

      http://www.atl.external.lmco.com/projects/QoS/docu ments/DOA2003_97_Thaker.pdf [lmco.com]

      Seems the funding for the TAO SCIOP implmementation came from the US Navy:

      http://www.omg.org/news/meetings/workshops/RT_2003 _Manual/Presentations/5-4_Thaker_etal.pdf [omg.org]
  • FreeBSD, Darwin (Score:5, Informative)

    by Midnight Thunder (17205) on Sunday March 05, 2006 @10:56AM (#14853538) Homepage Journal
    Seems like there is an implementation [www.sctp.de] for FreeBSD and Darwin (underlying OS used by MacOS X) too, according to this page.
  • read the RFC (Score:4, Insightful)

    by darthscsi (144954) on Sunday March 05, 2006 @10:57AM (#14853539)
    A while ago I read the RFC. It is very scary. Multihoming as proposed moves things like name resolution into the kernel.

    I will grant SCTP does some neet stuff, the best is that it allows independent non-mutually-blocking streams over one connection. It also has state cookies, yum.

    SCTP tries to be all things to all people in one protocol. It reads as though they just decided the whole layered protocol thing was overrated and shoved every new feature into this one layer.
    • by butlerm (3112) on Sunday March 05, 2006 @01:17PM (#14853894)
      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.

    • Re:read the RFC (Score:2, Interesting)

      by hehman (448117)
      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.
  • by diegocgteleline.es (653730) on Sunday March 05, 2006 @11:00AM (#14853544)
    The Linux network stack is having tons of new things lately, SCTP [wikipedia.org] is one, but how it compares with DCCP [wikipedia.org], 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?
  • by rev_karol (735616) on Sunday March 05, 2006 @11:14AM (#14853565)
    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 [hamilton.ie]
    Interesting plots too [hamilton.ie]
    The end result is that TCP is not particularly suited to high-speed networks.
  • I'm not geeky enough to understand what all this means but if it means net traffic will get better then I'm all for it. However, based on the responses so far, SCTP vs TCP is starting to become another vi vs Emacs, PHP vs Perl debate that all /. articles seem to follow. Won't someone please think of the packets! :)
  • 4-way handshake (Score:2, Interesting)

    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 re
  • For all its problems TCP/IP is everywhere. This fact has made it the networking technology to use even when it doesn't make technical sense. For example, folks use it in high performance computing and in storage (iSCSI) where there are much better methods available technically. Its commonality (along with ethernet's popularity) often make TCP/IP over ethernet the cheapest solution to many problems (while not the best).

    I used to work on InfiniBand where the reliability/congestion detection protocol (Reliable Connected and Link Level flow control in IB terms) are in hardware. This scales to 20 Gbit connections between hosts quite well. Other examples of hardware protocols include myrinet (invented by myricom) and qsnet (from quadrics) and scalable coherent interface current pushed by Dolphin Interconnect. All of these folks struggle to compete with good old TCP/IP over ethernet. Except for the parts of the HPC world, TCP/IP over ethernet wins. In the storage landscape, Fibre Channel, SAS, and SATA seem to be holding out but iSCSI sure is trying.

    The performance issue is real though and very few systems can saturate a 10 Gbit TCP/IP etnernet link without massive host CPU overhead. One solution floating around is that instead of trying to make new protocols to replace TCP, we should imitate the competition and put hard work in hardware. TCP/IP offload NICs (TOE) are becoming increasingly more popular. With RDMA technology layered on top of it you get iWARP. For storage you get iSER (ironically from an IB company!). This technology is being adopted by both the MS and Linux camps so it seems to have a good shot. In fact, many of the interfaces used by IB work about as well over iWARP cards. Things like Message Passing Interface, Direct Access Provider Library, Sockets Direct Protocol (SDP), and iSER do not know the difference between iWARP and IB or anyone else.

    Software can just post a full size message and it gets sent out the wire without copying, segmentation, timers, resends, or other CPU hogs. This kind of stuff really helps with large messages. With SDP, apps can be made to take advantage of it without changes to the application. MS is also providing a standard way for just TOE NICs without RDMA abilities to work with the OS. Linux doesn't seem to have a standardized way for TCP/IP to be offloaded entirely but is supporting RDMA and SDP.

    The things SCTP seems to offer is more explicit understanding of the difference between failure and congestion and multi-home support. This could make load balancing over multiple paths between hosts pretty interesting. The problem I see is that is that it is competing with the established TCP that now has many of its warts fixed with hardware offload. SCTP will still have the issue of a CPU handling segmentation/reassembly, massive amounts of interrupts, timer/retry overhead, etc. It also seems to have a higher overhead for connection establishment (although that is mitigated by being able to send data during the end phases). Is this a solution looking for a real problem? Pehaps not. Does this really have a chance of being taken up? I am not too confident.
    -Ack
    • by butlerm (3112)
      SCTP and Infiniband focus on different areas. IB is largely a high performance HPC / cluster network architecture for LAN applications, where SCTP is a transport protocol designed to operate efficiently under WAN conditions (significant packet loss, high RTTs).

      SCTP is a more efficient RDMA/iWARP transport than TCP, but the differential advantage of SCTP over TCP is much lower in a LAN environment due to the low RTTs, so RDDP/TCP dominates so far despite the bizarre marker insertion scheme (MPA). Same goes
      • "SCTP and Infiniband focus on different areas. IB is largely a high performance HPC / cluster network architecture for LAN applications, where SCTP is a transport protocol designed to operate efficiently under WAN conditions (significant packet loss, high RTTs)."

        Ok, that makes more sense. IB and other hardware based reliability systems all have problems with long distances. There are folks working on IB WAN though including the U.S. Naval Research Laboratory [pennnet.com]. Check out Obsidian Research [obsidianresearch.com].

        "The interrupt is
    • TCP/IP offload NICs (TOE) are becoming increasingly more popular.
      Ummm... I thought that most NICs had onboard hardware to offload the processing.

      Only the win-modems/NICs (aka the cheap stuff) forced the CPU to handle all the network activity.

      Or am I missing something?
    • TOE cards are not becoming more popular, if anything they are losing popularity. This is due to CPUs becoming more popular, the TCP overhead is not nearly as noticable.
      • At 1 gigabit/second, I would agree that popularity is dropping. All the 1GbTOE folks are gone. At 10 Gbit, I think you still need it and I think the users are showing signs of agreement. Pushing 10 gigabit/second of TCP/IP over ethernet (1500 byte packets) will take up a LOT of CPU time even on todays boxes. I think that Intel's comments about TCP/IP "on loading" represent their failure to get a TOE NIC to really work. At one point they pushed a TOE model. I can say that the solution has to be an ASIC
    • TCP/IP offload NICs (TOE) are becoming increasingly more popular. [...] This technology is being adopted by both the MS and Linux camps so it seems to have a good shot.

      Err, no. TSO (TCP Segmentation Offload -- DMA IO for the network) has been adopted by the Linux people, TOE (TCP Offload Engine -- half the TCP stack is now in hardware) has been completely rejected [lwn.net] by the Linux people, multiple times ... and has basically zero chance of ever happening.

      The good thing, is that it doesn't help ... so no

      • Correct, Linux rejected TOE. But they are accepting IB, iWARP, RDMA, and iSER which essentially include the same ideas. You could argue that Linux's method for supporting TCP/IP offload is to support the RMDA APIs and then run sockets direct protocol. So while Linux doesn't support TOE, they support iWARP which includes TOE.
        -Ack
        • by butlerm (3112)
          Actually, most iWARP/RDMA stuff doesn't have a software interface to TCP at all - the hardware handles not only TCP, but three or more layers on top of it (at least MPA, DDP, and RDMA, plus iSCSI in some cases). That type of interface is not a problem. What is controversial is using TOE for conventional TCP applications using kernel space dispatch.

          This is a bit of an end run around the Linux kernel bridging, routing, and filtering layers, which is the primary reason why support for it won't get merged in
  • by Animats (122034) on Sunday March 05, 2006 @12:37PM (#14853762) Homepage
    It's always been a bit strange that TCP, which is a streaming protocol and ignores message boundaries, is the standard for request/response message type traffic. You have to add a framing protocol on top of TCP to do messaging, which is what everybody does.

    The first attempt in the IP world to add a protocol of this type was Reliable Data Protocol, in 1984. (See RFC 908 [faqs.org]). 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 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.

      It would have been nice if SCTP would have been widely available when we were designing prot

  • by AaronW (33736) on Sunday March 05, 2006 @01:33PM (#14853941) Homepage
    This sounds somewhat similar to TIPC [sourceforge.net] which we're using in some projects where I work. Like UDP it is message based, but it provides a reliable message transport. It also runs in the kernel as a protocol stack. It does have some differences, though. It is not based on a source and destination, but rather a publish/subscribe mechanism which sounds similar to the SCTP multi-homing support. With the publish/subscribe, one or more clients can indicate that they're interested in a certain service. When that service becomes available or disappears on the node, cluster, or network (depending on the scope of configuration) the client stack will automatically notify it.
    It also has the concept of priority in it, so that messages may be prioritized.
    Unlike SCTP, however, it does not run on top of IP but is its own protocol that runs directly over the wire, which means that it cannot be routed across an IP network. It is great as an internal embedded messaging protocol, but not as useful when a network is involved.
    TIPC is also not connection oriented. There is no connection setup required to send messages much like UDP.

    -Aaron
  • by Raul654 (453029) on Sunday March 05, 2006 @01:48PM (#14853995) Homepage
    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.
    • 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 th
      • "First, SCTP does not support half open connections like TCP, so some applications will not work without modifications." - besides (1) port scanners and similiar tools designed to gather information based on low-level socket behavior, and (2) SYN overflow DOS scripts, I cannot think of a single application that depends on half-open connections. Am I missing an obvious one?
  • The article makes no mention of congestion avoidance [wikipedia.org]. Does SCTP use AIMD like TCP? Is it TCP-friendly?
    • Congestion control is an area where SCTP is much like TCP. SCTP uses AIMD on a per destination address basis. However any of the the alternative congestion algorithms for TCP would behave similarly with SCTP.

      Of course given the additional message boundary information available in SCTP, further improvements could be made.
  • From Wiki:

    Chunks

    Each SCTP packet consists, in addition to the common header, of chunks. Each chunk has a common format but the contents can vary. One chunk is display in the diagram to the right with the green background.

    Chunk type
    An 8-bit value predefined by the IETF to identify the contents of the chunk value field.

    Chunk flags
    Eight flag bits whose definition vary with the chunk type. The default value is zero.

    Chunk length
  • by Skapare (16644) on Sunday March 05, 2006 @05:14PM (#14854555) Homepage

    Some of the protocols that could benefit from SCTP include:

    • IRC ... put each channel in its own stream to minimize lost packet retry bottlenecks. This is especially valuable in server to server trunk links.
    • HTTP ... multiple page requests, each in a separate stream, avoids the flood of multiple TCP connections that can use many processes on the server, and avoids the wait of sequential chunks in persistent connections.
    • SMTP ... get your Nigerian business deals, body part enlargement products, replacement ink cartridges, notifications of winning in lotteries you never played, stock investment advise, and those all important sexual drive enhancement drugs, all at the same time.
  • kitchen sink (Score:3, Insightful)

    by idlake (850372) on Sunday March 05, 2006 @05:35PM (#14854630)
    SCTP sounds like a kitchen sink solution; it has some nice features and some useless features.

    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.

    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.

    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.

    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.
    • Re:kitchen sink (Score:4, Interesting)

      by FireFury03 (653718) <slashdot@nexusuk.oGAUSSrg minus math_god> on Monday March 06, 2006 @08:14AM (#14856879) Homepage
      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.

You can do more with a kind word and a gun than with just a kind word. - Al Capone

Working...