applications
play

Applications: A Selective Text-Based vs. Multimedia Retransmission - PDF document

Applications: A Selective Text-Based vs. Multimedia Retransmission Protocol Text for Multimedia on the Strict loss constraints Internet Minimal timing constraints Mike Piecuch , Ken French, George Oprica and Mark Claypool


  1. Applications: A Selective Text-Based vs. Multimedia Retransmission Protocol • Text for Multimedia on the – Strict loss constraints Internet – Minimal timing constraints Mike Piecuch , Ken French, George Oprica and Mark Claypool • Multimedia – Forgiving to loss Computer Science Department – Requires timing constraints Worcester Polytechnic Institute Proceedings of SPIE Multimedia, Systems and Applications Conference Boston, November 2000 Our Solution: Protocols: A Selective Retransmission TCP vs. UDP Protocol • TCP • Balances the extremes of TCP and UDP • Tradeoff between loss and latency – No loss • Retransmits a percentage of lost packets – Retransmits all lost messages – Potentially large latency – If end-to-end delay is large, may accept loss • UDP – If end-to-end delay is small, may always request retransmission – Potentially unbounded loss – Does no retransmission – If loss rate is very high, may request retransmission – Minimal latency • Neither is what you want! – How to decide? Groupwork Decision Algorithms • Measure of loss • Measure of latency • Packet is lost Increasing Latency • … Do you request retransmission? • Consider: (Request Retransmission) – Quiet WAN, interactive audio (Give up) – LAN, broadcast video Increasing Loss – Lossy MAN, interactive audio (Kleinrock, 1992) 1

  2. Decision Algorithms Approach • Implement SRP and “application” • Setup “WAN” test-bed Acceptable Quality • Run “application” over Increasing Latency Policies – TCP - No loss - Low latency -OQ – UDP - Medium loss - Medium latency -ELL – SRP - High loss - High latency (Request Retransmission) • Measure “Quality” (Give up) • Analyze Results Increasing Loss (Kleinrock, 1992) Implementation of SRP Sample SRP Session • Application layer client/server protocol Data Client Server Block – No “kernel hacking” (yet) – Built on top of UDP • Measure loss and latency Time – Use to decide when to request retransmission • Decision algorithm modular – Equal Loss Latency (ELL) – Optimum Quality (OQ) (Sequence Numbers) Request retransmission Sample SRP Session Experiments Client Server Traffic Traffic Data Generator Generator Block 10BaseT 10Base2 network network Time Client Router Server • UDP traffic generator • Token bucket router to control loss and latency • Audio session 8000 bytes/sec – Sample rate 160ms, packet size 1280 Do not request retransmission 2

  3. Low Loss, Low Latency Sample Data 3% Loss , 50 ms Round Trip Time 250 45 40 1.4 200 35 1.2 30 Latency (normalized) Latency (ms) Lost Packets 1 150 25 SRP - ELL 0.8 S R P - O Q 20 100 UDP 15 0.6 TCP 10 50 0.4 5 0.2 0 0 1 51 101 151 201 251 301 351 401 451 501 551 601 0 Packet Number 0 0.5 1 1.5 (Kleinrock, 1992) Loss (normalized) High Loss, High Latency Conclusions 15% Loss , 275 ms Round Trip Time • TCP and UDP provide extremes 2 – Not what Multimedia wants 1.8 • SRP can provide a balance Latency (normalized) 250ms 1.6 1.4 • Tuning of SRP depends upon SRP - ELL 1.2 SRP - OQ 1 – Application UDP 0.8 TCP – Measure of “quality” 0.6 – Measurement of network (loss, RTT) 0.4 0.2 0 0 0.5 1 1.5 2 Loss (normalized) 10% Future Work • Repair (FEC) • Congestion control Future Work? • Loss detection (timeout) • Additional decision algorithms • Multicast 3

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend