[R-C] Feedback mechanisms

[Michael Welzl]

On 13. aug. 2012, at 11:49, Harald Alvestrand wrote:

> On 08/13/2012 10:34 AM, Michael Welzl wrote:
>> Hm, hm, hm.  I'm not sure about that, either.
>> 
>> Let me try to sketch what I think would be good design and see what you people say - if there is a chance to get something like that to actually work:
>> 
>> First of all, I think that, to keep queues low, the sender needs as much feedback as it can possibly get. Say, one ACK for every packet. The amount of that feedback can be too much, but then the right thing to do would be to use some form of ACK congestion control, to reduce the amount of this feedback *only* when needed but generally send as much as possible. There are working methods for doing that, and they're not too complicated.
> I've already opted out at this point.
> The algorithm needs all the information it can get, but the idea that the algorithm is only executed at the sender is something I don't see as a given.
> 
> Data reduction at the receiver and considering the feedback volume / result tradeoff is not unusual.

Sorry if I created a confusion here: my second email, which answers Colin's, has a much clearer overview of what I think the design space is regarding sender-side or receiver-side control.

What I describe in that email as "receiver-side" has pretty much the same sender behavior as the RRTCC proposal, BTW, IIRC (haven't looked at the proposal for a while now). Yes, this looks more flexible regarding the amount of feedback, but it may be problematic regarding the control of multiple streams.

However, whether you put the control in the sender or receiver doesn't change what this first email suggests: that you may need a lot of feedback, whenever that's possible, to avoid queues, and that we may need very small ACKs for that if we can define them.

Cheers,
Michael