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

[grenville armitage <[e-mail]>]

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