"Faster than a speeding bullet. More powerful than a locomotive.
Able to leap tall buildings in a single bound---Look! Up in the sky"???
NO...It's not a bird or a plane or Superman---Look out on the Net-- it's SCTP! Stream Control Transmission Protocol is being hyped as one of the Top 10 Hottest Technologies of 2001 by Telecommunications Magazine. According to a marketing blurb accompanying the book,
Stream Control Transmission Protocol (SCTP):A Reference Guide by Randall R. Stewart and Qiaobing Xie,
" SCTP is considered by many to be the TCP of the future....more robust and secure...the technology of choice
for building next-generation commercial grade infrastructures for telecommunications and e-commerce."
To understand this new protocol, it is important to know the lineage of SCTP. The protocol was directly motivated by the need to transport telecommunication signaling messages over an IP-based network. The signaling system SS7 has been the dominant bearer of control information in telecommunication networks where high performance and reliability are critical to existing services and applications. However, the SS7 signaling network is logically a separate network which requires dedicated network infrastructure and only shares some physical resources with regular user traffic. The IETF working group, 'Signalling Transport (SIGTRAN)' is proposing a different approach for the transport of signaling messages: Stream Control Transmission Protocol. Stream Control Transmission Protocol is primarily defined within rfc2960 as a new IP transport protocol existing at the same level as UDP and TCP. In this approach, signaling messages are exchanged over a common packet-switched (IP-based) network instead of a logically separate network but, it is instructive to note, this new protocol has been shaped largely by the fact that telephony signaling has rigid timing and reliability requirements often prescribed by government regulations.
Time to look under the hood! We'll address the questions:
SCTP Core Features.
The primary distinguishing features of this new protocol are "multi-homing" and "multi-streaming". A connection between 2 endpoints in this context is called an "association".
Multi-homing is defined as the ability of an association to support multiple IP addresses or interfaces at a given end point. In its current form SCTP does not do load-sharing. The benefit of multi-homing is potentially greater survivability of the session in case of network failures. Use of more than one address could allow re-routing of packets in event of failure and also provide an alternate path for retransmissions. Endpoints can exchange lists of addresses during initiation of the association. One address is designated as the primary address to receive data. A single port number is used across the entire address list at an endpoint for a specific session. Heartbeat chunks are used to monitor availibility of alternate paths with thresholds set to determine failure of alternate and primary paths.
Multi-streaming does not refer to multiple streams in the TCP sense but rather each stream represents a sequence of messages within a single association--these may be short or long messages which include flags for control of segmentation and reassembly. Stream Identifiers and Stream Sequence numbers are included in the data packet to allow sequencing of messages on a per-stream basis. This can mean that there would be no unnecessary head-of-line blocking between independent streams of messages in case of loss in one stream. SCTP also provides a mechanism for designating order-of-arrival delivery as opposed to ordered delivery.
Comparisons to TCP.
Like TCP, SCTP:
Applications would benefit most that:
Applications would benefit little that:
A. The SCTP library being developed by the Computer Networking Group at the University of Essen (Germany) and Siemens AG (Germany).
SCTP for Beginners by Andreas Jungmaier is a very good place to start to understand SCTP. The online tutorial is well documented giving the important information and links relating to SCTP. Thank you Andreas!
This user-space implementation is multifaceted and consists of:
We wrote an application modeled on the well-known ttcp but using the SCTP library client/server model and raw sockets. Since we are interested in optimizing bulk transfers in high delay/bandwidth networks, we wanted to see how well the implementation performed. Bearing in mind that this is not a kernel implementation so would not be expected to be as optimized for speed and that file transfer has been identified above as an application that would benefit little or none from SCTP's features, we did not find SCTP performed well for bulk transfers.
B. The Linux kernel implementation being developed by La Monte Yarroll (Motorola) and others.
This is still in the development stage and, while we would expect a better performance from a kernel implementation, given the needs of bulk transfer and the key features of SCTP, we do not expect this will provide a great performance improvement over TCP. Since SCTP is block-oriented and not byte-oriented, it should be much easier to do OS-bypass and get better performance.