[R-C] RRTCC issues: loss, decrease rate

[Randell Jesup]

On 8/8/2012 2:06 AM, Mo Zanaty (mzanaty) wrote:
> Just to make sure I understand your "bonus" reduction, it is because the "fishy" pattern confirms a congestion loss rather than a possibly stochastic loss, right? Or is there another reason to apply the bonus that I missed? Like some sort of mild congestion vs. severe congestion inference (that can't be obtained by the loss signal itself alone)?

Mostly it was just stronger confirmation of congestion, and it seemed to 
work well.  It increased the chance that in the first adjustment after 
congestion is noticed we'd be below the available bandwidth and the 
queues would start to drain (and drain faster!) - but the downside is 
that if the loss isn't congestion, you would impair quality more, which 
is why it was limited to cases where I was pretty sure.


This brings up a related point - reaction speed.  I've proposed here 
using the slope output of the filter to adjust the amount of bandwidth 
reduction.  It's a fairly simple argument:

* The slope of delay increase is directly proportional to how fast the 
queue is growing.
* The rate the queue grows is directly proportional to how far 
over-bandwidth the bottleneck is
* You want to reduce bandwidth far enough to cause the queues to start 
to drain.

Note that in (3), it's really the combination of your reduction and the 
reduction of any other streams sharing the bottleneck.

Once again, this argument is strongest when there are few streams at the 
bottleneck.  In the single stream case, if you have correctly determined 
the slope, if you reduce bandwidth by an amount directly proportional to 
the slope, then you will (in theory!) exactly hit the link bandwidth.  
You'd want to slightly overshoot on purpose to ensure draining of the 
queue buildup.

As the number of competing streams increase, you're more likely to 
over-react, in that you're reading the bottleneck over-use amount, but 
you're only responsible for one of the flows.  So you have to be careful...

On the other hand, you want to get the bottleneck below congestion as 
fast as possible to avoid further delay buildup, and you want to 
overshoot slightly to ensure it drains (especially if another flow is 
still increasing (TCP sawtooth)).

So, instead of trying to hit the target in a single reduction, you can 
instead reduce sending rate by a fraction of apparent over-bandwidth 
amount (with some minimum reduction amount or percentage).  This means 
in the single-flow case, it will take several RTT at minimum to get 
below the link rate, but the delay increase rate will continually slow.  
With this slower reaction pace, you want to also stop reacting more 
slowly, to ensure you get into the queues-draining point, and drain them 
fast enough to make a difference.  You can do this by a number of 
methods. When the filter confirms the draining is occurring, you'll want 
to wait to increase bandwidth until the queues are stable and hopefully 
drained (the current algorithm includes this).

This has the advantage of reacting faster in cases of more severe 
congestion or larger over-link-bandwidth cases.  Tuning the reaction 
rate for sharing the link with other RRTCC flows, and to share 
reasonably with TCP flows would be the subject of tests; there are other 
related values to tune it, such as for how long it avoids switching 
direction (decrease->increase), how it reacts during startup, how RTT 
and jitter in delay signals feed in (more jitter may imply more 
competing streams, but not always).

You *might* be able to infer the number of competing streams (or some 
measure of competition) by the slope change after a reduction. In the 
single-flow case, it may be a fairly strong signal that it's 
single-flow, and you might want to include memory of that for a period 
and adjust the reaction rate to be faster.

One reason single-flows are so interesting is that access-link 
congestion is a very common case and very important case for connection 
quality for the user, if not the worrying case (from congestion-collapse 
or fairness perspectives).

-- 
Randell Jesup
randell-ietf at jesup.org