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

[Stefan Holmer <[e-mail]>]

On Thu, Oct 23, 2014 at 2:26 PM, Varun Singh <[e-mail]> wrote:

> On Thu, Oct 23, 2014 at 12:36 PM, Stefan Holmer <[e-mail]> wrote:
> > We don't have plans for it right now, but I can imagine that it might
> happen
> > sooner or later. I do think this draft could be useful in for instance
> mesh
> > conferences where your uplink bottleneck is on your access link. The main
> > question is if it's reliable enough that the benefits clearly are greater
> > than the downsides of incorrect classification.
> >
>
> In a mesh the endpoint already knows that the outbound streams belong
> to a group and the main thing to figure out which ones share a common
> bottleneck, if not all of them.
>

What do you mean with "belong to a group"? What I mean could be useful is
to determine if the bottleneck is shared (e.g., the access link is the
bottleneck) and then use some sort of
coupled cc.


>
> Another possible simplification is that the flows are carrying the
> same content, but may be at different rates (if each has an
> independent congestion controller).
>
> >
> > On Wed, Oct 22, 2014 at 7:44 PM, Mirja Kühlewind
> > <[e-mail]> wrote:
> >>
> >> Hi Stefan,
> >>
> >> asking this because I'm personally curious but also as rmcat chair:
> >>
> >> Are you planning to implement some kind of coupled congestion control in
> >> your system?
> >>
> >> Mirja
> >>
> >>
> >>
> >> On 22.10.2014 16:36, Stefan Holmer 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
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> ------------------------------------------
> >> Dipl.-Ing. Mirja Kühlewind
> >> Communication Systems Group
> >> Institute TIK, ETH Zürich
> >> Gloriastrasse 35, 8092 Zürich, Switzerland
> >>
> >> Room ETZ G93
> >> phone: [phone]
> >> email: [e-mail]
> >> ------------------------------------------
> >
> >
>
>
>
> --
> http://www.netlab.tkk.fi/~varun/
>