Rate Adaptation Protocol for Realtime 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 (contd)

• 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 TCPs 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 (contd)

• 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 TCPs 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