1 / 18

A Selective Retransmission Protocol for Multimedia on the Internet

A Selective Retransmission Protocol for Multimedia on the Internet. Mike Piecuch, Ken French, George Oprica and Mark Claypool Computer Science Department Worcester Polytechnic Institute. Proceedings of SPIE Multimedia, Systems and Applications Conference Boston, November 2000.

neith
Download Presentation

A Selective Retransmission Protocol for Multimedia on the Internet

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. A Selective Retransmission Protocol for Multimedia on the Internet • Mike Piecuch, Ken French, George Oprica and Mark Claypool • Computer Science Department • Worcester Polytechnic Institute • Proceedings of SPIE Multimedia, Systems and Applications Conference • Boston, November 2000

  2. Applications:Text-Based vs. Multimedia • Text • Strict loss constraints • Minimal timing constraints • Multimedia • Forgiving to loss • Requires timing constraints

  3. Protocols:TCP vs. UDP • TCP • No loss • Retransmits all lost messages • Potentially large latency • UDP • Potentially unbounded loss • Does no retransmission • Minimal latency • Neither is what you want!

  4. Our Solution:A Selective Retransmission Protocol • Balances the extremes of TCP and UDP • Tradeoff between loss and latency • Retransmits a percentage of lost packets • If end-to-end delay is large, may accept loss • If end-to-end delay is small, may always request retransmission • If loss rate is very high, may request retransmission • How to decide?

  5. Groupwork • Measure of loss • Measure of latency • Packet is lost • … Do you request retransmission? • Consider: • Quiet WAN, interactive audio • LAN, broadcast video • Lossy MAN, interactive audio

  6. Decision Algorithms Increasing Latency (Request Retransmission) (Give up) IncreasingLoss (Kleinrock, 1992)

  7. Decision Algorithms Acceptable Quality • Policies • OQ • ELL Increasing Latency (Request Retransmission) (Give up) IncreasingLoss (Kleinrock, 1992)

  8. Approach • Implement SRP and “application” • Setup “WAN” test-bed • Run “application” over • TCP - No loss - Low latency • UDP - Medium loss - Medium latency • SRP - High loss - High latency • Measure “Quality” • Analyze Results

  9. Implementation of SRP • Application layer client/server protocol • No “kernel hacking” (yet) • Built on top of UDP • Measure loss and latency • Use to decide when to request retransmission • Decision algorithm modular • Equal Loss Latency (ELL) • Optimum Quality (OQ)

  10. Sample SRP Session Data Block Client Server Time (Sequence Numbers) Request retransmission

  11. Sample SRP Session Client Server Data Block Time Do not request retransmission

  12. Traffic Generator Traffic Generator 10BaseT network 10Base2 network Client Router Server Experiments • UDP traffic generator • Token bucket router to control loss and latency • Audio session 8000 bytes/sec • Sample rate 160ms, packet size 1280

  13. Sample Data

  14. Low Loss, Low Latency (Kleinrock, 1992)

  15. High Loss, High Latency

  16. Conclusions • TCP and UDP provide extremes • Not what Multimedia wants • SRP can provide a balance • Tuning of SRP depends upon • Application • Measure of “quality” • Measurement of network (loss, RTT)

  17. Future Work?

  18. Future Work • Repair (FEC) • Congestion control • Loss detection (timeout) • Additional decision algorithms • Multicast

More Related