Back to index
Scalable Feedback Control for Multicast Video in the Internet
Jean-Chrysostome Bolot, Thierry Turletti, and Ian Wakeman
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.
- 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.
Need congestion control for video dissemination or the Internet will die.
This is a good first cut at how to do it in a scalable fashion.
- 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
Back to index