Re: [rmcat] How we should handle feedback, and where the congestion should run

[Michael Welzl <[e-mail]>]

> On 06 Nov 2015, at 01:43, Randell Jesup <[e-mail]> wrote:
> 
> The line in the room was cut, but a few comments:
> 
> Even if RMCAT yields a single algorithm, having a standardized feedback message will help future work to improve on the algorithm, or to develop or deploy future algorithms.  This will not be the last work done in this area, and I'm sure improvements will be worked on, and people will trial alternative algorithms.  Getting support for the "other end" is a huge step forward in trialing (or deploying) an algorithm.
> 
> Also it appears there are multiple implementers dealing with the bandwidth and frequency for RTCP traffic if the control is on the sender side.  Almost all algorithms *can* be moved to run entirely on one side or on the other.  Running it on the receiver side can dramatically reduce the feedback required (as Michael said in the room).  Given use of the RTP send-time header extension, there's very little info that the sender has that the receiver doesn't (mostly just the size and timing of any lost packets).  The bandwidth for sending CC results would be far less than any (compressed or not) arrival time feedback to the sender.
> 
> Running on the receiver also means that no "merging" of feedback data needs to be done to run CC across multiple streams/5-tuples/etc.
> 
> We can build a generic arrival-time feedback message, or we can build a generic results-of-receiver-CC message.

The big problem I see with receiver-side schemes is that you don't only need to standardize 1) the feedback message, you also need to standardize the sender behavior in the absence of feedback.
2) If feedback is missing for a while, maybe that's a good thing, as a result of feedback suppression?  So we just gradually and blindly increase the rate?  See early versions of the GCC scheme.
3) If feedback is missing for a long time, at some point you HAVE to have a timeout and react accordingly.

Can we agree on all these things? At least 1) AND 3) are necessary.

To me, this seems like creating difficulties for a problem that MAY also be a non-problem. Note that TCP sends tons of feedback, maybe including SACK blocks, across the same thin uplinks that we're considering. I don't think there is conclusive evidence of that being a problem.

=> I tend to think that moving everything to the sender side is an easy way out.

Cheers,
Michael