Re: [rmcat] delay recovery phase

[Randell Jesup <[e-mail]>]

On 11/3/2014 5:04 AM, Stefan Holmer wrote:
> Sounds interesting.
>
> In 
> https://tools.ietf.org/html/draft-alvestrand-rmcat-congestion-02#page-10 
> we go into a HOLD state where the sender should keep its bitrate 
> constant while waiting for buffers to drain. We don't try to estimate 
> the time needed to drain the buffers, but instead look at the delay 
> change estimate m(i); if it's less than zero buffers are likely draining.

Right.  My point was that for large fast changes in available bandwidth 
(due to either link changes as we're talking about here, new 
non-adaptive VoIP flows, or brand-new hungry TCP flows (which due to RTT 
or the other limitations elsewhere don't eat the entire connection), 
it's good to estimate how far behind you've fallen while waiting to 
respond.  The other solution is purposely always overreact downwards 
(though this requires having an idea how much over we may be, which 
Google's algorithm doesn't use, but can be estimated by the slope of the 
delay increase and then confirmed by the slope of the delay decrease 
after lowering send bandwidth).

And per my previous comments, judicious frame drops at the sender can 
drain a queue very fast, though that has to be balanced against 
maintaining framerate for quality.  That's partially out-of-scope for 
RMCAT, but not entirely if it can feed the source not only an "available 
bandwidth" value, but also an "estimated overhang" value (delay in time 
and bits).    The control output of RMCAT to the source does *not* have 
to be a single integer.  Some sources (audio) may not be able to make 
(much) use of it.  Others might - video by dropping frames, audio by 
using comfort noise, both by changing/dropping FEC temporarily, etc.


-- 
Randell Jesup -- rjesup a t mozilla d o t com