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

[David Hayes <[e-mail]>]

Hi Grenville,

Thank you for your comments on the draft. Some notes inline.

Thanks and regards,

David

On Mon, 20 Oct 2014 15:07:46 +1100
grenville armitage <[e-mail]> wrote:

> David,
> 
> Had a quick glance, and draft-hayes-rmcat-sbd-00.txt looks like the
> start of an interesting piece of work.
> 
> In the spirit of kicking off discussion, a couple of editorial
> nits/suggestions...
> 
> In 2.1 and 3.1, you quote [Hayes-LCN14] as suggesting some parameter
> values "...that seem to work well over a wide range of practical
> Internet conditions."  The I-D would be more self-contained if you
> also summarised somewhere in the I-D itself what [Hayes-LCN14]
> considered to be "practical Internet conditions".
> 

The LCN paper tested two very different network conditions with
identical parameters. We are currently working on more expansive and
quantitative tests, which we hope to eventually publish in a journal.
The vagueness in the current comment reflects this and will be made
more concrete when we have more data to back it up.

> In 3. you introduce two variables, skewest and freqest. Adding an
> underscore and making them skew_est and freq_est would be visually
> clearer. (It took me a couple of reads to realise they weren't just
> typo'd words ;) )
> 
> 3.1.4. (heading) "Oscilation Estimate"  ->  "Oscillation Estimate"
> 
> 3.1.3  "...([RFC5481] and [ITU-Y1540] is used..."  ->  "...([RFC5481]
> and [ITU-Y1540]) is used..."
> 
> 3.2.1, First para uses "small", "moderate" numbers of flows fairly
> opaquely, then intimates that "large" == "hundreds".  Is the
> vagueness just the nature of a -00.txt I-D, or a constraint that
> applies to your flow grouping algorithm? (Put another way, can you
> provide implementers stronger guidance as to what sort of
> _in_efficiencies would be experienced if they anyway went ahead and
> used the algorithm in 3.2.1 across hundreds+ flows? I could also see
> that detail perhaps being out of scope, so just a suggestion.)

For hundreds of flows I expect the sorting required by the grouping
algorithm could become an issue, but it is beyond the
scope of a RMCAT document to discuss that (as you suggest). It is
mentioned because the basic SBD algorithm is generic, and can be
applied to more than just RTC-Web.

On the number of flows for RTC-Web,
draft-ietf-rtcweb-use-cases-and-requirements-14 requires RTC-Web
be capable of working with "several" flows and
draft-ietf-rmcat-eval-test-00 tests with up to 5 media flows. This
mechanism is more than sufficient for these numbers.

Does anyone on the list have any more information on the expected
numbers of flows?


> 
> 4.1. For implementers it may be helpful if -01.txt elaborated on time
> stamp resolution considerations. (The current text implies that
> typical RTP media flows use sub-millisecond timers whose resolution
> is 'less than one hundredth of a typical paths range of delays'.
> Would be useful to capture your thoughts on what happens when the
> paths are tens of ms, or the timers aren't "sufficiently"
> sub-millisecond.)
> 
> cheers,
> gja
> 
> David Hayes <[e-mail]> on Fri, 10 Oct 2014 17:37:10 +0200
> 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
> 
> 



-- 

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