Performance Evaluation of the Stream Control Transmission Protocol

Transcription

1

2

3 Performance Evaluation of the Stream Control Transmission Protocol Andreas Jungmaier, University of Essen, Institute of Computer Networking Technology, Germany Michael Schopp, Michael Tüxen, Siemens AG, Information and Communication Networks, Munich, Germany Abstract A new protocol which could be used for the transport of telecommunication signalling messages over an IPbased network is currently being discussed within the IETF. The protocol is called Stream Control Transmission Protocol (SCTP). In this paper we shortly describe SCTP and an implementation of SCTP. Furthermore, we evaluate how the protocol performs in an wide area network, especially when competing with TCP. The results were obtained in a test-bed consisting of two local networks which are interconnected via an emulator of a wide area network. 1 Introduction Modern telecommunication networks heavily depend on the fast and reliable exchange of control information. Signalling between different network entities not only supports basic telecommunications services and features but also enables the provisioning of advanced network services like for example IN-based services or mobility management in mobile communication networks. Quality of service criteria (which are directly perceived by the user of a telecommunication service), like e.g. the post-dialing delay in fixed and mobile networks, are strongly influenced by the performance of the signalling system. Over the last two decades, the signalling system number 7 (SS7) [1] has become the dominant bearer of control information in telecommunication networks. Existing services and applications rely on the high performance of SS7. This high performance is mainly due to efficient error control in layer 2 and to signalling specific network management procedures in MTP level 3. However, the SS7 signalling network is logically a separate network which requires dedicated network infrastructure and only shares some physical resources with user plane traffic. In ATM networks, this separation has partly been overcome with the introduction of the Signalling ATM Adaptation Layer (SAAL) [2] where data links between signalling points can be mapped onto VCs over a common ATM core network. SAAL uses SSCOP [3][4] which relies on sequence integrity provided by the ATM layer. IP does not provide such a service, but a modification of SS- COP SSCOP in a Multi-link and Connectionless Environment (SSCOPMCE, [5]), which has been specified by the ITU-T, could be used to transport signalling messages over an IP-based network. In the IETF working group Signalling Transport (SIGTRAN), a different approach for the transport of signalling messages is currently being specified: the Stream Control Transmission Protocol (SCTP) [6]. In this approach, signalling messages are exchanged over a common packet-switched (IP-based) core network, flow control and error control are performed end-toend, and availability is increased by using the concept of a cluster of application server processes (see section 3.2) and by using so-called multi-homed nodes, that is IP hosts for which more than on IP address can be used as destination address. In this approach, user plane and control plane traffic can both be transported over a single IP-based core network. In this paper, we study how user plane traffic (e.g. TCP connections) and signalling traffic (i.e. SCTP data flows) influence each other. The presented results are obtained by monitoring the behaviour of an SCTP implementation which runs in our SCTP testbed. The test-bed contains several TCP/IP and SCTP hosts which are interconnected via a WAN emulator [10]. In section 2, we discuss the features of the new Stream Control Transmission Protocol (SCTP), before in section 3 typical application scenarios and adaptation layers are presented. Section 4 describes the specification structure used as a basis for the implementation, while section 5 presents the experimental setup used to evaluate protocol performance. Finally, we present measurement results which show how the protocol performs in an emulated wide area network. 2 The Stream Control Transmission Protocol Currently, the exchange of signalling messages in an IP-based network is usually performed by either using UDP or TCP. Both of them do not completely match the requirements put on a signalling bearer in a telecommunication network.

4 UDP is message-based and provides a fast connectionless service. This makes it suitable for the transfer of delay sensitive signalling messages. However, UDP only provides an unreliable datagram service. Error control, i.e. sequencing of messages, detection of message duplication and retransmission of lost messages, has to be performed by the application. TCP, on the other hand, provides error control and flow control. However, it has other drawbacks: TCP is byte-stream-oriented. This means that delineation of messages has to be performed by the application and that the end of a message needs to be signalled to TCP by using the push mechanism in order to enforce immediate transfer of the according octets. Many applications only require partial ordering of signalling messages, e.g. of messages belonging to the same call or the same transaction. TCP however delivers data in a strict sequence. This might lead to unnecessary head-of-line blocking and thereby message delay might be increased. A TCP connection is directly identified by a pair of transport addresses (IP address and port number). This prevents transparent support of multihomed hosts. Typical TCP implementations do not allow application specific control of protocol parameters. However, this may be required to adapt the protocol behaviour to the needs of specific signalling applications. On one hand, SCTP enhances the services of UDP and offers a reliable transfer of datagrams. On the other hand, it behaves similar to TCP thereby trying to overcome some of the limitations of TCP. In [6], SCTP is described as follows: SCTP is a reliable datagram transfer protocol operating on top of an unreliable routed packet network such as IP. It offers the following services to its users: acknowledged error-free non-duplicated transfer of user data, data segmentation to conform to discovered path MTU size, sequenced delivery of user messages within multiple streams, with an option for order-ofarrival delivery of individual user messages, optional multiplexing of user messages into SCTP datagrams, and network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and masquerade attacks. SCTP is connection-oriented. However, the concept of SCTP associations is broader than that of TCP connections. Each of the two SCTP endpoints provides one SCTP port number and a list of IP addresses to the other endpoint of the association, so that each association is identified by two SCTP port numbers and two lists of IP addresses. Within an association, congestion control is performed in a way which is similar to that of the TCP congestion control mechanism. Acknowledged error-free non-duplicated transfer of user data is supported by gap reports and selective retransmissions. In this paper, we will show inter alia how TCP and SCTP behave when they compete for the same congested network resources. The protocol has recently been renamed from Simple Control Transmission Protocol to Stream Control Transmission Protocol. The term stream refers to the ability of the protocol to handle several streams of user datagrams per association and to provide in-sequence delivery of these datagrams per stream thereby avoiding head-of-line blocking resulting from a loss in another stream. 3 SS7 Transport over IP 3.1 General framework The general framework for SS7 signalling over IP-networks is described in the informational RFC 2719 [7]. A major application for the SCTP based signalling transport is the transport of ISUP messages between a signalling gateway (SG) and a media gateway controller (MGC). A signalling gateway is a gateway between an SS7-based network and an IP-based network. It handles all MTP-related tasks but has no SS7 user parts. The user parts (typically ISUP) reside within the media gateway controller which communicates with the SG and controls media gateways (MG) via an IP-based network. A media gateway controller can be associated with more than one signalling gateway for redundancy and possibly load sharing purposes. In such a case, the SGs can be viewed from the MTP-based network as signalling transfer points (STPs) and the MGC as signalling endpoint (SEP). Using the signalling gateway it is possible that the MGC transparently communicates with SEPs in the MTP-based network and vice versa. By using the IP-based signalling transport, it is also possible to build service control points (SCP) which have no MTP-protocol stack. In that case, SCCP messages will be transported between a signalling gateway and the SCP.

5 3.2 Application Server clusters Albeit being designed as a general purpose transport protocol overcoming some of the limitations of TCP, the usage of SCTP for transporting signalling information over an IP-based network was one of the main driving forces for its development in the SIGTRAN group. By using multi-homed hosts and the corresponding feature of SCTP it is impossible to meet the stringent reliability requirements of SS7 networks because one has to avoid single points of failure. Therefore the upper layer protocols (ULP) currently being discussed in the SIGTRAN group (see [8] and [9]) use the concept of a cluster of application server processes (ASP). This cluster is called an application server (AS) and the ULP provides the functionality to manage these clusters, i.e. there are messages for taking an ASP out of service, to activate an ASP and so on. Especially, it should be possible to run several ASP of one application server on different hosts. Furthermore it should be possible to perform load-sharing among the ASP of an application server. Considering the example given above, the application server corresponds to an MGC. By using multiple ASPs on different hosts one gets a distributed MGC. 3.3 M3UA an example of an upper layer protocol Adaptation layers are being defined so that the usage of an IP-based signalling transport protocol has no impact on the upper layer interfaces. For example, for transporting ISUP messages over an IPbased network no changes should be necessary for the ISUP. Therefore it was decided to transport primitives. For transporting SCCP and ISUP messages the primitives between MTP Level 3 (MTP3) and the SS7 user parts have to be transported. This is provided by the SS7 MTP3-User Adaptation layer (M3UA) described in [9]. In addition to the M3UA, an adaptation layer for the SS7 MTP2 (M2UA) has been specified as well [8]. M2UA provides transport of primitives between MTP Level 2 and MTP Level 3. Only M3UA is considered in the following. The transported primitives are: 1. MTP-TRANSFER request 2. MTP-TRANSFER indication 3. MTP-PAUSE indication 4. MTP-RESUME indication 5. MTP-STATUS indication These primitives are transported by M3UA messages. It should be noted that the MTP-TRANSFER indication and request are transported using the same M3UA message. This allows the direct communication between MGC without involving a signalling gateway. 4 The SCTP Specification We used SDL as specification language in order to generate a formal specification of the behaviour of an Association Distribution (Upper Layer) Data-Path SCTP Control Path- Management Control-Path Stream-Engine Flow Control/ Error Control Global Variables per Association Bundling Assoc. Distribution Message - Validation Operating System Adaptation Layer (Timer, Network) Figure 1: Overview of the SCTP specification structure

6 Timer expires Resend rcv INIT CookieWait [associate] snd INIT start Timer ABORT rcv INIT send INIT-ACK CLOSED ABORT rcv valid COOKIE snd COOKIE-ACK rcv INIT-ACK send COOKIE restart Timer CookieSent Legend : Action Reaction [Upper Layer Primitive] CONTROL-CHUNK Timer expires Retransmission rcv INIT or INIT-ACK or COOKIE snd DATA data outstanding recv SHUTDOWN data outstanding Shutdown Received Stale COOKIE COOKIE Collision recv SHUTDOWN no data outstanding snd SHUTDOWN-ACK rcv SHUTDOWN Established Shutdown Pending ABORT [shutdown] data outstanding rcv COOKIE-ACK stop Timer snd DATA data outstanding Shutdown Sent [shutdown] no data outstanding snd SHUTDOWN start Timer no data outstanding snd SHUTDOWN start Timer Timer expires resend all DATA acked snd SHUTDOWN-ACK ABORT CLOSED rcv SHUTDOWN-ACK recv SHUTDOWN no data outstanding snd SHUTDOWN-ACK Figure 2: State Overview Diagram of Module SCTP Control SCTP instance. This specification was used as a formal document with a fairly high degree of abstraction and served as basis for our implementation. 4.1 The Specification Structure Our specification structure is based on section 1.3 of the SCTP draft [6]. It decomposes the protocol into functionally separate blocks. This approach proved to be advantageous for structured software development later on (see section 4.3). Additionally, our SDL system overview diagram contains implementation specific blocks, that model the interface to operating system (e.g. timer) functions. As shown in figure 1, an SCTP system instance contains the following modules: 1. Message Validation and Distribution, which validates SCTP datagrams and identifies the according association. 2. Path Management, a module for monitoring the reachability of the different transport addresses of the peer of an association. 3. (De-)Bundling, a module that multiplexes (and de-multiplexes) several data and control chunks of an association into one SCTP datagram which is to be transported within one IP packet. 4. Window- and Flow-Control, the module that implements the TCP-like flow control and congestion avoidance mechanisms. 5. SCTP Control, the module for controlling the states of an association (association startup and take-down, cf. figure 2) 6. Reliable Transfer, a module that buffers outgoing messages until they are acknowledged by the association s peer, and initiates retransmission when necessary. 7. Reception Control, a module that keeps track of all incoming messages and generates the required acknowledgement control chunks. 8. Stream Engine, realizes the in-sequence delivery of user datagrams per stream and performs segmentation and reassembly of large user datagrams when necessary. 4.2 SCTP State Machine In the following, we explain one part of our specification, the SCTP Control module, that maintains the connection state of an association. In the CLOSED state, incoming control chunks as well as connection requests by an upper layer protocol may provoke a change of the state of an association.

7 100 MBit Ethernet 100 MBit Ethernet Host 1 e.g. Multi-homed SCTP endpoint Host 2 e.g. TCP Server NISTNET WAN Emulator Host 3 e.g. SCTP and/or TCP Host 4 e.g. TCP Client Bandwidth limitation Packet Loss Duplication Delay Figure 3: LAN Testbed for Protocol Testing (schematic) The state overview diagram (figure 2) was automatically derived from our SDL specification. It also contains state changes caused by erroneous conditions and unexpected messages. As such, it represents a more complete specification of the behaviour of that protocol component than the state diagram in section 3 of [6]. Shown are conditions and reactions for the transitions between the state CLOSED and the state ESTABLISHED using COOKIE mechanisms, as well as the transitions triggered by the shutdown procedure involving the three states Shutdown Sent/Pending/Received. 4.3 Mapping to Software Modules The implementation has been realized in C on Linux and Solaris workstations, using a standard GNU compiler. Based on the SDL specification, the single SDL blocks were mapped to C modules that communicate using similar interfaces. The communication with the operating system kernel has been encapsulated in an additional module so that operating system dependencies are only located in one place. This consequent mapping has been possible since the specification was generated keeping in mind operating system dependent interfaces as, e.g. timers and socket functions. 5 Results We used an experimental network setup (cf. figure 3), where two subnetworks were interconnected via a Linux router which ran the NIST software network emulator package [10] with the ability of causing adjustable delays, packet loss with a certain probability, duplication of packets, and bandwidth limitations. We tested the SCTP in a set of scenarios using a modified and debugged version of the so-called SCTP reference implementation [11]. We used this implementation, since it is publicly available and has been released by the main authors of the Internet draft. Therefore it can be assumed that other implementations will exhibit a similar behaviour. SCTP associations and TCP connections were usually set-up between hosts belonging to different subnetworks thereby passing the Linux router (WAN emulator). Since the emulator allows introducing parameter sets for individual source/destination address pairs, a multi-homed host may indeed have different network transmission characteristics for each of its transport addresses. A typical problem situation for protocols occurs when an endpoint is experiencing network congestion due to a congested link. In such a case, buffers of the access router to the congested link are filling up, leading to increasing packet delays and/or packet losses. Though the NIST network emulator [10] does not provide a perfect model for a bandwidth-limited link due to its implementation, the effects on the traffic can be effectively simulated by setting respective parameters (i.e. limiting bandwidth and adding a certain link delay). In the following sections we will present some results of our investigations. We will compare TCP behaviour and SCTP behaviour. We will use the terms SCTP association and SCTP connection interchangeably, in order to align the terminology with that of TCP. 5.1 Looking at a single SCTP association In order to check the basic functionality of SCTP, we send a large bulk of user datagrams within a single association from one host to another over the WAN

8 limit SCTP (100 Bytes) SCTP (1376 Bytes) TCP 80 Throughput [kb/s] Delay [ms] Figure 4: Flow control over a bandwidth-limited link emulator which emulates in both directions a lossfree bandwidth-limited link of 100 kbyte/s (link layer payload) with an additional fixed delay. SCTP multiplexes control and user data into IP packets whose size is close to the MTU size of 1500 octets. We use the order-of-arrival delivery option and measure the mean rate at which user datagrams arrive at the receiver. Figure 4 shows the results for different values of the fixed delay between the hosts and for different SCTP user datagram sizes (100 Byte and 1376 Byte). The different user datagram sizes result in different overhead per user byte. Independent of the user datagram size, user datagrams arrive at exactly the rate at which the 100 kbyte/s link has a utilization of 1, when the delay is small. As the product of link rate and round trip time (RTT) surpasses the initial receiver window size of 32 KByte, the throughput is limited by 32 KByte/RTT. A TCP connection shows a similar behaviour over such a link. In fact, any protocol with a limiting receiver window size should exhibit this behaviour. In figure 4 we also show the theoretical behaviour of an ideal protocol which has no overhead. 5.2 Two competing protocol instances SCTP congestion control was designed similar to that of TCP with the goal to assure that SCTP does not behave more aggressively than TCP. In order to test the behaviour of SCTP when competing for a limited resource, we sent the traffic of two saturated sources over a loss-free, bandwidth-limited link of 100 kbyte/s (link layer payload) with an additional fixed delay of 50 ms. In a first configuration we studied two competing SCTP connections (i.e. associations) where for both connections the user data chunks (of size 100 byte) were multiplexed in large IP packets. In a second configuration, one connection produced large IP packets whereas for the second connection, the protocol option no-bundling was enabled, leading to small IP packets. In a third and in a fourth configuration, large TCP/IP packets competed with large SCTP/IP packets and with small SCTP/IP respectively. We observed that independent of the configuration, the two connections always shared the link equally in terms of link layer load. Figure 5 illustrates this. The throughput of a single SCTP connection is traced over the time. Without competition the achieved throughput is equal to the maximum throughput over a 100 kbyte/s link (taking the SCTP overhead for 100 byte user data chunks into account). At some point in time, another SCTP connection is established over the link for the duration of approximately 90s. During the existence of that connection, the achieved throughput of the observed SCTP connection falls to almost exactly half of its original value and the new connection achieves approximately the same throughput, i.e. the link is equally shared. From this we conclude that neither SCTP with large IP packets nor SCTP with small IP packets can achieve a throughput different from that of a TCP connection. This means that SCTP is neither more nor less aggressive than TCP. The introduction of an additional SCTP association into a TCP/IP network with established TCP connections does not affect the

9 100 SCTP (100 Bytes) SCTP max. throughput (100 kb/s link) SCTP max. throughput (50 kb/s link) 80 throughput [kb/s] time [s] Figure 5: Two competing connections sharing a link SCTP (1130 Bytes) Limit SCTP Throughput in [Bytes/s] Number of concurrent TCP connections Figure 6: One SCTP connection and n TCP connections sharing a link throughput of these connections more than the introduction of an additional TCP connection. 5.3 Bandwidth sharing between several connections Signalling traffic over an SCTP connection might require a certain bandwidth. We use a (non-saturated) SCTP user datagram source which creates datagrams at an approximate rate of 30 kbyte/s. We send this traffic within a single SCTP association over a lossless bandwidth-limited link (again with 100 kbyte/s and an additional fixed delay of 50 ms) together with the traffic of up to n greedy TCP sources. Figure 6 shows the throughput of the SCTP connection for different values of n. We find that as long as the SCTP sender does not need more than a share of -th of the link bandwidth (shown in the figure as limit ), it gets the required throughput. In this case, the remaining bandwidth is equally shared between the n greedy TCP connections. Otherwise, each connection, no matter if it is an SCTP association or a TCP connection, gets -th of the link bandwidth. From this follows that multiplexing of several

10 streams into one association results in a less aggressive behaviour than opening one association per stream, which would be a typical TCP usage. Furthermore, the results imply that in an engineered IP-based signalling network, managing the number of associations (connections) per link, could guarantee a well-defined minimal throughput per connection. In an environment where SCTP associations are established in a controlled way and exist for a rather long time, e.g. for signalling transport, network planning should exploit this behaviour. 6 Conclusion We have shown that SCTP traffic has the same impact on TCP traffic as normal TCP traffic. This leads to the conclusion that the introduction of this new protocol into a TCP/IP network does not degrade the performance of the existing protocols. Furthermore, we have seen that TCP and SCTP connections share resources equally and that this behaviour can be taken into account in an engineered IP-based signalling network. SCTP was developed to transport signalling traffic. Protocol features like selective acknowledgements, fast retransmissions and out-of-order delivery were incorporated in order to enable the protocol to match the high performance requirements put onto a signalling system. However, it is not yet clear if SCTP can meet these requirements. This issue will be investigated in further studies. References [1] ITU-T Recommendation Q.700: Introduction to CCITT Signalling System No. 7, International Telecommunication Union, Geneva, March [2] ITU-T Recommendation Q.2100: B-ISDN Signalling ATM Adaptation Layer (SAAL) Overview Description, July [3] Henderson, T.R., Design principles and performance analysis of SSCOP: a new ATM Adaptation Layer protocol, Computer Communication Review (1995) vol. 25, no. 2, pp [4] ITU-T Recommendation Q.2110 (07/94) B- ISDN ATM adaptation layer Service specific connection oriented protocol (SSCOP), July [5] ITU-T Recommendation Q.2111 (12/99) B- ISDN ATM adaptation layer Service specific connection oriented protocol in a Multi-link and Connectionless Environment (SSCOPMCE), December [6] Stewart, et al.: Stream Control Transmission Protocol, Internet Draft (work in progress), draft-ietfsigtran-sctp-08.txt, Signaling Transport Working Group, April 2000 [7] Ong, L., et al.: RFC 2719 Framework Architecture for Signaling Transport, The Internet Society, 1999 [8] Morneault, K., et al.: SS7 MTP2-User Adaptation Layer, Internet Draft (work in progress), draft-ietf-sigtran-m2ua-03.txt, Signaling Transport Working Group, March 2000 [9] Sidebottom, G., et al.: SS7 MTP3-User Adaptation Layer (M3UA), Internet Draft (work in progress), draft-ietf-sigtran-m3ua-02.txt, Signaling Transport Working Group, March 2000 [10] Carson: NIST Network Emulation Tool, June 1998 [11] SCTP Reference Implementation, Version 2.1.0, ftp://standards.nortelnetworks.com/sigtran/sctpref tgz, Cisco and Motorola, 1999.