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

[Simone Ferlin-Oliveira <[e-mail]>]

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