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

[Stefan Holmer]

On Wed, Aug 8, 2012 at 8:06 AM, Mo Zanaty (mzanaty) <mzanaty at cisco.com>wrote:

> Hi Randell,
>
> 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)?
>
> Thanks,
> Mo
>
> -----Original Message-----
> From: rtp-congestion-bounces at alvestrand.no [mailto:
> rtp-congestion-bounces at alvestrand.no] On Behalf Of Randell Jesup
> Sent: Wednesday, August 08, 2012 1:46 AM
> To: rtp-congestion at alvestrand.no
> Subject: Re: [R-C] RRTCC issues: loss, decrease rate
>
> 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.
>

Agreed.


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

Yes, and distinguishing between congestion and stochastic loss is a
non-trivial problem. There are different approaches and ways to model it,
but in the end I don't think there's a way to make it work reliably in all
scenarios. But it might be possible to build something which improves
things in some scenarios while not making a difference in other.


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

You could even go one step further and make the "bonus" reduction depending
on how certain you are that the loss was fishy or not.


>
> --
> Randell Jesup
> randell-ietf at jesup.org
>
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120808/17eca550/attachment.html>