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

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

Hi David,

just again on the skewness point: Form my current understanding what you somehow 
want to measure with this is something like a standing queue..? Still the way 
you calculate the skewness seems very abstract to me. However, if it can be 
shown that this provides useful information, it definitely should be used. The 
question (for all the metrics that you propose) is how can you show that these 
are the right metrics. One approach is definitely to do more measurements in 
various scenario but could you also assess the risk of failures? Or (and this 
potentially is more a question for the cc congestion) how bad is if you group 
two flows together wrongly?

Mirja


On 21.10.2014 17:36, David Hayes wrote:
> Hi Mirja,
>
> Thank you for going through this and giving your comments and questions!
>
> I have answered your questions inline.
>
> Regards,
>
> David
>
> On Tue, 21 Oct 2014 11:22:09 +0200
> Mirja Kühlewind <[e-mail]> wrote:
>
>> 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?
>
> Not quite. Decisions can start to be made after T (nominally 350ms),
> though with far less accuracy, but increasingly more accurately as
> time progresses. This needs to be outlined in the draft.
>
>> Can you also explain a little further why you've chosen 350ms and
>> N=50?
>
> Roughly, T should to be long enough to capture the short term variance
> in the OWD, but not too long so as to be able to sample the low
> frequency oscillations of OWD on the bottleneck. T=350ms provided
> good results (though not necessarily optimal) on the two very different
> networks we tested it on in the LCN paper. However, the dynamics on the
> Internet can change. T is one the parameters sent in the initialisation
> message, so although we want to recommend a good "all round" value for
> it, it can be changed to suit specific network dynamics.
>
> The system will need to keep N samples of many of the statistics. With
> larger values of N, many of the parameters can be calculated more
> accurately (or less noisily), but at the expense of memory and
> sensitivity to changing network conditions. Also, if N is too small it
> is difficult to get a good freq_est for comparison. N=50 was found to be
> good "all round" value in our tests so far. It too is one of the
> parameters sent during initialisation, potentially allowing an
> application to set it according to its needs for network dynamic
> sensitivity.
>
>> 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?
>
> OWD skewness (in an abstract way) is a function of the load at the
> bottleneck and the traffic dynamics. When a queue becomes congested,
> the queue distribution becomes skewed toward the back of the queue (At
> extreme loads the dynamic changes again). It is important in the
> algorithm for a number of reasons:
> 	1. If there is no congestion along the path, all of the delay
> 	statistics are too noisy to be useful for grouping flows
> 	(there is no bottleneck!). Skewness is used to determine
> 	whether a flow is experiencing congestion -- or to put it
> 	another way that the statistics will be reliable for grouping
> 	flows.
>
> 	Other possible metrics could be:
> 	- magnitude of delay (but we do not know how long the queue is
> 	  at the bottleneck and what the OWD_min is)
> 	- loss (loss can be caused by other factors, and may be to rare)
>    	- ECN (this will be good in the future, but is not reliable
>    	  now - the bottleneck may not be ECN enabled)
> 	- etc
>
> 	Skewness was found to be a reliable congestion indicator that
> 	did not require any prior knowledge of queuing along the path.
>
>
> 	2. Two similar bottlenecks with similar traffic but different
> 	loads can exhibit a similar variance, but will have a different
> 	skewness. This helps to distinguish this case.
>
>>
>> 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).
>
> This is a good point, especially the further from the network interface
> measurements are made. Min would be a better option in terms of noise,
> but (in theory) Min is load ambiguous (see 2. above) at similar loads
> to where skewness is (there is a discussion in the LCN paper concerning
> this). A simple filter, ie second highest OWD, may be enough.
>
>>
>> 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...?
>>
>
> The low frequency oscillation of OWDs at a bottleneck depends on many
> things including: the queue size, other traffic at the bottleneck (flows
> starting, flows leaving, etc), and the combined behaviour of all of the
> traffic's congestion controllers. In our experiments (and general
> observations of OWD graphs), the low frequency oscillation of OWDs is
> discernibly different between different bottlenecks. This metric tries
> to capture that difference with an efficient estimate that can be
> easily compared.
>
> We use the short term variation in the signal, p_v, as a guide for
> de-noising. The skewness congestion test 4)1. above helps to ensure
> that we are measuring a signal and not just noise.
>
>
>> 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.
>
> When the the packet loss rate is high, this becomes a reliable measure
> and is used by the algorithm. However, when the packet loss rate is low
> the signal is too rare to be useful.
>
> Within an RTT (we are looking at OWD) not all flows traversing a
> bottleneck will necessarily experience packet loss. Also, not  all flows
> will necessarily have the same RTT, having different paths to their
> destinations.
>
> Hassayoun, Iyengar, and Ros in their paper "Dynamic window coupling for
> multipath congestion control", look at a similar idea for MPTCP. The
> SBD is intertwined with the congestion control, and although sufficient
> for their purpose, has different objectives and I don't think can be
> applied to achieve a reliable grouping in the RMCAT scenario.
>
>>
>> 8) And one last question regarding the grouping: Do you always need
>> to apply all three conditions? Why are those three needed?
>>
>
> All the statistics are noisy making fine grain grouping based
> on one statistic difficult. Using a number of statistics summarising
> different aspects of the signal allows us to more coarsely group based
> on each statistic (allowing for the noise) but still obtain a fine
> enough grouping.
>
> An aside on the noise: The noise is caused by the same things that we
> are looking for in the "signal" from the bottleneck: queueing, packet
> loss, etc. The bottleneck "signal" is generally stronger than the noise
> from the other devices along the path, but still the signal and noise
> have similar characteristics. This similarity makes filtering difficult.
>
>> 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
>>>
>>>
>>>
>
>
>

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