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

[Stefan Holmer <[e-mail]>]

If you checkout the webrtc repository you'll find one trace under:
webrtc/resources/google-wifi-3mbps.rx. It contains packet arrival times in
nanoseconds (I think) when the sender sent at a constant rate of 3 mbps.

On Wed, Oct 22, 2014 at 5:20 PM, Simone Ferlin-Oliveira <[e-mail]>
wrote:

> Hi Stefan,
>
> Thanks for your comments.
>
> Would you have any traces of such WiFi cases you mention?
> We plan to run other tests with the algorithm. I have already an
> implementation and we are testing it with wired/3G/4G at the moment.
>
> Simone (co-author)
>
> On 22 October 2014 16:36, 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.
> >
> > 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.
> >
> > 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. :)
> >
> > It would be good to have the diff() operation defined somewhere. Is it
> the
> > diff between successive measurements, or the diff between the flows?
> >
> > /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
> >>
> >
>