[R-C] Feedback mechanisms

[Michael Welzl]

On Aug 14, 2012, at 5:36 PM, Bill Ver Steeg (versteb) wrote:

> Sorry for the spasm of email--- I am getting caught up correspondence.
>
> Note that the periodic feedback can convey more than a single  
> temporal datapoint. As I discussed in a previous email, the receiver  
> can inform the sender about trends or discontinuities in the data.  
> This is particularly useful if the sender and receiver can both  
> recognize/signal discontinuities in the data.
>
> So, I am arguing for periodic feedback that has a structure that  
> allows a rich information flow back to the sender. Based on such  
> data flows, the sender would like to glean "I am OK when I send at 2  
> Mbps or 3 Mbps, but the buffers are slowly building when I burst at  
> 4 Mbps and catastrophically congested when I burst at 5 Mbps". It  
> could also glean "I am sending at a constant rate, but I seem to be  
> getting sporadic cross traffic (or fade) that occasionally drives  
> delay". It obviously can also glean "Based on increasing delay and  
> the onset of loss, the channel can no longer support this rate, I  
> need to downshift" and "no loss and constant delay --- I am fine"  
> with some very short, infrequent messages. Knowing the statistical/ 
> temporal detail about delay is important, and worth some resources.
>
> Note that in addition to periodic feedback, timely feedback when  
> anomalous conditions occur is probably desirable.
>
> So --- IMHO, this is not a "do we do congestion control in the  
> sender or the receiver?" question. It is a question of cooperation  
> between the two to detect and set the correct rate. Knowing when to  
> upshift is as important as knowing when to downshift.

The tricky bit will be to avoid making it all too complex...

Cheers,
Michael