- IP Networking Basics
- 2 What Is SCTP?
- 3 Motivation for Developing SCTP
- 4 A Short History of SCTP Development
- 5 Major General SCTP Issues Debated in the IETF
- 6 Organization of this Book
- 7 Summary
- 8 Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 A Short History of SCTP Development
Table 1–1 Feature Comparison Between SCTP, TCP, and UDP
|
Protocol Feature |
SCTP |
TCP |
UDP |
|
State required at each endpoint |
yes |
yes |
noa |
|
Reliable data transfer |
yes |
yes |
no |
|
Congestion control and avoidance |
yes |
yes |
no |
|
Message boundary conservation |
yes |
nob |
yes |
|
Path MTU discovery and message fragmentation |
yes |
yesb |
no |
|
Message bundling |
yes |
yesb |
no |
|
Multi-homed hosts support |
yes |
no |
no |
|
Multi-stream support |
yes |
no |
no |
|
Unordered data delivery |
yes |
no |
yes |
|
Security cookie against SYN flood attack |
yes |
no |
no |
|
Built-in heartbeat (reachability check) |
yes |
noc |
no |
1.4.1 Early Works Before the IETF and MDTP
The work that has become SCTP began quite a number of years ago with the realization that TCP had several key weaknesses in dealing with telephone call control. The first realization came in 1991 when a network broke while testing and many minutes transpired before the TCP socket gave an error indication. This was quite unacceptable and began the quest (at least by the authors) to build something better.
Three consecutive works were started by this incident, each experimenting with methods of putting together reliable communications that used UDP. Each one attempted to escape some of the deficiencies of TCP. One of these early implementations used a continual three-way handshake, while another used a modification of this. Each improved on the other until the last, Multi-network Datagram Transmission Protocol (MDTP), began in 1997. After getting most of the general concepts together and having a working implementation, the authors decided to submit it to the IETF for consideration in 1998.
The submission of MDTP coincided with another telephony-signaling-over-IP initiative also being started in the IETF. That initiative resulted in the forming of the SIGTRAN working group in the Transport Area. At that time, the goal of SIGTRAN was to move existing telephone signaling protocols, including ISUP, DSSI, etcetera, onto a pure IP-based network.
The requirements for telephony signaling transport and the modular architecture developed by SIGTRAN found a good fit with MDTP's design concept. This began a host of modifications of the protocol in SIGTRAN, improving and refining the original design.
1.4.2 IETF Refinements
This name change evoked much discussion on the SIGTRAN mailing list as well as within the design team. The name change in many ways was more significant than many thought. It not only symbolized the substantial design improvement that the working group had performed; it signified an expansion of scope and functionality of the protocol. This expansion was what eventually led to SCTP being moved from a protocol running over UDP to one that directly runs over IP.
The following list describes some of the major changes that were invoked by the working group and the Internet Engineering Steering Group (IESG):
Multi-stream concept—The working group made the decision to separate the data reliability function from the message ordering function. This in effect enabled multiple ordered subflows within a single reliable connection and provided a solution to the "head-of-line blocking" problem that the original MDTP design was not able to solve.
Congestion control enhancements—The original MDTP design addressed congestion control incorrectly. The working group corrected this by completely redesigning most parts of the MDTP congestion control function, using both the TCP experiences learned from the past and new research results on TCP congestion control in the IETF and IRTF communities.
Four-way secure association initiation sequence—The original design used a modified three-way handshake initiation sequence similar to that of TCP. This was improved by the working group via the addition of the fourth "leg" to the handshake sequence and the introduction of an encrypted state cookie to fend off potential security attacks.
Selective acknowledgment (SACK) improvements—The SACK function was improved and enhanced from its original design so it more closely paralleled the TCP SACK extension.
Message bundling improvements—The original MDTP message bundling was replaced with a very efficient and flexible chunk-based message bundling mechanism by the working group.
Path MTU discovery—This was added to SCTP by the working group as a mandatory function in order to make SCTP more adaptive to various network conditions.
The large message fragmentation function was redesigned.
Extensibility improved—The chunk-based design and the extension mechanism were introduced to allow the IETF to add new features to the protocol in the future.
An enhancement was made to allow user data to be piggybacked on the third and fourth legs of the initial opening handshake sequence.
After about two years of designing and reviewing and about twenty revisions on the draft document, SCTP finally became an IETF Proposed Standard in October 2000 and was published as RFC2960 (Stewart et al. 2000). Since then, the continued work on SCTP has been handed over from SIGTRAN to the Transport Area working group (TSVWG) in the IETF.
If you would like to plumb the history of SCTP and dig through the 4,000+ e-mails that were generated during SCTP's birth, you can consult the IETF Web pages to find the current pointer to the e-mail archives of both SIGTRAN and TSVWG at http://www.ietf.org.