Research for streaming media transport protocols on basis of next

generation Internet

YAN Wei CHENG Yuan REN Maosheng

Computer Networks Laboratory Computer Networks Laboratory Computer Networks Laboratory

Peking University Peking University Peking University

yanwei@net.pku.edu.cn chengyuan@net.pku.edu.cn rms@net.pku.edu.cn

1

Abstract Internet’s rapid growing promotes network

applications’ evolutions. As particular network application has

its special requirements for network technology, many protocols

have been presented. Most of those protocols overlap and

redundant in function, which result in bad performance of

protocols. This paper presents an IPv6 QoS-based simple

streaming transport protocol (SSTP), which arms at next

generation networks and takes into account the feature of

multimedia stream transmission. The protocol has been

implemented and deployed in a multimedia stream playing

system. This paper not only introduce the background and

design thinking of SSTP，but also describes SSTP in detail. At

last the article compares the performance of SSTP and

RTP/RTCP, and gives the consideration about improvement of

SSTP.

Categories and Subject DescriptorsC.2.2 [Computer-Communication Networks]: Network

Protocols – Protocol verification

General TermsPerformance, Design, Experimentation

KeywordsStreaming media, transport protocol, performance

1. INTRODUCTION

In contrast to present internet, Next Generation Internet (NGI)

not only offers more bandwidth, but also provides Quality of

Service(Qos) to some extent, so it is practically important to

research novel streaming media transport protocols for NGI

based on IP QoS. In this paper, a Simple Streaming media

Transport Protocol (SSTP) is designed and implemented for

NGI and its functionality and capability are demonstrated by a

media streaming demo system in IPV6 test-bed.

The rest of this paper is organized as follows: The

characteristics of streaming media and previous streaming

media transport protocols are introduced in Section 2. We

discuss the design principle of SSTP, describe its functionality

and offer the essential technologies to implement it in Section 3.

In Section 4, according to analytical performance and actual

demo results, we propose the method to improve SSTP. The

development of future streaming media transport technologies

are discussed in Section 5.

2. CHARACTERISTICS OF STREAMING MEDIA AND STREMING MEDIA TRANSPORT PROTOCOLS

There are two main patterns of transmitting audio and video

media flow on Internet: downloading file to local user and

playing file directly on Internet. As for limitation of bandwidth

and congestion in network, it usually requires a long time to

download a media file entirely, while streaming transmission, a

means to deliver audio and video data continuously in real-time

to user, only requires several seconds to startup for viewing.

When the media file is being played on local computer of user,

its rest parts are being downloaded simultaneously from the

remote media server. The obvious advantage of streaming

transmission is the great reduction of startup delay. What is

more, it doesn’t require so large cache capacity.

2.1 CHARACTERISTICS OF STREAMING MEDIA The streaming transmission based media is called streaming

media, which plays media file while downloading it. In contrast

to the dominating protocol in present internet –TCP, streaming

media has following characteristics:

The consumed bandwidth is relative constant. Both

CBR(Constant Bit Rate) audio streaming and

VBR(Variable Bit Rate) video streaming consume the

relative bandwidth in the long term of time.

Sensitive to time. The streaming media, which plays media

file while downloading it, requires that the data must be

delivered to user in the given time slice, the delayed data

is useless to local media player.

The codec of streaming media has some tolerance

capability for packet loss, but it requires the distribution of

packet loss is uniform. That is say, it is not required no

packet lost in transport layer, it is enough to guarantee that

the packet loss is controlled in some range (usually from

2% to 10%) and there is no peak in a packet loss event

(For example, a large number of packets are lost in a short

time).

2.2 STREAMING MEDIA TRANSPORT PROTOCOLMedia files are stored on severs and users request them for

viewing, the process is called a session, which is from startup

request to end of playing media. A session control protocol —

2

RTSP (Real-Time Streaming Protocol) is applied widely now,

which is used for setting up, transmitting and controlling one or

more media flows in a same streaming media session.

Streaming media transport protocol is designed to offer

functionality of transmitting media flow on network, alleviating

or eliminating the limitation of internet itself. The goal of

protocol design is to provide a real-time, sequential, low-delay,

low-loss and low-jitter channel for streaming media. RTP as a

media transport protocol is used widely now.

RTP is proposed by IETF working group, RTP is originally

designed to satisfy the needs of multi- participant multimedia

conferences. RTP is defined to offer time information and data

flow synchronization under the communication pattern of one-

to-one or one-to-many.

RTP actually includes two sub-protocols, one is RTP used to

deliver data and the other is RTCP used for QoS statistical

information and control feedback information. So two pairs of

port number are used in a RTP session, one is used by RTP to

transmit data and the other is used by RTCP to deliver control

information.

RTCP and RTP provide the service of flow control and

congestion control. During RTP transmission session,

participants deliver RTCP messages periodically. According to

all kinds of statistical information in RTCP message, the server

can compute approximately the rate of packet loss, delay and

jitter etc, dynamically change the transmission speed and even

change the type of payload. So RTCP actually provide the

function of QoS in application layer, offsetting the limitation

that there is no QoS guarantee in IP layer.

Except RTP protocol, Shanwei Cen[3]proposed the SCP

protocol considering the unsuitability of TCP in streaming

media transmission. Christopher K. Hess and Roy H. Campbell

proposed the MSP protocol; Biswaroop.Mukherjee proposed the

TLTCP protocol in his thesis. But none of them is perfect, some

is not TCP-friendly, some wastes too much bandwidth and some

doesn’t support IP multicast.

3. SIMPLE STREAMING MEDIA

TRANSPORT PROTOCOLS

Present internet is a best-effort switch network, hardly providing

any QoS function. So it can’t guarantee the bandwidth of a flow

and an end-to-end delay. The prevalent RTP/RTCP protocol also

has shortcoming, RTP is originally designed to satisfy the needs

of multi-participant multimedia conferences which is different

from the model of client/server, so when using RTP to

transmitting media data, each packet header contains some

redundant information, thus wasting bandwidth unnecessarily.

What is more, because IP layer will provide end-to-end QoS

guarantee in next generation internet, RTCP is useless in NGI.

We design and implement a novel Simple Streaming media

Transport Protocol (SSTP) according to characteristic of NGI.

To improve the transmission performance, we reduce much

control information which is used presently but unnecessary for

future.

3.1 DESIGN PRINCIPLEAccording to characteristic of NGI, we affirm that the

transmission pattern of streaming media will change entirely: it

is not required for transport protocol to adaptive to the

fluctuation of flow in network. After the request to network

layer for the reservation of end-to-end bandwidth is satisfied,

transport protocol can use its own channel freely. In this paper,

we design and implement the Simple Streaming media

Transport Protocol (SSTP), a novel media transport protocol

specially for next generation internet.

SSTP is designed based on the assumption that IP layer support

Qos, that is to say, as for admitted flow, the given bandwidth,

packet loss ratio and packet delay are guaranteed in network

layer. We describe the SSTP design principle as follows:

Make full use of the Qos function in network layer.

In order to alleviate the load of network and improve the

performance of end systems, the format of packet and the

states of protocol should be simplified.

Provide the function of sorting, checking and

synchronizing for streaming media.

3. 2 SSTP PROTOCOLBased on above principles, SSTP protocol is directly designed

on IPv6, and it takes advantage of the flowlabel field of IPv6

header to identify different media streams. It has two advantages

compared to the RTP based on UDP: first, the decrease of

protocol layers can improve the processing rate of the end

systems (including both server and client); second, this decrease

cuts down the length of the data packet header, it can improve

the utility of the bandwidth, which is very important for media

stream transport protocol for its high demand to bandwidth.

3

Figure 1 Position of SSTP in protocol layers

Based on IPv6

The header of SSTP protocol abuts on the header of IP

protocol. In order to avoid conflicting with other protocols

at present, the value of Next Header field in IPv6 header is

assigned 200 for SSTP protocol.

It is prescribed in IPv6 standard that the MTU of all links

in Internet is 1280 bytes at least. In order to avoid

fragmenting in IP layer, it is suggested in SSTP protocol

that the length of every data packet is not bigger than 1280

-40 = 1240 bytes (there 40 bytes is the length of IPv6

header).Considering of the transport efficiency, the length

of SSTP data packet should be near the maximum value as

soon as possible (the maximum value is MTU of link - 40).

The flowlabel of IPv6 is used in SSTP protocol. The sender

set different flowlabels for different audio streams and/or

video streams of the same session; the receiver distinguish

different media streams by the flowlabel of the data packet

received.

There is no checksum in IPv6 header, the upper layer

protocol SSTP use pseudo header to calculate checksum in

term of prescript, the value of Next Header field is 200.

SSTP message format

SSTP message is divided to two classes according to

function: data message and control message. Data message

is used to transport media stream; Control message is used

to transport controlling information.

The header of SSTP message is 8 or 12 bytes, they are

separately used for byte-stream mode and frame mode.

There are some fields in header, including Mode, Extend,

Control, Event, Timestamp, Checksum, Sequence Number

and Payload. The Event and Timestamp fields are used to

control frame boundary and synchronization at frame

mode; the calculation of checksum include pseudo header,

SSTP header and SSTP payload.

When transporting media stream, control message is used

only if a sender (Server) definitely require a receiver

(Client) to send it. The control message provide the

feedback path to sender for receiver, the feedback info

usually include loss rate and bandwidth estimate at present.

Function description of SSTP

Two transport modes are applied in SSTP: byte-stream

mode and frame mode. At byte-stream mode, the server is

required to possess the media stream file to be transported,

all audio streams and video streams required by client are

included in the file; as a supplement to byte-stream mode ,

frame mode is mainly used in TV living broadcast. We

carry out the byte-stream mode at present. At byte-stream

mode, a whole file is treated as a byte stream, regardless of

the format and number of media streams in the file. The

server identifies the media stream file by the client’s

requirement and gets the header info of the media stream

(such as the natural play time and the size of media data

etc.). Based on these information, first, the server calculate

the bandwidth for transporting the file and identify

flowlabel, then apply resource reservation to network layer

QoS manager; second, the server calculate the size of

available SSTP data packet payload, based on calculation

result (bandwidth, the size of SSTP data packet available

payload ), it can confirm the interval between two

continuous data packets; finally, the server pack the data to

be sent into packets at fixed size, fill flowlabel, checksum

and sequence number in header, and send at the special

interval. The client get the data packets from the server by

the same flowlabel and protocol identification; the data

packets are discarded if checksum is wrong; then the rest

packets was reordered by sequence number, a new byte

stream is formed and delivered to upper layer; the codec in

upper layer decodes the byte stream and play it.

The byte-stream mode has many advantages compared to

RTP at present: first, the server doesn’t need to read and

identify every frame, the efficiency at server is improved

remarkably, a server can serve for more clients; second,

the transport rate of data packets is absolutely constant, it

is convenient for processing QoS (i.e. to alleviate the work

of shaping at ER), meanwhile, it is easy to reserve

resource; third, filling much data into a packet as soon as

possible decrease the header payload, which improve the

utility of the bandwidth; finally, every media stream file

has only a flow in the network, but not have several

audio/video streams, the payload of the QOS router for

resource reservation and the payload of end system is

4

decreased.

3.3 PLAY SYSTEMThe above SSTP is only a protocol at transport layer, its main

function is transporting media stream. In practical media stream

transport system, it must cooperate with RTSP. The client finds

the URI of the wanted media stream file, then it use RTSP

protocol to communicate with media server. During this process,

the server require to QOS manager in network layer to apply to

resource reservation. After the RTSP session is established

successfully, the client sends “PLAY”, the server begins to

transport media stream through SSTP (Figure 2 show this

process).The Control message in SSTP protocol is not used at

present, because theoretically QOS at network layer sustain

resource reservation from end to end, it is not necessary to get

the receiver’s feedback except to get some statistic information.

Figure2 Communication between media client and server

Media stream play system adopts C/S model, it sustain two

application modes: VOD mode and Broadcast Mode,

corresponded to bytestream mode and frame mode of SSTP

protocol respectively. We designed and implemented a media

stream transport system SimpleStreamer based on an open

source code library called Live, the protocol of transporting

media stream in this system is SSTP. The system is shown in

figure 3.

Figure 3 Media stream play system SimpleStreamer based on

SSTP

SimpleStreamer integrated the interface of IP QOS except that it

has simple structure, is scalable, sustains unicast and is easy to

manipulate. The client of the system can demand quality of

service based on his/her own requirement.

4 PERFORMANCE EVALUATION AND

COMPARISON

We implement SSTP and SimpleStreamer player under

commodity Linux environment. In this section, performance

evaluation parameters and theoretic analysis results are

presented, followed by the experimental performance analysis

of SSTP and Simple Streamer based on the practical

measurements.

4.1 EVALUATION PARAMETER ANALYSISFollowing parameters are usually concerned for analysis of

streaming transport protocol

Extra bandwidth overhead for protocol operations,

i.e. bandwidth occupied by appended packet head and

control signaling when the same amount of net

streaming media is delivered.

CPU usage of end systems. The complexity of the

protocol operation is measured especially at the

streaming media server. The CPU cycles taken by the

protocol is expected to be as few as possible.

Delay and jitter of data packets. Whether the packets

can arrive in time, and whether their arrival time are

distributed uniformly will directly affect the playback

effects of the streaming media.

Loss rate of data packets. Certain extent of packet

loss rate is tolerable for the media stream, however, if

large amount of packets are lost in a short period, the

playback quality will degrade severely.

Whether the protocol is TCP friendly. As TCP

streams constitute a large part of the traffic over the

Internet, the ability to be TCP friendly is also an

important standard for streaming transport protocols.

As the infrastructure of the Next Generation Internet has

changed a lot, the standard for performance evaluation of

streaming media transport protocols will also be different. For a

streaming media transport protocol with underlying end-to-end

QoS mechanism in the IP layer, the delay jitter, loss rate and

5

TCP friendliness mentioned above has been guaranteed and

need no further consideration theoretically, which means

different protocols will perform consistently in these aspects. As

a result, the performance evaluation of streaming protocols for

NGI will concentrate on bandwidth and CPU usage.

4.2 PERFORMANCE COMPARISON OF SSTP AND RTP

Comparison of bandwidth overhead and

net bandwidth

The bandwidth overhead of a specific streaming transport

protocol is determined by several factors including MTU,

media frame rate, packet header length, packing method,

protocol control messages and the length/frequency of the

ACK messages. Taking minimum MTU=1280 bytes for

IPv6 as an example, the bandwidth overhead of SSTP is

3.9% compared to 9.8% for TCP. When the frame length

variation is considered, bandwidth overhead of RTP is

9.9% 2.5%. SSTP is obviously more efficient than RTP.

End system CPU usage comparison

The end system CPU usage is determined by the

complexity of protocol operations and the number of RAM

access for packets retrieval. The CPU usage is expected to

be as low as possible, especially that of the streaming

servers for which the CPU capacity is already a big issue.

In a VOD system, media files are processed and stored in the

storage systems of media servers. The load per second of the

media server running RTP is at least M× （ Fread＋ Fparse ＋Fadd）heavier than those running SSTP. Fread is the computation

amount in the process from distinguishing the starting tag of the

frame to reading in the complete description information of the

frame head. Fparse is the computation required for obtaining the

frame length, frame playback time and other related information

according to the description information conveyed in the frame

head. Fadd is the computation complexity for calculating the

appended frame head. M usually falls between 23 and 30. F* is

closely related to the specific coding format of the media file

[8].

4.3 COMPARING SSTP’S PERFORMANCE TO

RTP’S PERFORMANCE

Theoretically, service requirements such as loss, delay jitter and

TCP friendliness have already been fulfilled by the underlying

networking infrastructure with end-to-end QoS mechanism.

However, as NGI technology is still in its infancy, the practical

performance needs further verifying. Thus we measured and

compared the practical performance of SSTP and RTP on an

IPv6 testbed. The measurement results are presented here in

detail.

Experiment environment and methods

Fig.4 depicts the topology of our experimental network.

The streaming server and client (each with a 2.6GHz

Pentium4 CPU, 1GB DDR SDRAM, 120GB Hard disk)

support both SSTP and RTP protocols.

In this experiment, jitter and loss rate of the two different

transport protocols are measured under the situations of

transmitting video/audio streams (6 times) and video

streams (9 times) respectively.

Figure 4 SSTP and media play system

Experimental results analysis

The loss rate and jitter of datagram transmitted by SSTP is

more then that transmitted by RTP in networks which there

are short of QoS mechanism. The loss rate and jitter of

datagram transmitted by SSTP is also more then the that

transmitted by RTP in networks which support the end-to-

end QoS.

figure 5 (a) jitter without QoS

6

figure 5 (b) jitter with QoS

figure 5 (c) loss rate without QoS

figure 5 (d) loss rate with QoS

But from performance graphics above we notice that the loss

rate and jitter of datagram have been rapidly reduced when

deploy the IP QoS mechanism, while that of datagram

transmitted by RTP have not been reduce much. It is that SSTP

benefit from guaranteeing bandwidth from IP QoS mechanism.

From the analysis above we also conclude that the performance

of SSTP is not better than RTP, because RTP has a partnership,

RTCP, which control traffics when there are congestion. SSTP is

based on IP QoS, and therefore we can simplify the control

mechanism of the protocol.

5 FUTURE WORK

The essential feature that differentiates streaming media

application from the traditional ones is its time-sensitiveness.

Overdue streaming packets make no sense for clients running

real-time applications. So the greatest concern is to guarantee

streaming data packets arriving at the clients in time. On the

other hand, in order to deliver more media streams

simultaneously under the limited bandwidth conditions of the

internet, the transportation efficiency of the streaming transport

protocols has to be taken into consideration.

The SSTP protocol based on IP QoS mechanism presented in

this paper is the first step of design and implementation.

Although the results of experiments do not live up to our

expectations, but the actual performance is approximately in

accordance with theoretic analysis, which demonstrates that

SSTP protocol with underlying QoS support succeeds in

delivering media streams efficiently and promptly.

According to the above analysis results, we plan to improve

SSTP from the following aspects: first, we will add at least

control signaling to SSTP through successive experiments to

improve the playback quality, save network bandwidth and

decrease the CPU usage. Then, we will devise an approach to

controlling buffer size of the receivers, at the same time

maintaining a certain level of playback quality for memory

limited networking devices. Finally, we will integrate an end-to-

end control signaling with the IP QoS mechanism in order to

shorten the setup response time perceived by the clients through

resource reservation and to grant clients the ability to adjust the

bandwidth allocated to them through previous requests.

REFERENCE

[1]. S. Cen, C. Pu and J. Walpole, “Flow and Congestion

Control for Internet Media Streaming Applications”, in

Proc. Multimedia Computing and Networking, January

1998.

[2]. Shulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,

“RTP: A Transport Protocol for real-time applications”,

RFC 1889, January 1996

[3]. C. K. Hess, “Media Streaming Protocol: An Adaptive

Protocol for the Delivery of Audio and Video Over the

Internet”, M.S. Thesis, University of Illinois at Urbana-

Champaign, 1998.

http://citeseer.nj.nec.com/hess98media.html  

7

[4]. B. Mukherjee, “Time-Lined TCP: a Transport Protocol for

Delivery of Streaming Media over the Internet”, Master's

thesis, University of Waterloo, Ontario, Canada, 2000 ,

http://citeseer.nj.nec.com/mukherjee00timelined.html

[5]. Reynolds, J. and J. Postel, “Assigned Numbers, STD 2”,

RFC 1700, October 1994

[6]. Live Networks Inc., “LIVE.COM Streaming Media”,

www.live.com

[7]. Henning Schulzrinne, Anup Rao and Rob Lanphier, "Real

Time Streaming Protocol (RTSP)", RFC2326, April 1998.

[8]. Chengyuan, “SSTP——a streaming media protocol on

basis of QoS”, master thesis 2003年。[9]. Deering, S. and R. Hinden, "Internet Protocol, Version 6

(IPv6) Specification", RFC 2460, December 1998

[10]. M. Handley and V. Jacobson, "SDP: Session Description

Protocol", RFC2327, April 1998

[11]. W. R. Stevens, “TCP/IP Illustrated, Volume 1: The

Protocols”, Addison-Wesley, Reading, Massachusetts,

1994.

[12]. W. R. Stevens. “TCP/IP Illustrated, Volume 2: The

Implementation”, Addison-Wesley, Reading,

Massachusetts, 1995.

[13]. Jian Lu, “Signal Processing for Internet Video Streaming:

A Review”, Apple Computer Inc.

streamingmedialand.com/sp4streaming2.pdf

[14]. DivXNetworks, Inc. “DIVX Player”, www.divx.com

[15]. Rob Koenen, “Overview of the MPEG-4 Standard”,

ISO/IEC JTC1/SC29/WG11 N4668, March 2002

[16]. MP4 Forum, “MPEG-4 – The Media Standard The

landscape of advanced multimedia coding”, Nov 2002

[17]. Microsoft Corporation, “Advanced Systems Format (ASF)

Document Revision 01.20.00e”, Dec. 6, 2002

[18]. R. Steinmetz and K. Nahrstedt, “Multimedia: Computing,

Communications, and Applications”, Prentice Hall PTR,

New Jersey, 1995.

[19]. K. Almeroth, “The evolution of multicast: From the

MBone to inter-domain multicast to Internet2

deployment”, IEEE Network, January/February 2000.

[20]. Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.

Jamin , “Resource ReserVation Protocol -- Version 1

Functional Specification”, RFC 2205, September 1997.

8