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

From: grenville armitage <[email-masked]>
Date: Mon, 20 Oct 2014 15:07:46 +1100

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

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

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 <[email-masked]> 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: <[email-masked]>
> To: Michael Welzl <[email-masked]>, David Hayes
> <[email-masked]>, Michael Welzl <[email-masked]>, Simone Ferlin
> <[email-masked]>, Simone Ferlin <[email-masked]>, David Hayes
> <[email-masked]> 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
> [email-masked]
> Department of Informatics
> University of Oslo

---

From: Simone Ferlin-Oliveira <[email-masked]>
Date: Tue, 21 Oct 2014 14:03:27 +0200

Grenville,

On behalf of the authors, I am answering to your comment about
timestamps (4.1) of the draft:
We actually have in mind to add more on timestamp precision and also
mention it to different places the algorithm can be implemented.
However, the work I am doing for that at the moment is going to be
included in the next version of the draft.

Thanks,
Simone

On 20 October 2014 06:07, grenville armitage <[email-masked]> wrote:
> 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".
>
> 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.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.)
>
> 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
>

---

From: David Hayes <[email-masked]>
Date: Tue, 21 Oct 2014 14:15:14 +0200

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 <[email-masked]> wrote:

> 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.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
> 
> > <[email-masked]>, Michael Welzl <[email-masked]>, Simone
> > Ferlin <[email-masked]>, Simone Ferlin <[email-masked]>, David
> > Hayes <[email-masked]> Subject: New Version Notification for
> > Status:
> > https://datatracker.ietf.org/doc/draft-hayes-rmcat-sbd/
> >   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.
> >
> >
> >
> >

--