Prioritized SCTP streams

Kandha K. Sankarapandian

Introduction

Stream Control Transmission Protocol (SCTP) is a relatively new transport protocol. This reliable, message-oriented protocol provides multiple streams between endpoints and transport-level support for multihoming. It was originally designed for transport of telephony signaling across the Internet in the lines of SS7, but it also provides some features that many applications could take advantage of. SCTP provides a number of advantages over TCP/UDP. Here are a few Security: SCTP has inherent mechanism for prevention of connection hijacking, and denial of service attacks like SYN flooding. The encrypted cookie lies at the core of SCTPs security. The 32-bit CRC coupled with the Heartbeat mechanism makes SCTP more robust. Multi-streaming: An SCTP association (or loosely speaking a connection) can have multiple streams, each of which defines a logical channel. The flow and congestion control are still on a per association basis, however. Streams can be exploited, for example, to accord higher priority to control messages over data messages and for other purposes. However, inter-stream priority is currently not a standard feature. Flexible ordering: Each SCTP stream can be designated for an in-order or immediate delivery to the upper layer. Unordered delivery reduces latency, which is often more important than strict ordering for transactional applications. Multi-homing: An SCTP association can specify multiple "endpoints" on each end of the connection, which increases connection level fault tolerance (depending on available path diversity). Extensibility: The key to SCTPs extensibility is the chunk feature. Each SCTP operation (data send, heartbeat send, connection init) is sent as a chunk with its own header to identify such things as type, size, and other parameters. New chunk types can be introduced to provide new capabilities, which make SCTP quite extensible.

SCTP has its share of pitfalls some of which are, Performance: The implementations for SCTP are not as mature as TCP. Even though the IETF document specifies one SACK for every two packets, the implementation effectively sends one for every packet to notify changes in rwnd. Efficiency: The lksctp implementation for Linux has further issues in terms of dynamic memory management. On a side note, the 32 bit CRC amounts to

considerable share of processing and there is no hardware support for offloading it. The lksctp project 1 is an implementation of SCTP in the Linux Kernel. The SCTP configuration has been added on an experimental basis in the 2.6 kernel tree. The lksctp architecture2 consists of two key components, the state machine and the smart pipe. The master state function sctp_do_sm looks up the state function, runs it and then processes the side effects. At the user level, the lksctp-tools provide the libraries and header files required for SCTP development.

CM over SCTP

SCTP supports two types of sockets. A SOCK_STREAM socket type for TCP like one to one communication and a SOCK_SEQPACKET socket for one to many communication roughly analogous to UDP. The SOCK_STREAM socket type facilitates easy migration from existing TCP based applications. To illustrate this, we consider the Connection Manager (CM)3, a multi transport messaging middleware developed at Georgia Tech. Since the function signature for SCTP socket API closely resembles that of TCP, a simple LD_PRELOAD hack can be used to make CM run over SCTP without any changes to the source code. The withsctp script for this hack sets the preload library to the one provided with lksctp-tools and runs the application. To run the demo, start the PBIO 4 Format Server using withsctp. Follow the same procedure for starting the
cmdemo

server and the cmdemo client. Now the client-server interactions occur over SCTP.

This involves the four-way handshake for connection establishment and using default parameters for SCTP specific parameters like the number of streams. To gain significant

1 2

http://lksctp.sourceforge.net/ http://old.lwn.net/2001/features/OLS/pdf/pdf/sctp.pdf 3 http://www.cc.gatech.edu/systems/projects/CM 4 http://www.cc.gatech.edu/systems/projects/PBIO

advantage over TCP, these parameter will have to be tweaked which translates to source level modifications.

Stream Priority

SCTP defines a connection between two end points as an Association. The end points may be multihomed. An Association consists of multiple streams of communication. lksctp provides ten streams by default for each association. This value may be changed during connection initialization using the INIT_MSG socket option. The lksctp-tools library provides wrapper functions for the standard socket API functions to ease the work of the developer. Using these functions, the application can specify send and receive parameters at the association level and also at the message level. On the sending side, parameters like the default stream, time to live etc can be specified by either setting the appropriate socket option (SCTP_ASSOCINFO) or by specifying them in the sctp_sendmsg function call. On the receiving side, the application can register for

sctp_data_io_event

notification to obtain these parameters. The Event notification

mechanism provides useful call back functionality for transport level events. The SCTP streams were designed to solve the head-of-line blocking problem of TCP. However it can be extended to support application specified priorities. The concept of inter-stream priority has been studied before5 but it involved addition of new functions to the socket API. The modifications to lksctp for the Prioritized SCTP functionality can be described under the User level and the Kernel level. 3.1 User Level At the user level, the functionality can be classified under Priority Initialization, Adjustment and Destruction. The sctp_assocparams structure has been modified to include members for specifying the stream priority options.
struct sctp_assocparams { sctp_assoc_t sasoc_assoc_id; __u16 sasoc_asocmaxrxt; __u16 sasoc_number_peer_destinations; __u32 sasoc_peer_rwnd; __u32 sasoc_local_rwnd; __u32 sasoc_cookie_life; __u16 sasoc_equal_priority_stream_start; __u16 sasoc_equal_priority_stream_end; __u8 sasoc_set_priority; __u8 sasoc_unset_priority; };

Priorities In Stream Transmission Control Protocol Multistreaming - Gerard J. Heinz II Univ Delaware

The Association parameters are specified using the socket option SCTP_ASSOCINFO. The
sasoc_set_priority and sasoc_unset_priority

variables are used to initialize/

destroy priority among the streams. The stream priority is assigned to be the same as the stream number by default. The
sasoc_equal_priority_stream_start and

sasoc_equal_priority_stream_end

are used to adjust the stream priorities. All

streams within the specified window are set to equal priority and the remaining stream priorities are adjusted accordingly. 3.2 Kernel Level At the kernel level, the corresponding sctp_assocparams structure is modified to include these additional members. The SCTP socket layer functionality, in particular the sctp_setsockopt_associnfo function is modified to perform stream priority initialization, adjustment and destruction. If the Association is already established, the priority options are applied to the existing streams. Otherwise, the priority options are applied to the end point and will affect any future association involving that end point. To specify the stream level priorities, the sctp_stream structure is modified as follows.
struct sctp_stream { __u16 *ssn; unsigned int len; __u16 priority; };

During stream initialization all the streams are set to a priority of 0 so that the Priority SCTP behaves in the same way as normal SCTP if priority is not set. When priority has been enabled for an association, the queuing of data chunks enter a different state from the normal stream. The sctp_outq_tail_data function queues the data chunks using the use of the list_add_tail kernel API function. In the Priority scenario, the chunks are queued using a priority queue mechanism implemented in the list_add_pqueue function. This involves reflecting back on the association and the stream to which the particular chunk belongs and determining the position of the chunk in the out queue based on priority. These queued data chunks form an SCTP packet and they are handed over to the IP layer through the sctp_packet_transmit function. Since these priority modifications affect only the sending queue, a server running on top of Prioritized SCTP can transparently communicate with a client running normal SCTP.

SCTP MPEG Streaming server

MPEG-4 encodes the video bit stream in groups of different frame types (I, P and B frames) where the I-frame (Inter Video Object Plane) is independent, while the P (Predicted) and B (Bidirectional Interpolated) frames depend on the I-frame in the group. This means that loosing an I-frame (for example due to network congestion) causes a noticeable worsening of the video quality of all the frames in the group. There is a lot of research to improve the quality of video streams like the Selective Reliability RTP 6 . Further proposals7 have been made to utilize the partial reliability feature of SCTP8. This framework can be further tuned with the introduction of priority among the streams. The I-frames are placed in the highest priority stream, the P-frames in a lower priority stream and the B-frames in the lowest priority streams. The effect of priority on the streams is studied under a simulated environment of a multi threaded Prioritized SCTP based MPEG streaming server (mpeg_server) and a normal SCTP MPEG client (mpeg_client). For this simulation we use an ascii file geneterated using the mpeg_file program. This program generates a file of given size and fills it with a random choice of I, P and B frames of a predefined frame size. This can be approximated to the data section of an MPEG file given that there is no correlation between the MPEG-4 video produced by various implementations Divx and Xvid. Further more real world data loss and delay characteristics are simulated using the netem module9 of the Linux QOS packet scheduler. The netem module parameters are adjusted using the tc utility include with iproute2 10 . Prioritized and normal SCTP behaved comparably under network delay conditions. However with the addition of unordered delivery at the SCTP layer, the client experienced a higher data rate for the I-frames in comparison with P and B frames. Similarly with increasing data loss ratio, the prioritized SCTP was able to achieve a lower I-Frame loss count in conjunction with the unlimited life time and retransmission parameter set to the stream.

5.1
6

Experiment Setup

Nicholas Feamster. Adaptive delivery of real-time streaming video. MIT 2000. Using SCTP with Partial Reliability for MPEG-4 Multimedia Streaming - M. Molteni and M. Villari Cisco System Technology Center, France 8 http://www.ietf.org/rfc/rfc3758.txt 9 http://linux-net.osdl.org/index.php/Netem 10 http://linux-net.osdl.org/index.php/Iproute2

The experiment uses two identical Netlab nodes running Linux 2.6.14 kernel, one of them (calvin) running the priority enabled SCTP and the other (hobbes) running the stock version of SCTP. The nodes are connected by a 100Mbps link. The simulation is carried out with a MPEG streaming client-server model. An MPEG file is generated with variable number of I, P and B frames each of a fixed frame length. Prioritized SCTP calculations are done with the server running on calvin and client running over hobbes. For the reference SCTP measurements, the server is run on hobbes and client on calvin. This is based on the fact that priority modifications are made only on the outgoing traffic. Delay and Data loss characteristics are shaped with the help of netem module. The Data rate measurement is made by running a clock between arrivals of the first frame of a particular type till the last frame of that type is received. Similarly the Data loss characteristics are computed for each frame type. The Frames have a finite retransmission timeout after which, the frames are dropped and the timeout value is decreasing for I, P and B frames in that order. An MPEG file of 1mb size containing the following frame counts was used. I-Frames: 406 P-Frames: 304 B-Frames: 314 Each frame is 1024 bytes long.

5.2

Results:
Table 1: Data rate in Frames per second SCTP I-Frame P-Frame 0ms 1255.985 891.219 100ms 130.927 98.042 10ms 510.029 383.877 100-10ms 134.235 101.592 Delay Prioritized SCTP B-Frame I-Frame P-Frame B-Frame 916.485 1201.114 870.237 915.745 94.484 245.334 90.014 155.178 394.415 590.141 380.093 303.115 93.106 365.934 120.023 90.005

The table indicates the data rate of I-Frames is much better with Prioritized SCTP under network delay conditions. Table 2: Data Loss in number of Frames Loss SCTP Prioritized SCTP

I-Frame 0% 0 1% 2 10% 2

P-Frame 0 1 7

B-Frame 0 3 12

I-Frame 0 0 0

P-Frame 0 1 10

B-Frame 0 4 15

The table indicates, no I-frames are lost due to their higher priority and timeout value.

Future Work

Here are some feature additions that may be worked into the current implementation of SCTP to make it suit our needs better. Customizations for better coordination between the application and SCTP stack. The event notification mechanism may be extended to provide a call back mechanism for the application to read into the kernel data. Routing decision based on priority. Simultaneous transmission across multi-homed interfaces to improve throughput. Currently the streaming feature is not architected for much parallelism. Calculate Packet loss rate and bandwidth measurement at transport level.

References
SCTP Tutorial - http://www.sctp.org/SCTP_tutorial.ppt UNIX Network Programming Volume 1, Third Edition: The Sockets Networking API By W. Richard Stevens, Bill Fenner, Andrew M. Rudoff Stream Control Transmission Protocol: The design of a new reliable transport protocol for IP networks, Masters thesis by Ivan Arias Rodriguez An Introduction to SCTP - http://www.ietf.org/rfc/rfc3286.txt Stream Control Transmission Protocol - http://www.ietf.org/rfc/rfc2960.txt SCTP for beginners - http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/index.html