Rate Adaptation Protocol for Real-time Streams

1. Rate Adaptation Protocol for Real-time Streams • Goal: develop an end-to-end TCP-friendly RAP for semi-reliable rate-based applications (e.g. playback of real-time streams) • RAP employs an additive-increase, multiplicative-decrease (AIMD) algorithm with implicit loss feedback to control congestion • RAP separates congestion control from error control • RAP is fair as long as TCP operates in a predictable AIMD mode • Fine-grain rate adaptation extends range of fairness • RED enhances fairness between TCP and RAP traffic • RAP does not exhibit inherent instability

2. The RAP Protocol • RAP is implemented at source host • Each ACK packet contains sequence number of corresponding delivered data packet • From ACKs, RAP source can detect losses and sample RTT • Decision Function: if no congestion detected, periodically increase rate if congestion detected, immediately decrease rate • Congestion detected through timeouts, and gaps in sequence space • Timeout calculated based on Jacobson/Karel algorithm using RTT estimate (SRTT)

3. Decision Function (cont’d) • RAP couples timer-based loss detection to packet transmission - before sending a new packet, source checks for a potential timeout among outstanding packets using most recent SRTT • A packet is considered lost if an ACK implies delivery of 3 packets after the missing one (cf. fast recovery) • RAP provides robustness against ACK losses by adding redundancy to ACK packets

4. Increase/Decrease Algorithm • In absence of packet loss, increase rate additively in a step-like fashion • Upon detecting congestion, decrease rate multiplicatively • Rate controlled by adjusting inter-packet gap (IPG)

5. Decision Frequency • RAP adjusts IPG once every SRTT • If rate is increased by one packet, then slope of rate is inversely related to the square of SRTT (cf. linear increase of TCP) • RAP emulates the coarse-grain rate adjustment of TCP • RAP is unfair to flows with longer RTT as TCP

6. Clustered Losses • Right after loss of first packet, loss of following outstanding packets are silently ignored (cf. TCP-SACK) • Cluster-loss-mode terminated as soon as ACK for a packet after that cluster is received

7. Fine-Grain Rate Adaption • Goal: make RAP more stable and responsive to transient congestion • Emulate a degree of congestion avoidance that TCP obtains due to ack-clocking (self-limiting) • During a given step, multiply IPG by ratio of short-term average RTT to long-term average RTT

8. RED • A TCP flow suffers if it experiences multiple losses within a window • RAP always follows AIMD and reacts only to first loss in an RTT • RED limits divergence of TCP from AIMD

9. Simulations • RAP is in general TCP-friendly, even without fine-grain rate adaptation • The more TCP diverges from AIMD, the less bandwidth it obtains • RAP compared to TCP-SACK to avoid TCP’s inherent performance problems • Measure inter-protocol fairness: ratio of average RAP bandwidth to average TCP bandwidth • Resources scaled linearly with number of flows to maintain share per flow fixed and operate TCP in its well-behaved mode • Varying number of flows and RTT

10. Simulations (cont’d) • For a wide range of RTT, increasing number of flows improves fairness (ratio converges to 1) • Not true for small RTT (or small pipe size) due to the small size of TCP’s congestion window • Fine-grain rate adaptation prevents RAP flows from overshooting the available bandwidth share • Thus, reducing loss for TCP flows and improving fairness • RED, if configured correctly (i.e. maxP not too large or too small), improves fairness between RAP and TCP