Re: [rmcat] Fw: New Version Notification for draft-hayes-rmcat-sbd-00.txt

[Stefan Holmer <[e-mail]>]

On Wed, Oct 22, 2014 at 7:12 PM, David hayes <[e-mail]> wrote:

> Hi Stefan,
>
> Thanks for your comments! They are very much appreciated.
>
> I have added some responses inline.
>
> Kind regards,
>
> David
>
> On Wed, 22 Oct 2014 16:36:32 +0200
> Stefan Holmer <[e-mail]> wrote:
>
> > Nice draft! I have a few comments:
> >
> > You're mentioning that skewness would require all delay measurements
> > to be stored, and therefore you're computing some different metric
> > which is related to skew. I wonder if it shouldn't be possible to
> > more accurately estimate the skew from a histogram instead? That way
> > you at least won't need to store all delay measurements. Might not be
> > worth the trouble if your metric works well.
>
> The 3rd central moment is difficult to calculate for a
> number of reasons. Yes you need the mean to start with, which would
> require storing all the delay measurements so that when you have the
> mean, you can compare them with it. The other problem is, that being a
> cubic function, it is very sensitive to outliers and therefore requires
> a high number of samples for an accurate result. Skew_est is efficient
> to calculate and less sensitive to outliers (the test is only above and
> below the mean), meaning we don't need quite as many samples.
>
>
> Using a histogram was one of the ideas I looked at. In the end I didn't
> go with it for the following reasons. To do this we need to know what a
> good bin size is, and probably need to use the same bin size for each
> flow (a common base for comparing). If we know the min/max network
> delays of every flow we can work out a good bin size, but
> generally we don't know this a priori -- and it could also change with
> new flows or changes in the network paths. We could use the previous
> NT's PDV as a guide for this, but the flows we are comparing with are
> probably going to different receivers. In this case we would need to
> communicate the information between sender and receivers.
>

Thanks for the background, I haven't researched this much, so I trust your
judgment. :)


>
> >
> > As mentioned by Mirja, it seems a bit error prone to use the max of
> > the OWD (also, shouldn't it be max_T(OWD)?) when computing the PDV.
> >
>
> max_T would be more consistent with our notation. Thanks.
>
> We used max_T instead of min_T because of their relationship to
> skew_est in a MM1K queueing model(LCN paper). However, the difference
> between MM1K and real networks and the problem of coping with outliers
> and may make min_T a better choice. In our tests we did not have any
> significant problems, but we would not have had processing delays Mirja
> pointed to.
>

I see. As you say, some way of getting rid of outliers is probably a good
idea.


>
> > Somewhat related to this, I wonder if you have any plans to test this
> > algorithm on WiFi? I have seen many cases of WiFi with a lot of
> > contention and/or interference, where the delay gets skewed not
> > because lack of bandwidth, but because of lower layer retransmissions
> > or because the access point was busy serving someone else for a
> > moment. I wonder if that can cause you to incorrectly detect shared
> > bottlenecks, where in reality there was only a shared WiFi... Now
> > that I think of it, the WiFi effect should result in positive
> > skewness, while you're looking for negative skewness, so you may be
> > ok here. :)
> >
> Simone has answered here. Thanks!
>
>
> > It would be good to have the diff() operation defined somewhere. Is
> > it the diff between successive measurements, or the diff between the
> > flows?
> >
>
> Can you elaborate on this suggestion a bit more please. Thanks!
>

It just wasn't immediately obvious to me if diff() in for instance
"diff(freqest)
< p_f" took the difference over freqest over time or the difference over
pairs of flows at one time instant. I assume it's the latter though?


>
> > /Stefan
> >
> >
> > On Fri, Oct 10, 2014 at 5:37 PM, David Hayes <[e-mail]>
> > wrote:
> >
> > > Dear All,
> > >
> > > We have just submitted of our initial shared bottleneck detection
> > > draft and will value your comments and suggestions.
> > >
> > > Regards,
> > >
> > > David
> > >
> > > Begin forwarded message:
> > >
> > > Date: Fri, 10 Oct 2014 08:17:57 -0700
> > > From: <[e-mail]>
> > > To: Michael Welzl <[e-mail]>, David Hayes
> > > <[e-mail]>, Michael Welzl <[e-mail]>, Simone
> > > Ferlin <[e-mail]>, Simone Ferlin <[e-mail]>, David
> > > Hayes <[e-mail]> Subject: New Version Notification for
> > > draft-hayes-rmcat-sbd-00.txt
> > >
> > >
> > >
> > > A new version of I-D, draft-hayes-rmcat-sbd-00.txt
> > > has been successfully submitted by David Hayes and posted to the
> > > IETF repository.
> > >
> > > Name:           draft-hayes-rmcat-sbd
> > > Revision:       00
> > > Title:          Shared Bottleneck Detection for Coupled
> > > Congestion Control for RTP Media. Document date:        2014-10-10
> > > Group:          Individual Submission
> > > Pages:          12
> > > URL:
> > > http://www.ietf.org/internet-drafts/draft-hayes-rmcat-sbd-00.txt
> > > Status:
> > > https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/
> > > Htmlized:       http://tools.ietf.org/html/draft-hayes-rmcat-sbd-00
> > >
> > >
> > > Abstract:
> > >    This document describes a mechanism to detect whether end-to-end
> > > data flows share a common bottleneck.  It relies on summary
> > > statistics that are calculated by a data receiver based on
> > > continuous measurements and regularly fed to a grouping algorithm
> > > that runs wherever the knowledge is needed.  This mechanism
> > > complements the coupled congestion control mechanism in
> > > draft-welzl-rmcat-coupled-cc.
> > >
> > >
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> > > tools.ietf.org.
> > >
> > > The IETF Secretariat
> > >
> > >
> > >
> > > --
> > >
> > > -------------------------
> > > David Hayes
> > > [e-mail]
> > > Department of Informatics
> > > University of Oslo
> > >
> > >
>
>
>
> --
>
> +-------------------------------+
> | David A. Hayes                |
> | [e-mail]          |
> +-------------------------------+
>