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

[Varun Singh <[e-mail]>]

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.

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/