A Selective Retransmission Protocol for Multimedia on the Internet Mike Piecuch - WPI Ken French - WPI Mark Claypool - WPI http://perform.wpi.edu 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Questions? 11/18/2018