RealMedia Streaming Performance on an IEEE 802.11b Wireless LAN

T. Huang and C. Williamson

Proceedings of IASTED Wireless and Optical Communications (WOC) Conference Banff, AB, Canada, July 2002

Presented by Feng Li [email protected]

CS577 Spring 2005 1 Introduction

• Three fast-growing Internet technologies – World-Wide Web – TCP/IP to the masses – Multimedia streaming – real-time, on-demand audio/video to the home – Wireless networks – freedom from physical constraints of wires (anything, anytime, anywhere) Æ All available and relative low cost • This paper explores the convergence of the 3 – Focus on Real Media (popular) – Focus on IEEE 802.11b (popular)

5/25/2005 CS577 Spring 2005 2 Objectives

• Characterize network traffic by Real Media – Useful for capacity planning – Useful for building simulations/models • Relationship between wireless channel (error rate, delay, etc) and user quality – Use wireless “sniffer”, correlate with application • Ascertain impact of streaming on competing (ie- TCP) traffic – Impact of streaming on Internet traffic of interest

5/25/2005 CS577 Spring 2005 3 Outline

• Introduction (done) •Background •Methodology • Results •Related Work •Conclusions

5/25/2005 CS577 Spring 2005 4 IEEE 802.11b Wireless LAN (1 of 2)

• High speed (up to 11 Mbps, 11g up to 54)

• Specifies physical layer and MAC layer

• Physical layer allows 1, 2, 5.5, 11 Mbps – Higher rates achieved by using sophisticated modulation – Header transmitted at 1 Mbps with clocking information (so payload can be transmitted faster)

• Physical layer has loss, fading and interference – Result in corrupted packets, especially at high rates – So, dynamically adjust rates based on channel error rate

5/25/2005 CS577 Spring 2005 5 IEEE 802.11b Wireless LAN (2 of 2)

• Is shared broadcast, so MAC layer regulates access – Carrier-Sense Multiple Access with Collision Avoidance (CSMA/CA) or Distributed Coordination Function (DCF) – If station wants to send, senses channel – If idle for frame time, send packet – Otherwise, wait until idle + another frame time + random (double random time) • Data sent requires ACK. – No ACK, then resend. Give up after 4 tries. – Receiver ignores if CRC error. • Can be Infrastructure mode (AP) or ad-hoc mode (peer-to-peer)

5/25/2005 CS577 Spring 2005 6 Real Networks (1 of 2)

RTSP

Server Data: TCP or UDP

• Buffering • Sure Stream • Scalable Video Technology •Repair

5/25/2005 CS577 Spring 2005 7 Real Networks Streaming Media (1 of 2)

• , server, client • Reliable or unreliable • Live or on-demand • Header identifies – “Key frames”, decide to retransmit – Streaming rate • RTSP for communication – Control in TCP, data UDP – Parameters during session

5/25/2005 CS577 Spring 2005 8 Outline

•Introduction (done) • Background (done) • Methodology •Results • Related Work •Conclusions

5/25/2005 CS577 Spring 2005 9 Experimental Environment (1 of 2)

• Real Server 8.0, Linux, 1.8 GHz P-4, 10 Mbps NIC

• RealPlayer 8.0, 800 MHz P-3, Cisco Aironet 350 NIC

• AP lucent RG-1000 WAP, Retransmit limit set to 4

5/25/2005 CS577 Spring 2005 10 Experimental Environment (2 of 2)

• Video of a rock concert • Target rate about 200 kbps – above modem, below broadband • Short clip

5/25/2005 CS577 Spring 2005 11 Experimental Design

• Streaming with and without TCP/IP traffic • Classify wireless –Based on OS status meter • TCP background gener- ated from server to client •Three traces per experiment – Trace at server using tcpdump – Trace close to AP using sniffer – Trace at client using tcpdump • Get wireless and higher layers

5/25/2005 CS577 Spring 2005 12 Outline

•Introduction (done) • Background (done) • Methodology (done) •Results • Related Work •Conclusions

5/25/2005 CS577 Spring 2005 13 Baseline Throughput Results

•Use netperf for 60-seconds, 84 KB receive socket buffer, 8 times • Weaker signal, lower throughput • Maximum observed, 4.6 Mbps, less than 11 – 10 Mbps Ethernet not bottleneck –Only Poor has too low a throughput

5/25/2005 CS577 Spring 2005 14 Subjective Assessment

• Playback very smooth for Excellent and Good *

•For Fair, playback was jerky (lost frames?), but visual quality was good

• Audio was good for Fair-Excellent

•For Poor, playback was jerky, some pictures blurry and truncated, audio deteriorated – In some cases, setup failed

5/25/2005 CS577 Spring 2005 15 Effect of Wireless Channel (1 of 2)

5/25/2005 CS577 Spring 2005 16 Effect of Wireless Channel (2 of 2)

- App has different Bursty loss view of channel - Mostly, expects Still residual errors to be static

5/25/2005 CS577 Spring 2005 17 Application Layer Streaming Rate (1 of 2)

• Initial phase (10-20 sec) is higher rate (about 3x) • Audio always meets target rate (Real favors audio) • Excellent and Good similar, meet target video • Fair and Poor well below target rate - 17.5 kbps, 12.1 kbps 5/25/2005 CS577 Spring 2005 18 Application Layer Streaming Rate (2 of 2)

• Excellent and Good similar, meet target video • Fair and Poor well below target rate - 17.5 kbps, 12.1 kbps 5/25/2005 CS577 Spring 2005 19 Application-Layer Retransmission

• NACK based approach reasonable for lost packets • Excellent does not lose any • Raw loss: - Good has 0.3% - Fair has 10% - Poor has 30% • Effective loss: - Excellent and Good have none - Fair has 0.2% audio, 1.3% video (it looked good) - Poor had 7% audio, 28% video (deteriorating) 5/25/2005 CS577 Spring 2005 20 Is That True?

•One statement: “In our experiment, the only packets that miss the deadline are retransmitted packets.” page 6, left column. So I doubt this statements: Because some retransmitted packets may meet the deadline. I think the number of retransmitted packets should be greater than what they listed in their paper.

5/25/2005 CS577 Spring 2005 21 Streaming with Competing Traffic • Excellent channel • 10, 20, 30 ,40, 50 competing bulk-TCP – Should be 460, 230, 150, 115, 92 kbps

Asks for more than fair share so not TCP-Friendly

5/25/2005 CS577 Spring 2005 22 Outline

•Introduction (done) • Background (done) • Methodology (done) • Results (done) • Related Work •Conclusions

5/25/2005 CS577 Spring 2005 23 Related Work

• No wireless streaming (“To the best of our knowledge…”) • Mena et al RealAudio [11] – Non-TCP friendly, periodic • Wang et al RealVideo [19] – Average 10 fps, little full-motion video • Loguinov et al MPEG-4 emulation [10] – Modem, jitter, asymmetry • Chesire at al University workload (Levy)

5/25/2005 CS577 Spring 2005 24 Conclusions

• Wireless channel has bursty loss – but MAC layer retransmission can hide – Application layer takes care of most of rest •Goodand Excellent fine for some streaming •Fairand Poor have degraded quality • With TCP traffic, RealPlayer not fair

5/25/2005 CS577 Spring 2005 25 Discussion: Shortcomings of their experiments?

• Subjective Assessment of Streaming Quality. • Qualitative Characterization of wireless conditions, based on the Link Status Meter on the Cisco Aironet 350 devices. (eyeball tests)? • 68 secs video and low encoding bitrate.. However, in figure 5. From figure 5, the play back duration should be greater than 90 secs with poor signal strength. So I am asking one experiment is enough ? ( variability in throughput, and scaling?)

5/25/2005 CS577 Spring 2005 26 Future Work?

5/25/2005 CS577 Spring 2005 27 Future Work

• Larger scale study (more videos, encodings, …) • Effects of mobility • Effects on other users on WAP • Fragmentation to reduce loss • Other technologies (WSM …) • Estimating capacity

5/25/2005 CS577 Spring 2005 28 References

• Mark Claypool, slides for CS529 – http://www.cs.wpi.edu/~cs529/f04/slides/KW02.ppt

5/25/2005 CS577 Spring 2005 29