A Selective Retransmission Protocol for Multimedia on the Internet Mike Piecuch, Ken French, George Oprica and Mark Claypool Computer Science Department.

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?