Computer Networks 54 (2010) 1418–1425
`
`Contents lists available at ScienceDirect
`
`Computer Networks
`
`j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / c o m n e t
`
`A transmission control SCTP for real-time multimedia streaming
`Kyung-Hoe Kim a, Kwang-Min Jeong b, Chul-Hee Kang a, Seung-Joon Seok c,*
`a Dept. of Electronics and Computer Engineering, Korea Univ., Anam-dong, Sungbuk-gu, Seoul 136-701, Republic of Korea
`b Samsung Electronics, Co. Ltd., 416 Maetan-dong, Yeongtong-gu, Suwon-si, Gyeonggi-do 443-742, Republic of Korea
`c Dept. of Computer Engineering, Kyungnam Univ., 449 Wolyong-dong, Masan-si, Kyungnam 631-701, Republic of Korea
`
`a r t i c l e
`
`i n f o
`
`a b s t r a c t
`
`Article history:
`Received 31 October 2007
`Received in revised form 3 September 2009
`Accepted 30 November 2009
`Available online 11 December 2009
`Responsible Editor: Prof. Qian Zhang
`
`Keywords:
`SCTP
`Multimedia streaming
`Partial reliability
`
`1. Introduction
`
`Transmission control protocol (TCP) is a transport layer
`protocol that is widely used for various Internet applica-
`tions, e.g., World Wide Web (WWW), email, and file trans-
`fer. However, the retransmission scheme in TCP is not
`appropriate for multimedia streaming applications be-
`cause it can increase the end-to-end delivery latency.
`Therefore, user datagram protocol (UDP) is a commonly
`used transport layer protocol for multimedia streaming
`applications. UDP does not employ any flow control
`schemes in response to network congestion, and therefore
`it can burden other users on the network and, ultimately,
`lower its service quality [1].
`To overcome this limitation, real-time transport proto-
`col (RTP) and real-time control protocol (RTCP) can be
`adopted on the top of UDP in multimedia stream applica-
`tions [2,3]. That is, the RTP/RTCP layer supplements the
`functions of UDP by correcting out of order data and
`controlling the volume of data transmitted by senders for
`
`* Corresponding author. Tel.: +82 11 255 7693; fax: +82 55 248 2554.
`E-mail addresses: kyunghoe@widecomm.korea.ac.kr
`(K.-H. Kim),
`sjseok@kyungnam.ac.kr (S.-J. Seok).
`
`1389-1286/$ - see front matter Ó 2009 Elsevier B.V. All rights reserved.
`doi:10.1016/j.comnet.2009.11.014
`
`Multimedia streams over the Internet have a strict playback delay time, i.e., multimedia
`data arriving after the playback time cannot be played by the receiver and they are dis-
`carded. In this paper, we introduce a transmission control SCTP (TC-SCTP) which has a
`transmission control sub-layer (TCSL) in which the multimedia streaming server deter-
`mines whether data can be played in the receiver before sending the data and decides
`whether to send data messages or not. In addition, TCSL employs differentiated retransmis-
`sion policy depending on the type of multimedia. We evaluate the performances of SCTP,
`partial reliability (PR)-SCTP, and TC-SCTP via ns-2 simulator. The simulation results dem-
`onstrate that the TC-SCTP protocol can decrease the amount of transmissions and increase
`the video decodable ratio, compared with other protocols.
`Ó 2009 Elsevier B.V. All rights reserved.
`
`congestion control. However, these actions rely on periodic
`reports between the sender’s and receiver’s RTCP, they
`cannot control by packets nor respond actively to network
`conditions.
`A new transport layer protocol, stream control trans-
`mission protocol (SCTP) has been proposed by Internet
`Engineering Task Force (IETF SIGTRAN Working Group.
`Although it was first developed for telephone signaling, it
`is gradually expanded into a general-purpose transmission
`layer, and it has been standardized as RFC 2960 in 2000 [4].
`Like TCP, SCTP provide reliable service and flow control
`mechanisms. In addition, similar to UDP, it can support
`unreliable transmission [5]. SCTP can provide multi-stream
`and multi-homing services for a single connection. In par-
`ticular, it can differentiate the level of reliability provided
`to messages, which is called SCTP partial reliability (PR-
`SCTP) [6]. PR-SCTP has the function of setting the reliability
`level for specific messages. The preset reliability level is
`used to determine the timing when the retransmission of
`specific data message is stopped. The function can be effec-
`tively applied to traffic containing different types of data,
`such as I, P, B frames in MPEG streaming applications.
`However, PR-SCTP attempts transmission at least once
`even for messages that do not require any retransmission
`
`Sportradar 1034
`Page 1
`
`

`

`K.-H. Kim et al. / Computer Networks 54 (2010) 1418–1425
`
`1419
`
`if
`In addition,
`due to the stringent delay constraint.
`retransmission is given up, it has to send a Forward-TSN
`Chunk to the receiver.
`Recently, multimedia streaming protocols are required
`to control its sending rate in response to the congestion
`condition of network [9–12,17–19]. It is because non-
`responsive streaming to network congestion, such as
`UDP, starves TCP flows under congestion condition. In this
`paper, we propose to use SCTP’s congestion control for
`multimedia streaming.
`Real-time data must reach the receiver within the toler-
`able playing time. Thus, a protocol like TCP, aiming for full
`reliability, cannot be used because a retransmission delay
`can exist. However, its alternatives, such as UDP and the
`combined UDP + RTP, do not attempt retransmission for
`lost packets. In this case, even if there is a chance for
`retransmission, based on the maximum playing time, they
`do not retransmit lost data. Considering this problem, the
`present study explains a multimedia data transmission
`protocol which is a modification of PR-SCTP.
`In this paper, we introduce a sub-layer, called as trans-
`mission control sub-layer (TCSL), between PR-SCTP and the
`application layer. The TCSL sub-layer maintains as many
`buffers as the number of data types, and stores messages
`from the transmission server depending on the type. After
`that, TCSL of TC-SCTP evaluates the necessity of transmis-
`sion before transmission. If the message does not need to
`be sent, it is simply removed. Compared with PR-SCTP with
`the fixed reliability level, TC-SCTP can dynamically con-
`sider network condition in each packet transmission.
`The rest of this paper is organized as follows. Section 2
`reviews existing video data transmission protocols. Section
`3 describes a proposed scheme for streaming multimedia
`data, called TC-SCTP. Section 4 evaluates the performance
`of TC-SCTP and Section 5 concludes this paper.
`
`2. Existing protocols for streaming multimedia data
`
`As mentioned above, PR-SCTP can differentiate its
`retransmission service for each message. Differentiated
`retransmission can be achieved by applying different
`retransmission limits depending on the data type, e.g., de-
`lay-sensitive data and delay-tolerable data. The differenti-
`ated retransmission policy in PR-SCTP can be applied to
`MPEG-type video transmissions. In order to differentiate
`the reliability of each frame in MPEG video transmissions,
`[7,8] restrict the number of transmissions according to the
`type of frame to be transmitted. For example, only one
`retransmission is allowed for I frames and P frames with
`stringent end-to-end delay bound because additional
`retransmissions are not necessary due to excess playing
`time. On the other hand, no retransmission is provided
`for B frames because losses of B frames do not have any
`significant effects on the quality of video streaming. In this
`mechanism, each frame data is retransmitted only once or
`not retransmitted at all. However, because all data have to
`be transmitted at least once, if the network is congested,
`data may be queued for a long period of time, which may
`in turn lower the overall performance of the video trans-
`mission. Moreover, when the retransmission is given up,
`
`the information on the corresponding packet should be
`delivered to the receiver using forward TSN, which takes
`a long one-way trip time, and may cause faster retransmis-
`sion than required, resulting in a reduction of the size of
`cwnd (congestion window). Furthermore, if the volume
`of network traffic is small and delay characteristics are
`favorable, the quality of video transmission is lower than
`the case where the number of retransmissions is not
`restricted.
`Like [7,8], Media-SCTP [5] also restricts the number of
`retransmissions according to the frame reliability. Media-
`SCTP assumes that MPEG frames belonging to the same
`GOP have the same playout deadline. Because each GOP
`is composed of the same number of frames, the playout
`deadline appears at a regular interval. The receiver’s frame
`dropping filter compares the current time with the playout
`deadline for each retransmitted frame. The difference be-
`tween the two points of time is the time allowed for
`retransmission. Because it takes around 0.5 round trip time
`(RTT) in average for the retransmitted frame to be deliv-
`ered from the sender to the receiver, the frame dropping
`filter compares the time allowed for retransmission with
`0.5 RTT. If the allowed time is longer than 0.5 RTT, the cor-
`responding data is retransmitted. If not, the receiver sends
`the Forward-TSN chunk to the sender so that the corre-
`sponding data chunk should not be retransmitted. On
`receiving the Forward-TSN, the sender takes an action to
`prevent the time-out of the corresponding data and the
`consequent reduction of the congestion window. That is,
`Media-SCTP’s receiver side decides data retransmission
`only when the playback time of the data remains more
`than 0.5 RTT regardless of the type of the data frame. In
`the proposed TC-SCTP, however, the differentiated retrans-
`mission restricts the maximum number of retransmission
`in the consideration of remaining time of data frame until
`its playback and of data frame type.
`Ahmed and co-workers [13,14] propose a sub-layer
`above RTP which is referred to as MP-RTP. Like Media-
`SCTP, MP-RTP’s receiver side has responsible for retrans-
`mission request and also sender side considers frame’s life-
`time before sending low priority frame. However, high
`priority frame is retransmitted through all available path
`simultaneously. In this paper, proposed TC-SCTP control
`sending multimedia data according to data types. TC-SCTP
`does not request any receiver’s message for retransmission
`and based on SCTP’s multi-streaming properties, not multi-
`homing’s.
`Wu et al. [15] introduce six special issues about Internet
`streaming video. Application-layer QoS control issue of
`these issues is classified into congestion control and error
`control. In particular, this paper introduces a Delay-Con-
`strained Retransmission as an application layer error con-
`trol method. This Delay-Constrained Retransmission is
`similar mechanism to Media-SCTP [5,13,14].
`In this
`scheme, receiver’s application requests packet retransmis-
`sion and sender’s application retransmits the lost packet
`when arrival in time for display is expected.
`The RaDiO in [16] determines which packets to select,
`when to transmit and how to transmit to minimize de-
`coded video distortion at the receiver. This algorithm is a
`general scheme for data transmission and is mainly based
`
`Sportradar 1034
`Page 2
`
`

`

`1420
`
`K.-H. Kim et al. / Computer Networks 54 (2010) 1418–1425
`
`on loss probability. Also RaDiO considers playback dead-
`line on scheduling decision and decoding dependency of
`individual packets with relative priority. This algorithm
`treats the rate distortion at encoding level but the TCSL
`that we proposed in this paper is controls the (re) trans-
`mission at transport layer level.
`
`3. Proposed Transmission-Control SCTP (TC-SCTP)
`
`In real-time video transmission techniques using the
`existing PR-SCTP, the retransmission function is differenti-
`ated depending on the importance of data chunk. That is,
`by restricting the number of retransmissions for each data
`chunk, it prevents unnecessary retransmissions. However,
`PR-SCTP is regardless of the condition of network conges-
`tion, so its performance is usually low in dynamically
`changing network environments. Moreover, PR-SCTP
`forces to transmit each data chunk at least once even under
`network congestion.
`The goals of this work are to minimize unnecessary
`transmission and to adapt network. In general, it is not ex-
`pected for all transmitted data to meet the restrict delay
`constraint in video transmission. Data that have been
`transmitted but failed to meet the delay time constraint
`can be discarded without affecting the receiver’s video
`playing. Although the occurrence of such unnecessary
`transmissions may not worsen the network situation, with
`it we cannot expect any active improvement in the net-
`work situation. Thus,
`in order to prevent unnecessary
`transmissions and to improve network condition, we need
`a technique where the sender omits data with short mar-
`ginal time, for transmission in advance, and sends the fol-
`lowing data promptly. Consequently, we introduce a
`Transmission Control-SCTP (TC-SCTP) as transport layer
`protocol at sender side.
`
`3.1. TC-SCTP
`
`TC-SCTP is located at transport layer between an appli-
`cation layer and a network layer and composed of Trans-
`mission Control sub-layer (TCSL) and PR-SCTP sub-layer.
`Fig. 1 shows the position and architecture of the TC-SCTP.
`The TCSL intercepts video data incoming form the upper
`layer toward PR-SCTP sub-layer and stores the data at
`
`buffers according to its type. The TCSL sub-layer checks if
`each frame stored in the buffers has sufficient time for
`arriving at receiver side or not, and determines whether
`to deliver each frame to the PR-SCTP sub-layer. Time con-
`strainer in the TCSL sub-layer checks an expected margin
`of time until each data should be played back at receiver.
`If the time constrainer decides that a message cannot reach
`the receiver within the playback time, the message is re-
`moved by the TCSL’s sender. This process in the TCSL
`sub-layer prevents unnecessary transmission. (Also,) TC-
`SCTP provides differentiated transmission service for
`real-time video data. For example, MPEG video stream is
`composed of voice data, image data (I, P and B frames),
`and control data. To provide differentiated transmission
`service to data coming from the video server of the upper
`layer, TCSL of TC-SCTP has four buffers for voice, I-frame,
`P-frame, B-frame, and control messages. a classifier of TCSL
`receives the MPEG frames directly from the application
`layer, discriminates them, and puts them in the separated
`queues according to the types of frame. Also, the classifier
`marks the frames with its arrival time which is necessary
`to calculate each frame’s playback time. The Time Con-
`strainer checks the remaining playback time for each mes-
`sage de-queued from buffers. Then, the sender selects a PR-
`SCTP stream according to the remaining playback time.
`TC-SCTP adopts existing PR-SCTP which supports vari-
`ous types of reliability and make up for the weak points
`for multimedia service. PR-SCTP sub-layer of TC-SCTP
`opens multiple streams for differentiated retransmission
`when establishing a session, and sets the maximum num-
`ber of retransmissions differently for each stream. Fig. 2
`shows an illustrative example, which opens four streams
`and sets the maximum number of retransmissions at 4,
`2, 1 and full, respectively. The sender module of TCSL
`sub-layer sends each frame data to one of the four PR-SCTP
`streams (stream 1, 2, 3, 4) depending on its data type (I
`frame, P frame, B frame, Voice/Control) and remaining
`playback time. Because I frame has more important infor-
`mation to play MPEG video back than P and B frames,
`stream 1 attempt more retransmissions (four times) than
`stream 2 (two times) and stream 3 (one time). So, B frame
`is only retransmitted once. The last stream 4 provides con-
`trol information and voice data with fully reliability. It is
`because control and voice data are tightly related to recei-
`ver’s playback and user’s service satisfaction, respectively.
`
`
`ApplicationApplication
`
`LayerLayer
`
`
`MultimediaMultimedia
`
`StreamingStreaming
`
`ServerServer
`
`
`
`Transmission Control-SCTP (TC-SCTP)Transmission Control-SCTP (TC-SCTP)
`
`
`
`Transmission Control sub-layer (TCSL)Transmission Control sub-layer (TCSL)
`
`
`
`PR-SCTP sub-layerPR-SCTP sub-layer
`
`
`
`ClassifierClassifier
`
`
`
`SenderSender
`
`
`
`ith Drop-Head Queueith Drop-Head Queue
`
`
`
`jth Streamjth Stream
`
`
`
`DropDrop
`
`
`Time Time
`
`ConstrainerConstrainer
`
`Fig. 1. TC-SCTP layer architecture.
`
`Sportradar 1034
`Page 3
`
`

`

`K.-H. Kim et al. / Computer Networks 54 (2010) 1418–1425
`
`1421
`
`Fig. 2. Differentiated transmission according to data type.
`
`3.2. Drop-head queue
`
`The proposed TCSL sub-layer has multiple buffers, and
`the number of buffers is determined by the number of
`types of data incoming from the application layer. For
`example, MPEG video data are usually divided into five
`types – I-frame, B-frame, P-frame, voice data and control
`data - according to the degree of classification of OCI infor-
`mation. For differentiated transmission of these messages,
`the TCSL sub-layer maintains a buffer for each type of mes-
`sages. Voice and I-frame share the same buffer because
`these data have similar properties.
`A typical buffering method is drop-tail queuing. If the
`queue is full when a new frame arrives, the frame is dropped.
`In this case, en-queued data are served first. TCSL sub-layer’s
`buffers, however, use drop-head queuing property. That is, if
`a drop-head queue has no room for newly arriving frames, it
`removes data in the forefront of the buffer and then stores
`the new frames. It is because video streaming data is sensi-
`tive to delay. The longer they stay in the buffer, the shorter
`their marginal time for transmission. The buffers become
`full of frames when the network situation is deteriorated
`and frames are not transmitted smoothly in PR-SCTP sub-
`layer. In a buffer, the foremost frame is oldest and is most
`likely to have shorter marginal time for transmission than
`the time constraint for dropping. Thus, when a new frame ar-
`rives to a buffer occupied already, the foremost frame is
`dropped first and the new frame is added. Fig. 3 shows the
`drop-head queuing process.
`
`3.3. Time constraint
`
`Time constraint is used by the Time Constrainer of buf-
`fers in the TCSL sub-layer, to determine whether to send
`
`Fig. 3. Drop-Head queuing.
`
`data via PR-SCTP. TCSL sub-layer assigns different time
`constraints according to the data type. In order to assign
`time constraints, it is required to estimate the maximum
`time allowed for each data in the sender’s TCSL sub-layer
`to be played in the receiver’s application program. This
`section defines the parameters involved in assigning time
`constraints.
`The offset delay ðT OSÞ is the basic delay given when the
`sender and the receiver’s application layers begin to send
`and receive video streaming data. The delay means the
`time taken for multimedia data transmitted by the sender’s
`server to be played in the receiver’s application program.
`Data that arrives at the receiver after exceeding the time
`cannot be played, and is discarded. In this paper, offset de-
`lay was defined as the maximum marginal time for a data
`message received by TCSL sub-layer from the upper layer,
`to be delivered to the receiver’s application. As mentioned
`above, for the Time Constrainer to determine whether data
`in the buffer can be played in the receiver’s program, it
`should know how much time has passed since the data
`were created.
`In assuming that the sender’s server sends data to TCSL
`of TC-SCTP as soon as it creates the data, TCSL can use the
`time of receiving data from the upper layer ðT ARÞ as the
`time of creation for the data. The playback time ðT PBÞ is
`the point of time when each frame data should be played
`in the receiver’s upper layer. So, each data should arrive
`at the receiver before the playback time, because data
`arriving after the time cannot be played and removed. TCSL
`defines the estimated time of data playing by adding the
`offset delay time ðTOSÞ to the time when the data arrives
`at the sender’s TCSL sub-layer. The offset delay time is
`determined by sender’s application and notified to TCSL.
`This paper premises that the sender’s application should
`negotiate for service parameters, such as receiver’s buffer
`size, service rate, and so on, after service request from re-
`ceiver’s application. The sender’s application derives the
`offset delay time from values of receiver’s buffer size and
`transmission delay.
`ð1Þ
`TPB ¼ T AR þ TOS:
`For data to be sent via PR-SCTP sub-layer, the time con-
`strainer of TCSL sub-layer estimates the time remaining
`until the playback time. In this paper, the remaining time
`is defined as the marginal time to playback ðT MGÞ at recei-
`ver application, and checks whether the transmission of
`
`Sportradar 1034
`Page 4
`
`

`

`1422
`
`K.-H. Kim et al. / Computer Networks 54 (2010) 1418–1425
`
`the corresponding data will be necessary. If the marginal
`time for transmission is long, it is more likely that the data
`is transmitted to the receiver successfully. However, if it is
`short, it is more possible that even if the data is transmit-
`ted to the receiver successfully, the transmission would be
`useless. Thus, to prevent unnecessary transmission, the
`time constrainer in the TCSL sub-layer buffers checks the
`marginal time for transmission of each data before trans-
`mission. If the marginal time for transmission is shorter
`than a specific value, the TCSL’s sender discontinues trans-
`mission and removes the data from the buffer. The mar-
`ginal time for transmission is the difference between the
`estimated time of playing ðTPBÞ of each data and the cur-
`rent time of the time constrainer (T) for the data as below
`(see Fig. 4):
`TMG ¼ TPB T:
`
`ð2Þ
`
`Fig. 4. Marginal time for transmission.
`
`3.4. TCSL data transmission
`
`TC-SCTP is composed of TCSL sub-layer described in this
`section and PR-SCTP of [6,8]. A TCSL’s sender forwards
`messages to multiple streams pre-allocated by PR-SCTP
`according to message type and marginal time length
`ðT MGÞ which a TCSL’s time constrainer calculates for mes-
`sages from its local queue. This TCSL data transmission
`algorithm is illustrated in Fig. 5.
`TCSL’s sender classifies the marginal time lengths into
`three cases according to message type: T MG P Th1; T MG
`P Th2; T MG P Th3 ðTh1 > Th2 > Th3Þ. Also, TCSL sub-layer
`uses multiple streams of PR-SCTP with different reliability
`levels, such as maximum number of retransmission [8] or
`available time limit for retransmission [6]. For example,
`the stream 1, 2, and 3 of Fig. 2 allow four, two, and one
`times of retransmission. And, stream 4 provides full reli-
`ability i.e., it attempts retransmissions until transmission
`is complete.
`As mentioned before, the proposed TC-SCTP handles
`five types of MPEG data – I-frame, P-frame, B-frame, voice
`data and control data. Among these data, voice and I-frame
`image data are critical information in terms of user satis-
`faction. Thus, TC-SCTP attempts retransmission as many
`times as permitted by marginal time for transmission.
`For this, if the marginal time for transmission ðTMGÞ of an
`incoming message is longer than Th1, the TCSL’s sender
`sends it to Stream 1 of PR-SCTP sub-layer. Stream 1 at-
`tempts retransmission of the data up to four times. If the
`
`Fig. 5. TCSL data transmission algorithm.
`
`Sportradar 1034
`Page 5
`
`

`

`K.-H. Kim et al. / Computer Networks 54 (2010) 1418–1425
`
`1423
`
`data stays long in the buffer, as a result, Th2 6 T MG < Th1, it
`is retransmitted up to two times. If Th3 6 T MG < Th2, the
`TCSL’s sender transmits the data to Stream 3. Lastly, if mar-
`ginal time for transmission is shorter than Th3, the data is
`dropped without being transmitted.
`In contrast to I-frame data, in the proposed TC-SCTP, P-
`frame image data are transmitted to Stream 2 or 3,
`depending on marginal time for transmission, and B-frame
`data is transmitted only to Stream 3. The control signals for
`video streams are essential information for playing in the
`receiver. As control data plays the roles of synchronization,
`frame interval control, etc. and convey the user’s opera-
`tions such as play, pause and stop, if the data are dropped
`arbitrarily, the performance may be reduced significantly.
`Furthermore, because control data are small in volume
`and consume only a small amount of network resources,
`they do not affect network congestion. Thus, TC-SCTP
`transmits control data to Stream 4 without calculating
`the marginal time at time constrainer.
`The TCSL sets the values of parameter Th1; Th2 and Th3
`using the Retransmission Timeout (RTO) value traced by
`PR-SCTP continuously. So the thresholds can reflect the
`current network conditions. We consider the thresholds
`as bellows.
`
`Th1 ¼ RTT 4 þ a1;
`Th2 ¼ RTT 2 þ a2;
`Th3 ¼ RTT 1 þ a3:
`
`ð3Þ
`
`That is, Th1 is set to be more than quadruple of RTO, so that
`four times retransmission is possible. Also Th2 and Th3 val-
`ues are set to be more than double RTO and RTO, respec-
`tively. Actually, some slack term (such as standard
`deviation of RTO) may be added to these threshold values.
`Since the RTO values are usually determined by PR-
`SCTP according to the average of RTT, the thresholds are
`able to consider network conditions.
`
`4. Performance evaluation
`
`In this section, we first describe the network topology
`for simulations. To evaluate the performance of TC-SCTP
`against SCTP and PR-SCTP, we performed simulations via
`ns-2 simulator.
`
`4.1. Simulation environments
`
`In simulation, a network topology is used as shown in
`Fig. 6. There are seven sender (S1–S7), seven receiver
`(R1–R7), and two intermediate nodes (N1 and N2). In this
`network topology, MPEG-4 video traffic is transmitted
`from S1 to R1. At the same time, 3 Mbps CBR background
`traffics are generated by On/Off traffic generator between
`S2–S7 and R2–R7, respectively. The GOP block of MPEG-4
`video stream used for these simulations is composed of
`IBBPBBPBB frames and the coding rate is 30 fps. We simu-
`lated with the capacity of links set 50 Mbps and 20 Mbps.
`Link delay is set 10 ms, Video traffic transmission rate is in-
`crease from 1 Mbps to 8 Mbps and packet error rate is set
`from 0 to 0.1 with 0.01 intervals. In the simulation, we ana-
`lyze the performance in each transmission protocol under
`different transmission rate, delay, packet error rate.
`We focus on three performance metrics: throughput,
`decodable frame rate, and PSNR. Throughput is the volume
`of data transmitted to the receiver per unit time. Hence,
`higher throughput is, more data can be transmitted. In vi-
`deo transmissions, data are generated periodically and,
`after being transmitted, played in sequence. We first ob-
`serve the throughput by changing the transmission rate
`in Fig. 6 from 1 Mbps to 8 Mbps. As shown in Fig. 7, the
`throughput is decreased as the transmission rate is in-
`crease in all three protocols.
`After the transmission rate is over 6 Mbps, because it is
`the point that the congestion in the network happened, the
`throughput of all protocols are degraded. TC-SCTP shows a
`higher throughput than PR-SCTP and standard SCTP after
`network is congested.
`Because the standard SCTP guarantees ‘full reliability’,
`and thus repeats retransmissions until all data are cor-
`rectly transmitted.
`In order to a video data to be played continuously by
`the receiver, the data transmitted through the network
`should satisfy the strict delay constraint. If the delay con-
`straint is not satisfied on the network, the periodic video
`data is disturbed and the video breaks off. Therefore, we
`define the decodable frame rate as the ratio of video data
`transmitted successfully before the playback time ðTPBÞ
`estimated for each data to video data transmitted by the
`sender. That is, the decodable frame rate is a measure of
`continuous satisfaction of the delicate delay characteristics
`of video traffic.
`
`Fig. 6. Network topology.
`
`Sportradar 1034
`Page 6
`
`

`

`1424
`
`K.-H. Kim et al. / Computer Networks 54 (2010) 1418–1425
`
`Fig. 7. Throughput comparisons.
`
`Fig. 9. Cumulative distribution function of delay.
`
`However, the decodable frame rate is more important
`than the average throughput in video transmissions be-
`cause only timely arrived packets are meaningful with re-
`spect to service quality.
`Fig. 8 shows the decodable frame rate in SCTP, PR-SCTP,
`and TC-SCTP. When packet error rate is increased, the dec-
`odable frame rate of the flow decreased as expected. It can
`be seen that TC-SCTP can increase the percentage of data
`satisfying the delay constraint.
`TC-SCTP indicates that much higher decodable frame
`rate compared with SCTP and PR-SCTP. In short, even
`though TC-SCTP has lower throughput, it can significantly
`improve the decodable ratio that is an important measure
`in real-time multimedia transmissions. That is, TC-SCTP
`can improve the decodable ratio or quality of video
`transmissions.
`On the other hand, the loss of I-frame results in signifi-
`cantly quality degradation at receiver side. We simulated
`under various packet error rate, when using SCTP, PR-SCTP
`and TC-SCTP.
`Fig. 9 shows the cumulative distribution function of de-
`lay for received available I-frame by receiver side. It shows
`that the quality of video transmission using TC-SCTP can be
`more maintained than using SCTP and PR-SCTP.
`
`Fig. 8. Decodable frame rate vs. packet error rate.
`
`Fig. 10. PSNR vs. packet error rate.
`
`And we measured PSNR (Peak Signal to Noise Ratio) as
`performance metric to evaluate in the quality of video
`streams. PSNR is one of the most widely objective metrics
`for quality of video transmissions. It is utilized in literature
`measures quality of an original image before and after
`compression.
`Fig. 10 depicts results for packet error rate ranging from
`0.1 to 1.0. In this figure, TC-SCTP was outperforming than
`other protocols. Since the (re)transmission policy affects
`every frame resulting in a stable PSNR while P and B frame
`would be sent unreliable.
`
`5. Conclusions
`
`Real-time data such as voice and video must arrive at
`the receiver within the maximum playback delay time
`period. In this paper, we have proposed a Transmission
`Control-SCTP (TC-SCTP) for efficient MPEG video transmis-
`sions. TC-SCTP is composed of Transmission Control sub-
`layer (TCSL) and PR-SCTP sub-layer. Depending on the type
`of video frames and the delay constraint, TCSL sub-layer
`maintains multiple buffers and assigns different numbers
`
`Sportradar 1034
`Page 7
`
`

`

`K.-H. Kim et al. / Computer Networks 54 (2010) 1418–1425
`
`1425
`
`of retransmissions to each buffer. We have performed
`extensive simulations via ns-2. The simulation results
`demonstrate that TC-SCTP can improve the service quality
`in video transmissions by increasing the amount of data
`frames arriving within the delay constraint.
`
`References
`
`[1] S. Fu, M. Atiquzzaman, SCTP: state of the art in research, products,
`and technical challenges, IEEE Communications Magazine 42 (2004)
`64–76. April.
`[2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: a transport
`protocol for real-time application, IETF RFC 1889, January 1996.
`[3] R. El-Marakby, D. Hutchison, Scalability improvement of the real-
`time control protocol (RTCP) leading to management facilities in the
`Internet, in: Proceedings of ISCC’98, June 1998, pp. 125–129.
`[4] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor,
`I. Rytina, M. Kalla, L. Zhang, V. Paxson, Stream control transmission
`protocol (SCTP), IETF RFC 2960, October 2000.
`[5] A. Argyriou, A novel end-to-end architecture for H.264 video
`streaming over the Internet, in: Proceedings of Telecommunication
`Systems, February 2005, pp. 133–150.
`[6] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad, Stream control
`transmission protocol (SCTP) partial reliability extension (PR-SCTP),
`IETF RFC 3758, May 2004.
`[7] A. Argyriou, V. Madisetti, Streaming H.264/AVC Video over the
`Internet, CCNC (2004) 169–174. January.
`[8] Z. Lifen, S. Yanlei, L. Ju, The performance study of transmitting
`MPEG4 over SCTP, in: Proceedings of Neural Networks and Signal
`Processing, vol. 2, December 2003, pp. 1639–1642.
`[9] H. Radha, M. van der Schaar, Y. Chen, The MPEG-4 fine-grained
`scalable video coding method for multimedia streaming over IP, in:
`Proceedings of IEEE Trans. Multimedia, vol. 3, March 2001.
`[10] K. Stuhlmueller, N. Faerber, B. Girod, Adaptive optimal intra update
`for
`lossy video transmission,
`in: Proceedings of SPIE, The
`International Society for Optical Engineering, vol. 4067, March
`2000, pp. 286–295.
`[11] A. Mehaoua, S. Zhang, R. Boutaba, FEC-PSD: a FEC-aware video
`packet drop scheme, in: Proceedings of GLOBECOM ’99, vol. 4,
`October 1999, pp. 2091–2096.
`[12] B. Girod, M. Kalman, N.J. Liang, R. Zhang, Advances in channel-
`adaptive video streaming,
`in: Proceedings of
`International
`Conference on Image Processing, vol. 1, September 2002, pp. 9–12.
`[13] Ahmed A.E. Al, Chitra Venkatramani, Tarek Saadawi, Myung Lee,
`Improving interactive video in wireless networks