Research for streaming media transport protocols on basis of



                                                    next g...
and congestion in network, it usually requires a long time to              protocol design is to provide a real-time, sequ...
What is more, because IP layer will provide end-to-end QoS
guarantee in next generation internet, RTCP is useless in NGI. ...
mode and frame mode. At byte-stream mode, the server is              function is transporting media stream. In practical m...
4     PERFORMANCE                     EVALUATION                   a result, the performance evaluation of streaming proto...
networking infrastructure with end-to-end QoS mechanism.
However, as NGI technology is still in its infancy, the practical...
5 FUTURE WORK                                                     [3]. C. K. Hess, “Media Streaming Protocol: An Adaptive
...
[20]. Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
     Jamin , “Resource ReserVation Protocol -- Version 1
 ...
Upcoming SlideShare
Loading in …5
×

Full Paper - BACK

256 views
205 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
256
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Full Paper - BACK

  1. 1. 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 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 Keywords PROTOCOLS 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 1
  2. 2. 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 Cen[3]proposed 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 PROTOCOL 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. 2
  3. 3. 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 IPv6(QoS)  Function description of SSTP Figure 1 Position of SSTP in protocol layers Two transport modes are applied in SSTP: byte-stream 3
  4. 4. 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 SETUP 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 Media flow server 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, server client the transport rate of data packets is absolutely constant, it Streamin play g is convenient for processing QoS (i.e. to alleviate the work control control SimpleStreamer Recorded Media of shaping at ER), meanwhile, it is easy to reserve Media flow file file 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
  5. 5. 4 PERFORMANCE EVALUATION a result, the performance evaluation of streaming protocols for NGI will concentrate on bandwidth and CPU usage. AND COMPARISON 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 [8]. 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 5
  6. 6. 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. 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. IPv6 backbone figure 5 (c) loss rate without QoS Edge router client Streaming media server 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 6
  7. 7. 5 FUTURE WORK [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- 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 [4]. 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 [5]. Reynolds, J. and J. Postel, “Assigned Numbers, STD 2”, protocols has to be taken into consideration. RFC 1700, October 1994 [6]. 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. [7]. 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 [8]. 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 [9]. Deering, S. and R. Hinden, "Internet Protocol, Version 6 delivering media streams efficiently and promptly. (IPv6) Specification", RFC 2460, December 1998 [10]. 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 [11]. 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 [12]. 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- [13]. 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 [14]. DivXNetworks, Inc. “DIVX Player”, www.divx.com bandwidth allocated to them through previous requests. [15]. Rob Koenen, “Overview of the MPEG-4 Standard”, ISO/IEC JTC1/SC29/WG11 N4668, March 2002 REFERENCE [16]. MP4 Forum, “MPEG-4 – The Media Standard The landscape of advanced multimedia coding”, Nov 2002 [17]. Microsoft Corporation, “Advanced Systems Format (ASF) [1]. 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 [18]. R. Steinmetz and K. Nahrstedt, “Multimedia: Computing, Proc. Multimedia Computing and Networking, January Communications, and Applications”, Prentice Hall PTR, 1998. New Jersey, 1995. [2]. Shulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [19]. 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. 7
  8. 8. [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

×