[R-C] Feedback mechanisms

[Stefan Holmer]

On Mon, Aug 13, 2012 at 12:20 PM, Michael Welzl <michawe at ifi.uio.no> wrote:

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

Worth noting that we have the option of only sending frequent feedback
(e.g. once per packet) when we experience congestion. The rest of the time
we can simply trigger the feedback periodically.


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

Might be simpler to have the FSE at the receiver as well in that case?


>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120813/1de04de4/attachment.html>