1. A Selective Retransmission Protocol for Multimedia on the Internet
Mike Piecuch - WPI
Ken French - WPI
Mark Claypool - WPI
Introduce ourselves
Selective Retransmission Protocol
Purpose of SRP
Stream multimedia over a network.
The Internet has been dominated by text based applications such as http, ftp, telnet.
With new technology, Emergance of multimedia based apps.
11/18/2018

2. Text vs. Multimedia Strict loss constraints Minimal timing constraints
Forgiving to loss
Requires timing
constraints
Text based and multimedia applications have very different needs
Text based application cant tolerate losses, for example a ftp session with loss could cause corrupted files. Timing is not a factor as long as the transfer is eventually completed.
Multimedia can handle a small amount of loss, there are many ways to recover from a loss such as substitute frames and redundant data.
Latency, which is defined as Time from when a message is sent to when it is played back, is more of a factor for multimedia than text based applications.
A late packet in a multimedia stream can miss the time it needs to be played and is viewed as a loss.
11/18/2018

3. TCP vs. UDP No Loss Retransmits all lost messages Unbounded Latency
Unbounded Loss
Retransmits no lost
messages
Minimal Latency
The two most commonly used protocols over the Internet are Transport Control Protocol (TCP) and User Datagram Protocol (UDP)
TCP guarantees delivery with no overall loss
automatically retransmits all messages that don’t arrive in time
flow control
slows transmission rate from a fast sender, overwhelming a slow receiver.
Congestion Control
prevents the network from being overloaded.
The cost of guaranteed delivery is unbounded latency where messages can theoretically take a very large amount of time to be received
UDP has no guarantees on delivery, so potentially all data in a stream can be lost.
However with no retransmission overhead, there is minimal latency
11/18/2018

4. Solution – Selective Retransmission Protocol
Balances the extremes of TCP and UDP
Tradeoff between loss and latency
Retransmits a percentage of lost packets
Control based on needs of media
- Interactive video vs. broadcast audio
To remedy problems of multimedia transmission by TCP or UDP we designed and implemented the
SRP - Selective Retransmission Protocol
Balance between extreme latency of TCP and extreme loss of UDP
Tradeoff through retransmission of lost packets.
retransmit – regain loss packet, cost in latency of asking for it to be resent
not retransmit – recover quickly, cost of lost packet
Provide a medium loss, medium latency stream
Retransmits percentage of lost packets (all, none)
Decision based on the user-specified needs of the media
Example: interactive video stream:
strict latency constraint (interactive), forgiving loss constraint (video corrected)
Broadcast audio stream:
forgiving latency constraint (not interactive) and strict loss constraint (humans perceive even small errors)
11/18/2018

5. Implementation Application layer client/server protocol
Balances loss and latency through selective retransmission.
Modular decision algorithms
- Equal Loss Latency (ELL)
- Optimum Quality (OQ)
SRP, Application layer, UDP foundation
Fat Client / Thin Server, server sends at even interval.
Client selects messages to request retransmissions for when losses detected (current loss/latency statistics, balance overall)
loss is detected, decision Algorithm
To decide whether to
Retransmit for OR
Give up on the message
algorithm is modular, customized for specialized conditions and media
Two algorithms have been experimented with
ELL
equalize overall loss and latency. OQ
minimize overall loss and latency
11/18/2018

6. (Request Retransmission)
Decision Algorithms
Increasing Latency
(Request Retransmission)
(Give up)
Increasing Loss
(Kleinrock, 1992)
11/18/2018

7. (Request Retransmission)
Decision Algorithms
Increasing Latency
(Request Retransmission)
(Give up)
Increasing Loss
(Kleinrock, 1992)
11/18/2018

8. Sample SRP Session Data Block Client Server Time 11/18/2018
Time flows from top to bottom
Green blocks represent multimedia messages
Client left, server right.
Server breaks up a multimedia stream into packets
Messsages sent from server at constant rate
Received at client
Client can determine expected time of arrival (average)
If a message is not received at the expected time message is lost (TCP RTO)
Deciscion algorithm called (retransmit, give up) balance the overall loss and latency
This case: retransmit
Request sent to server to resend lost message
Message is regained, lowering overall loss, cost of higher latency
A loss later on, given up on, lowering latency, cost of higher loss (balancing)
Each retansmission round trip time, time probes sent, accurate RTT, when to expect
received too late for playback, useless – dropped
Received too early for playback, cached for later use
11/18/2018

9. Sample SRP Session
Data Block
Client
Server
Time
11/18/2018

10. Implementation Details
Retransmissions cost RTT
Late and early messages
Client and server buffers
Many details to be overcome during implementation of SRP
retransmissions propagate at RTT, time probes, accurate, expected
Messages could arrive late or early for playback
Late messages – useless, dropped
Early – cached for later use
Two buffers,
client – storing cached early messages
server – storing all sent messages, resent later if needed.
11/18/2018

11. Experiments UDP traffic generator
10BaseT
network
10Base2
network
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
In order to test our SRP protocol we had to simulate a Wide Area Network (WAN). We configured 5 Linux PCs, 2 to run SRP, 2 Traffic Generators, and 1 router.
The machines were 486 class computers with 16MB ram. They ran Red Hat 6.0 for an Operating System.
SRP session from client to server through router
all data recorded on client
Simulate a real network
Traffic Generators
UDP Blaster to send competing random traffic over network
Linux PC to function as a token bucket router
11/18/2018

12. Sample Data
This is a sample of data received on the client from a SRP session
Each time a packet came in, we recorded latency and loss
This graph shows the latency and loss for the session
Blue data series is the per packet latency
y-axis Left hand scale (milliseconds)
x-axis is packet number received
Spikes are caused by retransmissions due to the protocol waiting for a reply
Rising pink data series is lost packets
y-axis Right hand scale (packets)
Rises every time there is a packet loss
11/18/2018

13. Low Loss, Low Latency (Kleinrock, 1992) 11/18/2018
Using an average of the data acquired during testing
created an overall quality graph Klenrock type graph
compare each protocol’s performance for different network conditions
Low Traffic
3% Loss 50ms Latency
Axes
Y-axis - Average Latency X-axis - Average Loss
Scales are normalized based on desired loss and latency
loss – 10% latency - 250ms
Arc is range of acceptable qualities
Closer to the origin, the better the quality Origin is perfect quality
TCP mostly due to flow control did not provide acceptable quality
UDP provides
some loss very low latency OQ
has no loss low latency
ELL
did not perform as well as OQ
(Kleinrock, 1992)
11/18/2018

14. High Loss, High Latency 11/18/2018 High Traffic conditions 15% loss
275ms RTT
TCP
off the chart
due to flow control
UDP
Highest loss
Lowest latency
ELL
better than UDP OQ
only protocol within the acceptable quality range
11/18/2018

15. Conclusions SRP is a good balance
Potential replacement for TCP and UDP
for multimedia
Additional tuning
SRP is good balance of
High loss of UDP
High latency of TCP
Great potential for
replacing TCP and UDP for multimedia
Tuning can
increase performance of SRP even in extreme network conditions
11/18/2018

16. Future Work Flow control Loss detection Additional algorithms
Multicast
Flow control can be added to reduce the impact on the network environment
in the idea of TCP’s flow control mechanisms to share network bandwidth fairly
The loss detection algorithm can be improved because it is difficult to know how long to wait for packet
Also additional algorithms can be created for
different network conditions
multimedia characteristics
IP Multicast is an efficient mechanism for disseminating data from a sender to a group of receivers.
Instead of sending a separate copy of data to each individual receiver, the sender sends a single copy to all receivers.
Modifications could be made to SRP to better support multicast applications
11/18/2018

17. Questions?
11/18/2018