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

[Mirja Kühlewind <[e-mail]>]

Hi David, hi all,

I've read your document and have a couple of questions (as an individual 
contributor):

1) You propose to use the OWD, to do all the calculation at the receiver and to 
signal the information to the sender. Did you also do some analysis how good 
your approach would be if you use RTT (because than the sender could also work 
independent of the receiver)?

2) You also talk about a receiver based approach. I'm not sure if this case is 
needed because that's the case where simply congestion control does its job. 
While if one sender has multiple flows it seems to be more reasonable for me to 
couple these.

3) Am I right to that you need an initial set-up time of 17.5 sec? Can you also 
explain a little further why you've chosen 350ms and N=50?

4) Can you also explain with which (network) effect you have skewness? Is this 
really an effect in real systems that gives you valuable information?

5) If you look at the variance (and use the max) you might want to apply some 
kind of filtering first e.g. to filter out single out liners (due to some 
processing delays).

6) Can you also explain a little more, why you also use the oscillation 
frequency and the value p_v=0.2? While the other metrics actually measures some 
kind of network behavior, e.g. delay variance is determined by the queue size, 
the oscillation size is determined by the congestion control behavior. I guess 
the flows have to use the same congestion control scheme...?

7) For packet loss you can also estimated the loss frequency. I would think if 
the congestion control operates loss-based that this would actually give you a 
pretty good estimate if flows share the same bottleneck. Or even easier if the 
loss of the flows always occur in the same RTT.

8) And one last question regarding the grouping: Do you always need to apply all 
three conditions? Why are those three needed?

Mirja



On 10.10.2014 17:37, David Hayes 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
>
>
>