Additive Multiplicative slow start phase congestion avoidance phase
Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K
Average rate same as TCP travelling along same data-path (rate computed via equation), but CM protocol has less rate variance.
The design of good multicast congestion control protocols is far more difficult than the design of unicast protocols. Multicast congestion control schemes ideally should scale to large receiver sets and be able to cope with heterogeneous network conditions at the receivers. For example, if for all receivers the sender transmits packets at the same rate, care has to be taken as to how the sending rate is decreased in case of network congestion.
They[6] show that window-based congestion control can be TCP-friendly without knowing the RTT, whereas rate-based congestion control does need this information in order to be TCP-friendly. This is an important insight, since RTTs are difficult to obtain in a scalable fashion for multicast communication without support from the network.
A common criterion for classifying TCP-friendly multicast congestion control protocols is whether they operate at a single rate or use a multirate approach. unicast transport protocols are confined to single-rate schemes.
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, multiplicativedecrease (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
RAP in a typical end-to-end architecture for realtime playback applications in the Internet