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

[David Hayes <[e-mail]>]

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



-- 

-------------------------
David Hayes
[e-mail]
Department of Informatics
University of Oslo