mcast_feedback_cntrl

Scalable Feedback control for Multicast Video Distribution in the Internet

J.-C. Bolot (INRIA), T. Turletti (INRIA), I. Wakeman (UCL), 1994

Summary. The authors propose a feedback control mechanism for real-time traffic that solicits feedback from receivers; feedback is based on the loss-rates of the receivers and is sent probabilistically; when congestion is detected by the source, it informs the application who then adjusts the rates.

More detail

It is desirable to have some sort of congestion control for the transport of real-time data, but the standard mechanisms used for bulk data transfer (such as those used in TCP) may not work because the goals for transport differ for the two types of applications: real-time traffic tends to be rate adaptive and the goal of transport should be to maximize the user-perceived quality while minimizing bandwidth; the bulk data traffic tends to be rate elastic and the goal of transport is to maximize throughput while minimizing delay.

Multicast creates special needs for feedback control: to achieve scalability, must distribute the feedback alg to the receivers, must avoid message implosion by limiting number of responders somehow, must map those responses received to the entire group and must figure out how to adjust the output rate fairly.

Other feedback control alg don't address multicast. Some other feedback control mechanisms require changes in network architecture.

Algorithm. The source needs the following information in order to determine if congestion is present and notify the application:

max RTT: used to determine how long to wait for responses from receivers.
congestion feedback: for obvious reasons.
estimate of the group size: determine how many bits in the keys will be significant which in turn implies how many rounds will be in an epoch (see below).

Congestion is determined by the loss-rate at the receiver. Decided in.an ad hoc manner that ``congested'' means loss-rate of 1.4%. There are three states that the network can be in: LOADED, UNLOADED, CONGESTED.

Feedback is received on a probabilistic basis. The source and receivers generate random keys. Based on an estimate of the number of receivers (don't know how this is bootstrapped), the source decides how many bits in the key will be significant bits used for matching by the receivers. When solicitations for feedback are sent out to the receivers, the receiver answers only if:

Its state of the receiver is greater than that specified in the source's packet and the key matches. In this case, the receiver sends a reply which includes the state.
The SIZESOLICITED bit is on and the key matches.
The RTTSOLICITED bit is on. In this case, the receiver waits for a randomly chosen delay between 0 and 2**RTTSHIFT (another source packet field) and then sends a reply which includes the chosen delay and the timestamp from the original source packet (the figure did not show this).
Question: what is ``maximum rtt'' field for?

Sample usage.Given the feedback mechanism, application must somehow utilize the feedback to control output rate. The authors implemented rate.control in a video coder using the feedback mechanism explained above. When CONGESTION detected, the coder can make 3 adjustments: refresh rate, quantizer and movement detection. The source specifies a maximum rate and a mode. The mode determines which adjustment to make when congestion is detected.

Since the source does not receive input from all receivers, it must estimate how much congestion is present based on those responses that it did get. It can do this because it knows the probability of a key match given the number of significant bits in the key and the estimated number of receivers.

Rate decreased +/*.

If the number of receivers is less than 10 (another ad hoc value, I believe) the receivers send a NACK if a block was lost since the number of receivers is low enough that this won't cause implosion. The block cannot be retransmitted, but the source does take that loss into account when encoding current blocks.

Performance. Graphed the loss-rates and bandwidth used over time. One can see that when the loss-rate was >5%, the bandwidth used is at a minimum; when <5%, the bandwidth used rises to the maximum allowed.