1 / 34

Performance of Video-Chat Applications Under Congestion

Performance of Video-Chat Applications Under Congestion. O. Boyaci, A. G. Forte, H. Schulzrinne Department of CS Columbia University, New York, NY. Proceedings of 11th IEEE International Symposium on Multimedia (ISM) December 2009. Introduction (1 of 3).

bessie
Télécharger la présentation

Performance of Video-Chat Applications Under Congestion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Performance of Video-Chat Applications Under Congestion • O. Boyaci, A. G. Forte, H. Schulzrinne • Department of CS • Columbia University, New York, NY • Proceedings of 11th IEEE International Symposium on Multimedia (ISM) • December 2009

  2. Introduction (1 of 3) • High speed Internet should consider many last-mile technologies • ADSL, Cable, satellite • Many of these have asymmetric bandwidths • Ex: ADSL common 3 Mb/s down, 1 Mb/s up • Many common apps (Web, Video streaming) fine with more bandwidth down • But video chat (or video conferencing or interactive video) needs to send video as well as receive it • Uplink can become bottleneck • Worse when there is cross traffic • This paper focuses on uplink

  3. Introduction (2 of 3) • Changes in bandwidth due to congestion can affect video and audio • Video suffers more given higher bwidth reqs. • Needs to detect congestion first • Distinguish congestion loss versus wireless loss • (Why?) • Way application reacts can result in “fair share” or increase in overall congestion

  4. Introduction (3 of 3) • Different ways of having congestion from contending traffic • Consider: fixed changes, HTTP (file download), Bit Torrent • Tested: Skype 4.0.0.215, Windows Live Messenger14.0.8064.206, Eyebeam 1.5.19.5.52345, and X-Lite 3.0.47546 • Note, Eyebeam and X-Lite both from from Counterpath • X-Lite free, older codec version (lower visual quality)

  5. Teaser • Skype behaved best • Adapted to packet loss, RTT and jitter • Followed changes in bandwidth without causing loss • Eyebeam performed worst • High fluctuations in transmission speed • Poor adaptation to bandwidth fluctuations

  6. Outline • Introduction (done) • Related Work (next) • Loss • Measurements • Conclusions

  7. Related Work (1 of 2) • Popular video (Youtube, Hulu, Netflix, Joost) have it easier [8, 12] • Use TCP and can can have large buffer • Content stored at various bitrates • Youtube and Hulu – users select • Netflix – chooses automatically • Video chat often uses UDP (as in this study) • Want to avoid underutilization (lower quality) • Want to avoid overutilization (unfair, congestion)

  8. Random Loss vs. Congestion Loss • Generally, packet loss a sign of congestion (e.g. TCP does this with dupacks) • When is this not the case? … wireless • Causes of wireless loss: signal fading, obstacles, co-channel interference • Many of these not due to congestion • Lowering sending rate due to wireless loss may needlessly lower quality • Video chat could use algorithm, such as Spike [14] to distinguish loss type • Spike looks at loss and one-way delay time

  9. Related Work (2 of 2) • Audio chat studied extensively • Latency for audio [4] • Bandwidth and adaptation for Skype audio [6] • But … video not as much • Skype’s responsiveness to video [5] • This paper Skype, Live, Eyebeam, X-Lite

  10. Outline • Introduction (done) • Related Work (done) • Loss (done) • Measurements (next) • Conclusions

  11. Setup • Sender and Recevier for Video • Lenovo Thinkpad X63 laptops • Windows Vista • Wireshark PC -FreeBSD 7.1 -Dummynet to control: queue, RTT, bwdith, loss

  12. Parameters • Emulate ADSL • 114 ms for RTT • Queue size 60 KB • 3 MB/s downlink • 1 MB/s uplink • Three experiments: • Changes in bandwidth • File upload (HTTP) cross traffic • File upload (BitTorrent) cross traffic

  13. Changes in Bandwidth • Step function 1 • Decrease bandwidth by 80 kb/s every 10 seconds • Then increase (same way) • Step function 2 • Decrease bandwidth by 400 kb/s every 10 seconds • Then increase (same way)

  14. Skype with 10-10 Step Function - Adjusts promptly - Minimum rate, drops call - Note, uses jitter and RTT not just lossC

  15. Windows Live with 10-10 Step Function • - Drastically drops video (audio left alone) • Very low, adds FEC to audio • Minimum is 50 kb/s

  16. Eyebeam 10-10 Step Function • Uses H.264 - Doesn’t respond to increase • Tries to keep audio and video • Adds FEC • Only 2 bitrates, high fluctuations

  17. X-Lite 10-10 Step Function • Only has H.263 • Minimum of 180 kb/s, even at 100% loss • Uses FEC for audio (exacerbates problem) • Does not drop call, even if no bwidth

  18. Windows Live with 10-50 Step Function • Adjusts quickly to congestion • Adjusts slowly to lack of congestion • (Live better than others, which are not shown)

  19. Subjective Evaluation • Skype and MSN • Drop video frames, but no visual artifacts • Little packet loss • X-Lite and Eyebeam • Try to keep frame rate, but have lots of artifacts • Lots of packet loss • Only Skype always preserved audio quality

  20. HTTP as Cross Traffic • Traffic competes with video and audio for bandwidth • Again, Dummynet settings the same • HTTP traffic on uplink loads 9 MB file to Media Fire • (I’m going to call this file upload)

  21. X-Lite with File Upload • Traffic doesn’t really change at all • Both get close to the same bandwidth

  22. Eyebeam with File Upload • Similar to X-Lite, but loss rate higher • (Probably because traffic fluctuates more)

  23. Skype with File Upload • Adapts by lowering transmission rate • Low packet loss

  24. Windows Live with File Upload • Does not adapt much • Loss rates periodically higher

  25. BitTorrent as Cross Traffic • Used Vuze [15] and didn’t limit maximum update rate • In general, BitTorrent can have many connections • Paper says about 20 connections

  26. X-Lite with BitTorrent • Again, does not adapt much • Loss rates higher than for file upload • Also limits BitTorrent

  27. Eyebeam with BitTorrent • Again, does not adapt much • Loss rates higher than for file upload • Loss rates higher than for X-Lite

  28. Skype with BitTorrent • Skype lowers rate consistently, giving more data to BitTorrent • Once BitTorrent stops, goes back up

  29. Windows Live with BitTorrent • Lowers rate considerably • Goes back up slowly when BitTorrent gone

  30. Random Losses • Add random losses • Since not from congestion, perhaps video applications would not adapt • Add 1% loss • Case 1: during entire session • Case 2: during middle of session

  31. Eyebeam, X-Lite and Live with Random Losses • Eyebeam and X-Lite • Do not adjust rates at all • Windows Live • Not reported

  32. Skype with Random Losses • For loss in the middle (top), Skype adds 20% FEC • Note, during congestion, decreased rate • For constant loss (bottom), increases gradually (not full speed right away) • Here, can’t determine change in delay

  33. Conclusions • Built testbed to emulate DSL • Control cross traffic: Fixed changes, File Upload, BitTorrent • Analyzed four popular clients: Skype, Windows Live Messenger, X-Lite, Eyebeam • Skype adapts gradually to congestion and to lack of it • Live adapts quickly to congestion, slow increase • X-Lite and Eyebeam do not change during cross traffic, go down during restricted bandwidth but not back up • Eyebeam strong fluctuations

  34. Future Work? • (Paper lists none)

More Related