[R-C] Feedback mechanisms

[Michael Welzl]

ARGH!

> 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.

I meant: Randell's !!

Michael


PS: I meant THAT text:

Just to be clear about the sender / receiver side thing, the amount of feedback is intrinsically bound to that decision - using the generic information that cc. mechanisms build upon (timers, sequence numbers, i.e. whether packets made it or not), anything that can be done on the receiver side can also be moved to the sender side, with the possible disadvantage of having more feedback.

If we define a generic framework for feedback and put the cc. mechanism on the sender side, we have exactly what pluggable congestion control in the Linux or FreeBSD TCP implementation already gives us: we can replace the sender side as we wish, without requiring any change on the receiver side. That is, if we define a generic feedback method, whatever is done at the sender side will work with any receiver that implements our method.

This game could also be played the other way 'round. Any congestion control mechanism eventually decides about a send rate. We could generically define to send the rate to the sender, and define for the sender to use that rate upon getting it, or else have a timeout after some predefined interval. Then, any mechanism could be placed on the receiver side, possibly limiting the feedback to the sender, and it's all going to work fine as long as the sender follows our generic rules. I still think that we should allow for that feedback to be very frequent (whenever that's acceptable), and for that case it would be good to have very small ACKs.

Yup, I think these are the two options we have, and I think we can and should decide which route we're going to take irrespective of the mechanism proposals on the table. All mechanisms can be implemented both ways.

The receiver-based method seems more flexible to me, as we CAN better limit the feedback with it if we want to. I'm however not sure if a CM-like functionality (e.g. my FSE proposal) for controlling multiple streams would work well with a receiver-based design.