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

[Randell Jesup]

On 8/8/2012 1:04 AM, Mo Zanaty (mzanaty) wrote:
> In the case of loss due to congestion (a full queue or AQM action), the loss itself seems like the right signal to process. Why wait to infer congestion from the subsequent delay pattern which can be speculative/unreliable rather than the loss itself?

I agree totally, one should always assume loss is some type of 
congestion (though very low levels of loss might be ignored).  This is 
an area where the current proposed algorithm can be improved.

> If the goal is to distinguish congestion from stochastic loss, that is a general problem that probably needs more thought than the RRTCC 3-sigma outlier filter, or Kalman filter (which is designed to filter stochastic jitter but not losses), or Randell's "fishy" filter. There should be ample research available on this topic from many years of TCP over wireless links.

Agreed.  The way I used it was to give a "bonus" reduction in bandwidth 
if the losses appeared 'fishy'.  Per the earlier emails, this would 
mostly happen on otherwise-mostly-idle access links or maybe during 
bursts of cross-traffic.

-- 
Randell Jesup
randell-ietf at jesup.org