- 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.5 Major General SCTP Issues Debated in the IETF
1.5.1 Do We Really Need a New Transport Protocol?
To provide large-scale commercial telephone services, a reliable way of transporting telephony signaling messages across IP networks had to be defined first.
People from the telephone industry, the so-called Bell heads, were well aware of the stringent timing and reliability requirements of transporting telephony signaling messages and had specifically created the Signaling System No. 7 (SS7) network to meet those requirements. They had serious doubts about whether TCP, the only reliable data transport protocol in the IP world, was up to the task.
A team led by Telcordia (formerly Bellcore) engineers was formed in SIGTRAN to investigate the adequacy of using TCP/IP to transport telephony signaling. They came to the conclusion that the main problem with using TCP/IP for providing commercial-grade telephony signaling was the lack of control over the TCP retransmission timers. Some of the working group members quickly pointed out that this lack of user-level timer control was merely an implementation problem of the TCP stack, instead of a limitation on the protocol itself.
However, the analysis also pointed out that the "head-of-the-line blocking" imposed by TCP was also an issue. In high call-volume application scenarios, such as call processing centers, this "head-of-the-line blocking" could become a major problem due to delays imposed on user messages waiting at the receiver for a lost TCP segment to arrive. These delays would impose a domino effect on all calls, escalating the delay to an unacceptable level.
With the submission of MDTP and the ensuing discussions, the working group also quickly agreed on another major shortcoming of TCP: its lack of path-level redundancy support. This was viewed by many telco engineers as a major weakness of TCP/IP compared to SS7, because the latter was designed with full support of link-level redundancy. (For example, in the field, the data connection between two SS7 signaling nodes is often deployed over a set of physical T1 links, commonly referred to as a link-set, that may consist of up to 16 separate T1s, thus providing considerable link redundancy.)
Because of its packet-switched nature, a connection in an IP network normally does not confine itself to a specific physical link. Rather, what is equivalent to a link in the circuit-switched SS7 network is a path in an IP network. In order to achieve a degree of link-level fault resilience similar to that offered by the SS7 network, the working group reached the consensus that the IP transport protocol for telephony signaling must provide support for path redundancy.
There were also concerns that the three-way handshaking procedure used during the TCP setup might introduce too much delay at call setup.
The option of modifying or enhancing TCP to meet those new requirements was briefly discussed in the working group but was quickly abandoned. The working group was hesitant to take that approach, probably because other similar IETF investigations on transport issues—for example, the Requirements for Unicast Transport/Sessions (RUTS) BOF7 and the Support for Lots of Unicast Multiplexed Sessions (SLUMS) BOF—had already pointed out the difficulty of modifying TCP.
In the end, the working group reached the conclusion that a new transport protocol that would run over UDP was needed. MDTP was adopted as the baseline design of the new protocol. The working group also decided to insert a signaling protocol adaptation layer between the new transport protocol and the telephony signaling protocols. This decision effectively separated the transport function from any specifics of the upper-layer telephony signaling protocols. This separation paved the way for further transformation of MDTP into a generic IP transport protocol.
1.5.2 Over UDP Versus Over IP
The work on MDTP had been moving forward smoothly and the protocol design was becoming stable when the working group received word from the IETF Transport Area Directorate in December 1999 that some important design decision should be revisited. The TAD had been discussing whether to change the new protocol (renamed SCTP already) to sit directly over IP instead of over UDP.
Soon afterward the IESG and the TAD made the recommendation of moving SCTP to run directly on top of IP. The reason was that the IESG and the TAD saw the value and significance of the new protocol and recognized the great potential of SCTP becoming a major transport protocol. SCTP was thought to be useful to a much wider range of applications than telephony signaling transport. Moving SCTP directly over IP with its own port number space was viewed as the architecturally correct solution.
Initially the working group was very reluctant to accept this recommendation. The main concern was that this change would almost certainly mean that SCTP would have to be implemented in the operating system kernel. It would normally take most operating system vendors a long time, up to several years in some cases, to make a new protocol commercially available in their operating system kernels. It was thought that the telephone industry just could not wait that long for the SIGTRAN protocol. In addition, some were concerned that to have the protocol sitting in the operating system kernel would make it much harder to keep tight control over the retransmission timers. Without this control, the stringent timing requirements of telephony signaling would be difficult to meet.
However, the IESG insisted that the working group should look at the bigger picture beyond signaling transport as well. The long-term benefits of putting SCTP in an architecturally correct position in the IP stack far outweighed the short-term deployment delay the change would incur on the telephony signaling transport applications. Eventually the working group agreed.