Scalable Feedback Control for Multicast Video in the Internet

One-line summary: Probabilistic methods are used to sample the receiver space and gain knowledge of the worst RTT of the group, the worst congestion state of the group, and the number of members of the group - this is in turn used to control video dissemination.

Overview/Main Points

• Need congestion control for video - but danger of control information implosion at source if congestion feedback is sent from all receivers.
• Send out a random N bit key with multicast probe packet - if a receiver key matches the probe key, the receiver responds with control information. If the source receives no responses, it decreases N by 1 bit and repeats. This way we eventually probabilistically sample the receiver population space.
• Receivers return the STATE of the network - congestion (indicates to the application to slow down), unloaded (all is well, app should increase rate), or loaded (continue sending at this rate).
• Inria built the IVS video conferencing system (H.261 codec over multicast IP). This control method allows the video conferencing system to throttle back video information (by throwing away high frequency components, movement detection threshold or frame rate) - IVS trades quality for bandwidth based on this feedback. (SG - sounds familiar, eh?)
• The assignment to LOADED, UNLOADED, or CONGESTED is based on the packet loss rate at the receivers; authors talk about wanting to use some perceptual quality indicator, and their not being an objective enough one.
• Difficulty in deciding what fraction of receivers indicating CONGESTED should trigger the source to slow down video rate - ideally want to differentiate between different parts of the multicast tree (SG - a la VGW?).
• Uses additive increase, multiplicative decrease in video rate.
• Theory shows that scalable method works - inverse exponential relationship between number of bits in probe packet and probability that a receiver will respond (duh). Experiments at Inria show that this seems to work well in practice as well.

Relevance

Flaws

• Single control mechanism for all receivers is not good - nearly nobody gets the optimal rate. What about those poor saps on ISDN lines - they get flooded?
• Probabilistic methods not so good for identifying low/high bandwidth regions of the multicast tree; want to identify them and deal with them separately.
• Receiver method for deciding when to report congested seems half-baked.