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
CS577 Spring 2005

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 b (popular)
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

4. Outline Introduction (done) Background Methodology Results
Related Work
Conclusions
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

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)
11/19/2018
CS577 Spring 2005

7. Real Networks Streaming Media (1 of 2)
Server
RTSP
Data: TCP or UDP
Buffering
Sure Stream
Scalable Video Technology
Repair
Server-Player protocol
RTSP for control
UDP or TCP for data
Progressive Networks Architecture (PNA) for backward compatibility
HTTP if going through a firewall
Buffering (also called preroll)
for smoothness in the face of bandwidth changes
SureStream
different bandwidth encodings of the same clip
can switch on fly
Scalable video technology
Data and frame rate controlled by client speed
Audio data gets priority. If bwdith left, then video.
Repair
Forward Error Correction
Interleaving (at least for audio)
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

9. Outline Introduction (done) Background (done) Methodology Results
Related Work
Conclusions
11/19/2018
CS577 Spring 2005

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/19/2018
CS577 Spring 2005

11. Experimental Environment (2 of 2)
Video of a rock concert
Target rate about 200 kbps
above modem, below broadband
Short clip
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

13. Outline Introduction (done) Background (done) Methodology (done)
Results
Related Work
Conclusions
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

16. Effect of Wireless Channel (1 of 2)
11/19/2018
CS577 Spring 2005

17. Effect of Wireless Channel (2 of 2)
- App has different
view of channel
- Mostly, expects
to be static
Bursty loss
Still residual errors
11/19/2018
CS577 Spring 2005

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
kbps, 12.1 kbps
11/19/2018
CS577 Spring 2005

19. Application Layer Streaming Rate (2 of 2)
Excellent and Good similar, meet target video
Fair and Poor well below target rate
kbps, 12.1 kbps
11/19/2018
CS577 Spring 2005

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)
11/19/2018
CS577 Spring 2005

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.
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

23. Outline Introduction (done) Background (done) Methodology (done)
Results (done)
Related Work
Conclusions
11/19/2018
CS577 Spring 2005

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)
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

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?)
11/19/2018
CS577 Spring 2005

27. Future Work?
11/19/2018
CS577 Spring 2005

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
11/19/2018
CS577 Spring 2005

29. References Mark Claypool, slides for CS529
11/19/2018
CS577 Spring 2005