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

[David hayes <[e-mail]>]

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.

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

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

> /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]		|
+-------------------------------+