Limitations of TCP and SCTP

SCTP suffers from being less well tested an tuned implementations, poor performance compared to TCP. Iperf TCP on a 1.5Ghz Powerbook to localhost reaches 3.45 Gbits/sec, while SCTP is 642 Mbits/sec. Powerbooks and most desktops come with Gigabit Ethernet, so SCTP cannot even reach full line bandwidth of a Gigabit Ethernet interface while TCP has no problems. New Gigabit Ethernet MAC designs also support TCP and UDP checksum offload, it is not clear if these designs will support SCTP checksum offload and other performance enhancements as well.

TCP suffers from only being able to HACK 3-4 gap segments in a single SACK. SCTP, while still looking at packet loss as congestion, behaves much better in a low-latency environment by being able to SACK and list more than 4 gaps. I believe this is the reason SCTP has better performance at 1k packet sizes and 20% noise.

Both TCP and SCTP exhibit behaviors where changing the default tuning parameters, or changing message sizes can dramatically affect performance and throughput. Continued testing an analysis is required to ensure that assumptions made when an implementation is first released still hold over the life of the software. For example, Internet links have improved in bandwidth several orders of magnitude since TCP was first introduced, and the 16 bit TCP sequence number, which was chosen to reduce overhead bandwidth winds up limiting TCP throughput on todays high bandwidth links, which still have latencies similar to the first Internet links. In some cases, due to last-mile links like DSL links with extensive FEC codes, the latencies are even higher.