RealMedia Streaming Performance on an IEEE 802.11b Wireless LAN

1. 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

2. 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 RealMedia (popular) • Focus on IEEE 802.11b (popular)

3. Objectives • Characterize network traffic by RealMedia • 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

4. Outline • Introduction (done) • Background • Methodology • Results • Related Work • Conclusions

5. 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

6. 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)

7. RTSP Server Data: TCP or UDP RealNetworks Streaming Media (1 of 2) • Buffering • SureStream • Scalable Video Technology • Repair

8. RealNetworks Streaming Media (1 of 2) • Codec, 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

9. Outline • Introduction (done) • Background (done) • Methodology • Results • Related Work • Conclusions

10. Experimental Environment (1 of 2) • RealServer 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

11. Experimental Environment (2 of 2) • Video of a rock concert • Target rate about 200 kbps • above modem, below broadband • Short clip

12. 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

13. Outline • Introduction (done) • Background (done) • Methodology (done) • Results • Related Work • Conclusions

14. 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

15. 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

16. Effect of Wireless Channel (1 of 2)

17. Effect of Wireless Channel (2 of 2) - App has different view of channel - Mostly, expects to be static Bursty loss Still residual errors

18. 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

19. 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

20. Application-Layer Retransmission • NACK based approach reasonable for lost packets • Good 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)

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

22. Outline • Introduction (done) • Background (done) • Methodology (done) • Results (done) • Related Work • Conclusions

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

24. Conclusions • Wireless channel has bursty loss • but MAC layer retransmission can hide • Application layer takes care of most of rest • Good and Excellent fine for some streaming • Fair and Poor have degraded quality • With TCP traffic, RealPlayer not fair

25. Future Work?

26. 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