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
Presented by Feng Li lif_at_cs.wpi.edu
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 Real Media (popular)
• Focus on IEEE 802.11b (popular)

3
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

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
Real Networks Streaming Media (1 of 2)

• Buffering
• Sure Stream
• Scalable Video Technology
• Repair

8
Real Networks 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)

• 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

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
• 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)

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

22
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
23
Outline

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

24
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)

25
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

26
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?)

27
Future Work?
28
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

29
References

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