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
firstname.lastname@example.org email@example.com firstname.lastname@example.org
Abstract Internet’s rapid growing promotes network 1. INTRODUCTION
applications’ evolutions. As particular network application has
its special requirements for network technology, many protocols In contrast to present internet, Next Generation Internet (NGI)
have been presented. Most of those protocols overlap and not only offers more bandwidth, but also provides Quality of
redundant in function, which result in bad performance of Service(Qos) to some extent, so it is practically important to
protocols. This paper presents an IPv6 QoS-based simple research novel streaming media transport protocols for NGI
streaming transport protocol (SSTP), which arms at next based on IP QoS. In this paper, a Simple Streaming media
generation networks and takes into account the feature of Transport Protocol (SSTP) is designed and implemented for
multimedia stream transmission. The protocol has been NGI and its functionality and capability are demonstrated by a
implemented and deployed in a multimedia stream playing media streaming demo system in IPV6 test-bed.
system. This paper not only introduce the background and The rest of this paper is organized as follows: The
design thinking of SSTP ， but also describes SSTP in detail. At characteristics of streaming media and previous streaming
last the article compares the performance of SSTP and media transport protocols are introduced in Section 2. We
RTP/RTCP, and gives the consideration about improvement of discuss the design principle of SSTP, describe its functionality
SSTP. and offer the essential technologies to implement it in Section 3.
In Section 4, according to analytical performance and actual
Categories and Subject Descriptors demo results, we propose the method to improve SSTP. The
C.2.2 [Computer-Communication Networks]: Network development of future streaming media transport technologies
Protocols – Protocol verification are discussed in Section 5.
General Terms 2. CHARACTERISTICS OF
Performance, Design, Experimentation STREAMING MEDIA AND
STREMING MEDIA TRANSPORT
Streaming media, transport protocol, performance
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 protocol design is to provide a real-time, sequential, low-delay,
download a media file entirely, while streaming transmission, a low-loss and low-jitter channel for streaming media. RTP as a
means to deliver audio and video data continuously in real-time media transport protocol is used widely now.
to user, only requires several seconds to startup for viewing. RTP is proposed by IETF working group, RTP is originally
When the media file is being played on local computer of user, designed to satisfy the needs of multi- participant multimedia
its rest parts are being downloaded simultaneously from the conferences. RTP is defined to offer time information and data
remote media server. The obvious advantage of streaming flow synchronization under the communication pattern of one-
transmission is the great reduction of startup delay. What is to-one or one-to-many.
more, it doesn’t require so large cache capacity. RTP actually includes two sub-protocols, one is RTP used to
deliver data and the other is RTCP used for QoS statistical
2.1 CHARACTERISTICS OF STREAMING information and control feedback information. So two pairs of
MEDIA port number are used in a RTP session, one is used by RTP to
The streaming transmission based media is called streaming transmit data and the other is used by RTCP to deliver control
media, which plays media file while downloading it. In contrast information.
to the dominating protocol in present internet –TCP, streaming RTCP and RTP provide the service of flow control and
media has following characteristics: congestion control. During RTP transmission session,
The consumed bandwidth is relative constant. Both participants deliver RTCP messages periodically. According to
CBR(Constant Bit Rate) audio streaming and all kinds of statistical information in RTCP message, the server
VBR(Variable Bit Rate) video streaming consume the can compute approximately the rate of packet loss, delay and
relative bandwidth in the long term of time. jitter etc, dynamically change the transmission speed and even
Sensitive to time. The streaming media, which plays change the type of payload. So RTCP actually provide the
media file while downloading it, requires that the data function of QoS in application layer, offsetting the limitation
must be delivered to user in the given time slice, the that there is no QoS guarantee in IP layer.
delayed data is useless to local media player. Except RTP protocol, Shanwei Cenproposed the SCP
The codec of streaming media has some tolerance protocol considering the unsuitability of TCP in streaming
capability for packet loss, but it requires the distribution of media transmission. Christopher K. Hess and Roy H. Campbell
packet loss is uniform. That is say, it is not required no proposed the MSP protocol; Biswaroop.Mukherjee proposed the
packet lost in transport layer, it is enough to guarantee that TLTCP protocol in his thesis. But none of them is perfect, some
the packet loss is controlled in some range (usually from is not TCP-friendly, some wastes too much bandwidth and some
2% to 10%) and there is no peak in a packet loss event doesn’t support IP multicast.
(For example, a large number of packets are lost in a short
time). 3. SIMPLE STREAMING MEDIA
2.2 STREAMING MEDIA TRANSPORT TRANSPORT PROTOCOLS
Media files are stored on severs and users request them for
viewing, the process is called a session, which is from startup Present internet is a best-effort switch network, hardly providing
request to end of playing media. A session control protocol — any QoS function. So it can’t guarantee the bandwidth of a flow
RTSP (Real-Time Streaming Protocol) is applied widely now, and an end-to-end delay. The prevalent RTP/RTCP protocol also
which is used for setting up, transmitting and controlling one or has shortcoming, RTP is originally designed to satisfy the needs
more media flows in a same streaming media session. of multi-participant multimedia conferences which is different
Streaming media transport protocol is designed to offer from the model of client/server, so when using RTP to
functionality of transmitting media flow on network, alleviating transmitting media data, each packet header contains some
or eliminating the limitation of internet itself. The goal of 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. Based on IPv6
We design and implement a novel Simple Streaming media The header of SSTP protocol abuts on the header of IP
Transport Protocol (SSTP) according to characteristic of NGI. protocol. In order to avoid conflicting with other protocols
To improve the transmission performance, we reduce much at present, the value of Next Header field in IPv6 header is
control information which is used presently but unnecessary for assigned 200 for SSTP protocol.
future. It is prescribed in IPv6 standard that the MTU of all links
in Internet is 1280 bytes at least. In order to avoid
3.1 DESIGN PRINCIPLE fragmenting in IP layer, it is suggested in SSTP protocol
According to characteristic of NGI, we affirm that the that the length of every data packet is not bigger than 1280
transmission pattern of streaming media will change entirely: it -40 = 1240 bytes (there 40 bytes is the length of IPv6
is not required for transport protocol to adaptive to the header).Considering of the transport efficiency, the length
fluctuation of flow in network. After the request to network of SSTP data packet should be near the maximum value as
layer for the reservation of end-to-end bandwidth is satisfied, soon as possible (the maximum value is MTU of link - 40).
transport protocol can use its own channel freely. In this paper, The flowlabel of IPv6 is used in SSTP protocol. The sender
we design and implement the Simple Streaming media set different flowlabels for different audio streams and/or
Transport Protocol (SSTP), a novel media transport protocol video streams of the same session; the receiver distinguish
specially for next generation internet. different media streams by the flowlabel of the data packet
SSTP is designed based on the assumption that IP layer support received.
Qos, that is to say, as for admitted flow, the given bandwidth, There is no checksum in IPv6 header, the upper layer
packet loss ratio and packet delay are guaranteed in network protocol SSTP use pseudo header to calculate checksum in
layer. We describe the SSTP design principle as follows: term of prescript, the value of Next Header field is 200.
Make full use of the Qos function in network layer.
In order to alleviate the load of network and improve the SSTP message format
performance of end systems, the format of packet and the SSTP message is divided to two classes according to
states of protocol should be simplified. function: data message and control message. Data message
Provide the function of sorting, checking and is used to transport media stream; Control message is used
synchronizing for streaming media. to transport controlling information.
The header of SSTP message is 8 or 12 bytes, they are
3. 2 SSTP PROTOCOL separately used for byte-stream mode and frame mode.
Based on above principles, SSTP protocol is directly designed There are some fields in header, including Mode, Extend,
on IPv6, and it takes advantage of the flowlabel field of IPv6 Control, Event, Timestamp, Checksum, Sequence Number
header to identify different media streams. It has two advantages and Payload. The Event and Timestamp fields are used to
compared to the RTP based on UDP: first, the decrease of control frame boundary and synchronization at frame
protocol layers can improve the processing rate of the end mode; the calculation of checksum include pseudo header,
systems (including both server and client); second, this decrease SSTP header and SSTP payload.
cuts down the length of the data packet header, it can improve When transporting media stream, control message is used
the utility of the bandwidth, which is very important for media only if a sender (Server) definitely require a receiver
stream transport protocol for its high demand to bandwidth. (Client) to send it. The control message provide the
RTSP OTHERS feedback path to sender for receiver, the feedback info
usually include loss rate and bandwidth estimate at present.
TCP SSTP UDP
Function description of SSTP
Figure 1 Position of SSTP in protocol layers Two transport modes are applied in SSTP: byte-stream
mode and frame mode. At byte-stream mode, the server is function is transporting media stream. In practical media stream
required to possess the media stream file to be transported, transport system, it must cooperate with RTSP. The client finds
all audio streams and video streams required by client are the URI of the wanted media stream file, then it use RTSP
included in the file; as a supplement to byte-stream mode , protocol to communicate with media server. During this process,
frame mode is mainly used in TV living broadcast. We the server require to QOS manager in network layer to apply to
carry out the byte-stream mode at present. At byte-stream resource reservation. After the RTSP session is established
mode, a whole file is treated as a byte stream, regardless of successfully, the client sends “PLAY”, the server begins to
the format and number of media streams in the file. The transport media stream through SSTP (Figure 2 show this
server identifies the media stream file by the client’s process).The Control message in SSTP protocol is not used at
requirement and gets the header info of the media stream present, because theoretically QOS at network layer sustain
(such as the natural play time and the size of media data resource reservation from end to end, it is not necessary to get
etc.). Based on these information, first, the server calculate the receiver’s feedback except to get some statistic information.
the bandwidth for transporting the file and identify
HTTP GET WWW
flowlabel, then apply resource reservation to network layer Description server
QoS manager; second, the server calculate the size of
available SSTP data packet payload, based on calculation
client VCR control
result (bandwidth, the size of SSTP data packet available Streaming
payload ), it can confirm the interval between two media
continuous data packets; finally, the server pack the data to
be sent into packets at fixed size, fill flowlabel, checksum TEAR DOWN
and sequence number in header, and send at the special
interval. The client get the data packets from the server by Figure2 Communication between media client and server
the same flowlabel and protocol identification; the data
packets are discarded if checksum is wrong; then the rest Media stream play system adopts C/S model, it sustain two
packets was reordered by sequence number, a new byte application modes: VOD mode and Broadcast Mode,
stream is formed and delivered to upper layer; the codec in corresponded to bytestream mode and frame mode of SSTP
upper layer decodes the byte stream and play it. protocol respectively. We designed and implemented a media
stream transport system SimpleStreamer based on an open
The byte-stream mode has many advantages compared to source code library called Live, the protocol of transporting
RTP at present: first, the server doesn’t need to read and media stream in this system is SSTP. The system is shown in
identify every frame, the efficiency at server is improved figure 3.
remarkably, a server can serve for more clients; second,
the transport rate of data packets is absolutely constant, it Streamin play
is convenient for processing QoS (i.e. to alleviate the work control control
of shaping at ER), meanwhile, it is easy to reserve Media flow
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 Figure 3 Media stream play system SimpleStreamer based on
has only a flow in the network, but not have several audio/ SSTP
video streams, the payload of the QOS router for resource
reservation and the payload of end system is decreased. SimpleStreamer integrated the interface of IP QOS except that it
has simple structure, is scalable, sustains unicast and is easy to
3.3 PLAY SYSTEM manipulate. The client of the system can demand quality of
The above SSTP is only a protocol at transport layer, its main service based on his/her own requirement.
4 PERFORMANCE EVALUATION 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
We implement SSTP and SimpleStreamer player under
commodity Linux environment. In this section, performance Comparison of bandwidth overhead and
evaluation parameters and theoretic analysis results are net bandwidth
presented, followed by the experimental performance analysis The bandwidth overhead of a specific streaming transport
of SSTP and Simple Streamer based on the practical protocol is determined by several factors including MTU,
measurements. media frame rate, packet header length, packing method,
protocol control messages and the length/frequency of the
4.1 EVALUATION PARAMETER ACK messages. Taking minimum MTU=1280 bytes for
ANALYSIS IPv6 as an example, the bandwidth overhead of SSTP is
Following parameters are usually concerned for analysis of 3.9% compared to 9.8% for TCP. When the frame length
streaming transport protocol variation is considered, bandwidth overhead of RTP is
Extra bandwidth overhead for protocol operations, 9.9% ± 2.5%. SSTP is obviously more efficient than RTP.
i.e. bandwidth occupied by appended packet head and
control signaling when the same amount of net End system CPU usage comparison
streaming media is delivered. The end system CPU usage is determined by the
CPU usage of end systems. The complexity of the complexity of protocol operations and the number of RAM
protocol operation is measured especially at the access for packets retrieval. The CPU usage is expected to
streaming media server. The CPU cycles taken by the be as low as possible, especially that of the streaming
protocol is expected to be as few as possible. servers for which the CPU capacity is already a big issue.
Delay and jitter of data packets. Whether the packets
can arrive in time, and whether their arrival time are In a VOD system, media files are processed and stored in the
distributed uniformly will directly affect the playback storage systems of media servers. The load per second of the
effects of the streaming media. media server running RTP is at least M× （ Fread ＋ Fparse ＋
Loss rate of data packets. Certain extent of packet Fadd ） heavier than those running SSTP. Fread is the computation
loss rate is tolerable for the media stream, however, if amount in the process from distinguishing the starting tag of the
large amount of packets are lost in a short period, the frame to reading in the complete description information of the
playback quality will degrade severely. frame head. Fparse is the computation required for obtaining the
Whether the protocol is TCP friendly. As TCP frame length, frame playback time and other related information
streams constitute a large part of the traffic over the according to the description information conveyed in the frame
Internet, the ability to be TCP friendly is also an head. Fadd is the computation complexity for calculating the
important standard for streaming transport protocols. appended frame head. M usually falls between 23 and 30. F * is
As the infrastructure of the Next Generation Internet has closely related to the specific coding format of the media file
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 4.3 COMPARING SSTP’S PERFORMANCE TO
QoS mechanism in the IP layer, the delay jitter, loss rate and RTP’S PERFORMANCE
TCP friendliness mentioned above has been guaranteed and
need no further consideration theoretically, which means Theoretically, service requirements such as loss, delay jitter and
different protocols will perform consistently in these aspects. As 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
Experiment environment and methods
Fig.4 depicts the topology of our experimental network. figure 5 (b) jitter with QoS
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 5 (c) loss rate without QoS
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 figure 5 (d) loss rate with QoS
datagram transmitted by SSTP is also more then the that But from performance graphics above we notice that the loss
transmitted by RTP in networks which support the end-to- rate and jitter of datagram have been rapidly reduced when
end QoS. 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.
figure 5 (a) jitter without QoS
5 FUTURE WORK . 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-
The essential feature that differentiates streaming media Champaign, 1998.
application from the traditional ones is its time-sensitiveness. http://citeseer.nj.nec.com/hess98media.html
Overdue streaming packets make no sense for clients running . B. Mukherjee, “Time-Lined TCP: a Transport Protocol
real-time applications. So the greatest concern is to guarantee for Delivery of Streaming Media over the Internet”,
streaming data packets arriving at the clients in time. On the Master's thesis, University of Waterloo, Ontario, Canada,
other hand, in order to deliver more media streams 2000 ,
simultaneously under the limited bandwidth conditions of the http://citeseer.nj.nec.com/mukherjee00timelined.html
internet, the transportation efficiency of the streaming transport . Reynolds, J. and J. Postel, “Assigned Numbers, STD 2”,
protocols has to be taken into consideration. RFC 1700, October 1994
. Live Networks Inc., “LIVE.COM Streaming Media”,
The SSTP protocol based on IP QoS mechanism presented in www.live.com
this paper is the first step of design and implementation. . Henning Schulzrinne, Anup Rao and Rob Lanphier, "Real
Although the results of experiments do not live up to our Time Streaming Protocol (RTSP)", RFC2326, April 1998.
expectations, but the actual performance is approximately in . Chengyuan, “SSTP——a streaming media protocol on
accordance with theoretic analysis, which demonstrates that basis of QoS”, master thesis 2003 年。
SSTP protocol with underlying QoS support succeeds in . Deering, S. and R. Hinden, "Internet Protocol, Version 6
delivering media streams efficiently and promptly. (IPv6) Specification", RFC 2460, December 1998
. M. Handley and V. Jacobson, "SDP: Session Description
According to the above analysis results, we plan to improve Protocol", RFC2327, April 1998
SSTP from the following aspects: first, we will add at least . W. R. Stevens, “TCP/IP Illustrated, Volume 1: The
control signaling to SSTP through successive experiments to Protocols”, Addison-Wesley, Reading, Massachusetts,
improve the playback quality, save network bandwidth and 1994.
decrease the CPU usage. Then, we will devise an approach to . W. R. Stevens. “TCP/IP Illustrated, Volume 2: The
controlling buffer size of the receivers, at the same time Implementation”, Addison-Wesley, Reading,
maintaining a certain level of playback quality for memory Massachusetts, 1995.
limited networking devices. Finally, we will integrate an end-to- . Jian Lu, “Signal Processing for Internet Video Streaming:
end control signaling with the IP QoS mechanism in order to A Review”, Apple Computer Inc.
shorten the setup response time perceived by the clients through streamingmedialand.com/sp4streaming2.pdf
resource reservation and to grant clients the ability to adjust the . DivXNetworks, Inc. “DIVX Player”, www.divx.com
bandwidth allocated to them through previous requests. . Rob Koenen, “Overview of the MPEG-4 Standard”,
ISO/IEC JTC1/SC29/WG11 N4668, March 2002
REFERENCE . MP4 Forum, “MPEG-4 – The Media Standard The
landscape of advanced multimedia coding”, Nov 2002
. Microsoft Corporation, “Advanced Systems Format (ASF)
. S. Cen, C. Pu and J. Walpole, “Flow and Congestion Document Revision 01.20.00e”, Dec. 6, 2002
Control for Internet Media Streaming Applications”, in . R. Steinmetz and K. Nahrstedt, “Multimedia: Computing,
Proc. Multimedia Computing and Networking, January Communications, and Applications”, Prentice Hall PTR,
1998. New Jersey, 1995.
. Shulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, . K. Almeroth, “The evolution of multicast: From the
“RTP: A Transport Protocol for real-time applications”, MBone to inter-domain multicast to Internet2
RFC 1889, January 1996 deployment”, IEEE Network, January/February 2000.
. Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
Jamin , “Resource ReserVation Protocol -- Version 1
Functional Specification”, RFC 2205, September 1997.