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

[Randell Jesup <[e-mail]>]

On 11/6/2015 2:52 AM, Michael Welzl wrote:
> 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.

I agree that we'd need to standardize that when using a receiver-side 
algorithm with a generic message (i.e. not a matched sender with a 
custom/private message), the sender side must be prepared to deal with 
1) and 3) and likely 2), and we would need to specify fairly completely 
the sender-side behavior in response to the feedback (though that 
behavior can be simple).  I.e. the send will attempt to send at the rate 
requested in a feedback message; will inform codecs of the new rate as 
fast as possible; will optionally pace data entering the network to not 
exceed either the congestion rate, or a separate pacing rate supplied.  
Time periods for calculating both rates shall also be provided, though 
the sender may not be able to use an arbitrary time for calculating rate 
(i.e. encoders may not be flexible on that - easier to do for pacing).

In terms of 1/2/3 above: if we do this, the receive-side algorithm could 
configure the sender via these messages and/or negotiation. The feedback 
messages can (optionally) have control information that tells the sender 
what to do on missing feedback, and when.  For example, it could have a 
feedback-timeout field, or timeout and what-to-do-at-timeout fields.  We 
could also define a "are you still there" RTCP that can be sent when we 
see feedback timeouts or are getting close to them, asking the receiver 
to resend (and exactly how to respond to those can be part of the 
receive-side CC algorithm).  It could include updated RS/RR stats for 
any RTP flows, letting the receiver-side update their idea of the 
return-path congestion.

This brings up a more general point for coupling congestion control (I 
forget if this has been discussed) - not only can it make sense to 
couple multiple CC's running in the same direction, but also to inform 
CC's of return-path congestion (and expected network delay!) that 
feedback (RTCP) will contend with.  This applies no matter which end the 
algorithms run at.

I'm sure more specification of a standard receive-side feedback message 
would needed if we decide to go that way; the above would be a start.  I 
do think it's *very* worthwhile defining a standard for feedback 
(whichever end we end up with) such that new single-ended algorithms can 
be trialed or deployed (and coincidentally provides a way for the CC 
algorithm to probe to see if the other side supports something 
compatible, without mandating it be part of a higher-level negotiation).

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

True - but the constraints on TCP are very different, forward delay is 
encouraged to maximize throughput, traffic is often primarily 
unidirectional (so the feedback path is uncontended and often close to 
loss-free especially where the bottleneck link is the local last-mile or 
Wifi), while for us we typically have saturated links in both directions 
while trying to keep delays low, and each packet of feedback takes away 
from payload.

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

This still may be so, since in many ways (see above) it's easier to 
feedback raw data and keep *all* decisions at the sender side. (Though a 
sender-side standard feedback packet may still need rules on how to 
operate in reverse-path contention/loss that will need to be added.)  
However, as several of the candidates mentioned, there are issues with 
reverse-path bandwidth use - and I don't think they've even really 
gotten much into two-way tests; all the graphs I see are for one-way.  
Two-way will complicate things - and it's a critical part of the use-cases.

A send-side setup with feedback from the receiver for each packet 
(generic or not!) will almost certainly require careful compression 
decisions (and feedback-rate decisions, perhaps semi-controlled by the 
sender - see above similar to the receive-side discussion).  For this 
reason alone, I'm not sure if RTCP-XR will work, even with modifications 
or additions - but I haven't looked much at RTCP-XR other than to note 
it has a LOT of stuff and isn't very thin.  But take that with a grain 
of salt.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [e-mail]!  Way too much spam