[R-C] Feedback mechanisms

[Stefan Holmer]

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

>
> On 13. aug. 2012, at 13:43, Stefan Holmer wrote:
>
>
>
> 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.
>
>
> I agree, that sounds like a good method to me.
>
>
>
>>
>> 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?
>
>
> Yes, I guess that's a good idea anyway. The assumption for the FSE is that
> it gives congestion controllers information about all flows that share the
> same bottleneck. In RTCWEB, such flows can be trivially identified by
> knowing that they use the same UDP port number pair, which would lead to
> identifying the same set of flows on the sender- and receiver side.
> However, we should not exclude the possibility of implementing a
> measurement-based shared bottleneck detection scheme which would feed
> information into the FSE...
>
> In that case, a sender may be in control of multiple streams that go to
> various destinations yet share the same bottleneck. Similarly, a receiver
> may have incoming streams that come from various sources yet share the same
> bottleneck.
>
> So yes, this calls for having an FSE in the sender AND receiver I think.
>

Agreed.


>
> Cheers,
> Michael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120813/bf5743d4/attachment-0001.html>