a selective retransmission protocol for multimedia on the internet
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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
Applications:Text-Based vs. Multimedia
• Text– Strict loss constraints
– Minimal timing constraints
• Multimedia– Forgiving to loss
– Requires timing constraints
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!
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?
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
Decision Algorithms
Increasing Loss
Incr
ea
sing
Lat
enc
y
(Kleinrock, 1992)
(Request Retransmission)
(Give up)
Decision Algorithms
Increasing Loss
Incr
ea
sing
Lat
enc
y
(Kleinrock, 1992)
(Request Retransmission)
(Give up)
Policies-OQ-ELL
Acceptable Quality
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
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)
Sample SRP Session
Data Block
Time
Client Server
Request retransmission
(SequenceNumbers)
Sample SRP Session
Data Block
Time
Client Server
Do not request retransmission
Experiments
• UDP traffic generator
• Token bucket router to control loss and latency
• Audio session 8000 bytes/sec – Sample rate 160ms, packet size 1280
ClientClient
Traffic Generator
Traffic Generator
10BaseTnetwork
10Base2network
Traffic Generator
Traffic Generator
RouterRouter ServerServer
Sample Data
0
50
100
150
200
250
1 51 101 151 201 251 301 351 401 451 501 551 601
Packet Number
Lat
en
cy (
ms
)
0
5
10
15
20
25
30
35
40
45
Lo
st
Pac
ke
ts
Low Loss, Low Latency3% Loss , 50 ms Round Trip Time
0
0.2
0.4
0.6
0.8
1
1.2
1.4
0 0.5 1 1.5
Loss (normalized)
Lat
ency
(n
orm
aliz
ed)
SRP - ELL
SRP - OQ
UDP
TCP
(Kleinrock, 1992)
High Loss, High Latency15% Loss , 275 ms Round Trip Time
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
0 0.5 1 1.5 2
Loss (normalized) 10%
Lat
ency
(n
orm
aliz
ed)
250m
s
SRP - ELL
SRP - OQ
UDP
TCP
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)
Future Work
• Repair (FEC)
• Congestion control
• Loss detection (timeout)
• Additional decision algorithms
• Multicast
Evaluation of Science?
• Category of Paper
• Science Evaluation (1-10)?
• Space devoted to Experiments?