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

Recommend


More recommend