|
|
|||
|
Bibliography:
|
|||
|
Summary: This paper group focuses on the performance of streaming audio and video across the Internet. Streaming audio and video have different performance characteristics as compared to typical Internet traffic. Streaming media is sensitive to delay and jitter; however, it is not sensitive to small amounts of data loss. Streaming media prefers a steady data rate as opposed to a "bursty" type of data stream. In order to obtain a smoother bandwidth curve, UDP is often used as the transport protocol instead of TCP. This suggests that streaming media may not be TCP friendly because it will be unresponsive to network congestion. The primary paper in this group uses an empirical method to study the performance of streaming traffic, as it is served from several servers to a geographically diverse set of clients (12 different countries for clients and 8 different countries for servers). The authors are primarily concerned with the end user experience and build a correlation between server geographic location and end user experience. As expected, the infrastructure of the server's geography played a large role in the ability to consistently deliver a quality video stream to the end user. In order to measure the end user experience, the authors chose RealVideo server as their mechanism for streaming video due to its immense popularity. In addition, the RealNetworks SDK enabled the authors to build a custom player that gathered a number of performance metrics. These metrics included OS, system type, available RAM, IP address, server connected to, and a quality rating provided after the experience by the end user. Using these metrics the author's concentrated on frame rates of 3, 15, and 20 fps. In addition to these metrics they recorded the transport method and discovered that only 44% of their content was delivered using TCP-this suggests that RealVideo is TCP unfriendly. The author's concluded several items: RealVideo is a good mechanism to stream video, averaging 10 fps in their experiment. This number reflects the usage of an initial delay buffer which mitigates the effects of jitter. People who use modems and or slower computers experienced significantly more delay and jitter as opposed to people who used newer computers. Finally people who had new computers and fast connections often had a higher quality experience than corporate LAN users, which, suggests that the bottleneck is being pushed more toward the server than the client connection. The second paper is interested in dial-up clients' experience with low-bitrate streaming video. The author's of this paper researched this group of users by connecting to access points in 600 US cities. From these various access points they collected quality measurements as these clients received data from their server. The interesting aspect of this paper is this measurement method. The client machines were actually in their lab on the east coast and they dialed long distance to various access points around the US. They then connected back to their custom video server located on an Internet backbone. This is an excellent effort on their part to setup a realistic test scenario of real end user experiences. The authors used two MPEG4 constant bit-rate streams, each ten minutes in length. Both displayed a (176x144) image; however, the first stream was encoded at 14 kb/s and the other at 25 kb/s for a total transfer of 1.05 and 1.87 megabytes respectively. From these two streams they measured packet loss, jitter, round-trip delay, one-way delay jitter, packet reordering, and path asymmetry. Some of the authors conclusions are: Internet packet loss is bursty in nature. One way delay jitter has more of an effect on the end user experience than large round-trip times or packet loss. Average round-trip time positively corresponds to number of hops; however, packet loss and does not. The last paper is very much like the first, but the authors concentrate entirely on audio only. The authors are interested in characterizing audio flows so that they can be identified and perhaps regulated in some manner. They intend to show that streaming content is different from short flow applications like Telnet and HTTP. They accomplish this by gaining access to a major audio content provider and studying the flow characteristics of Real Audio. The author's conclude that indeed Real Audio is a long flow application
that does utilizes UDP 60-70% of the time. They also demonstrate
that audio flows have a very regular packet length, consistent bit
rate, and interpacket arrival times. Because of these characteristics,
they hope that by identifying these types of flows some type of
management can be performed. |
|||
|
Additional Resources:
|
|||
