[R-C] Feedback mechanisms
Michael Welzl
michawe at ifi.uio.no
Wed Aug 15 12:13:07 CEST 2012
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
More information about the Rtp-congestion
mailing list