[Fwd: comments on draft-morton-ippm-delay-var-as-03 [was: [ippm] comments on draft-ietf-ippm-framework-compagg-04]]

[Benoit Claise <[e-mail]>]

Loki,

Thanks for your comment.
See inline for one specific point.
We will try to address the other points in the next version of the draft.
> Al - some comments on draft-ietf-ippm-framework-compagg-04
>
> Alan Clark's comments from last week are very relevant - in particular
> w.r.t. appropriate statement of assumptions related to implicit models
> and methodologies.
>
> In addition (and somewhat redundantly since I had already written the
> notes):
>
> General:
>   o of course, choice of PDV and IPDV as relevant implementations seems
> valid - however, there are implicit assumptions that should be made more
> explicit.  E.g. the values for reference time embody particular choices
> related to methodology and model:
>           o PDV assumes minimum delay knowable and difference optimally
> significant (transmission distribution is not relevant)
>           o IPDV assumes, or is typical within the context of, periodic
> transmission (or some context wherein packet separation is significant)
> and that the regularity of the period represents an optimal reference
> (and propagation time is not specifically relevant)
>   
That's a good point.
This also implies that Poisson makes more sense with PDV.

Regards, Benoit.

> Of course these descriptions are intended to be considerably more
> generic but in doing so they look past the obvious implementations
> (which is part of the intention of this draft, yes?).  Some of the
> descriptions of RFC 3933 include references to other timing
> distributions (e.g. Poisson).  The choices of minimum and delta are
> specific and motivated (by application requirements).
>
>   o references to "optimizing de-jitter buffer" are a relevant example
> of application design references that motivate the choice of jitter
> definition - is that related to the (anticipated) mandate of PMOL/APM?
>
>   o There should be more discussion of the typical implementation
> requirements - there is only passing mention of:
>            o optional statistical approaches
>                    - holding and post-processing all data in a
> measurement interval
>                    - not holding (much) data and maintaining running
> measures
>                    - holding a sliding window of data and maintaining
> sliding measures
>            o memory requirements (based on each case above)
>            o implications for reference values (based on each case
> above)
>                    - e.g. D(min) as running value for whole set or
> absolute for windowed set
>            o issues and complication possible in various instances of
> each case
>                    - e.g. quantiles are not available as running measure
>          ** many of these issues may be adequately addressed by simply
> emphasizing the MAPDV2/G.1020 document.  There is some mention of these
> issues in Appendix 13.
>
>   o "quick variation" seems an unfortunate turn of phrase
>            o however, it has been defined as being on the order of
> inter-packet separation so that seems adequate
>            o an alternative might be "short timescale variation"
>
>    o in the definition of IPDV, why is there no consideration of the
> practical context wherein packet arrival times are known but not
> transmission times for the periodic case.  Is that to suggest that there
> is no meaningful implementation of IPDV without transmission times?
>           
>    o in Sec. 8.1 referring to Measurement Stream Characteristics, there
> should be some description of the impact of sampling methodology for the
> cases wherein not all the packet D(i) are sampled.  This should include
> some suggestion for methodology references.
>             o for example: 
> The implication of short-range dependency on delay variation measurement
> Qiong Li; Mills, D.L.
> Network Computing and Applications, 2003
> Volume , Issue , 16-18 April 2003 Page(s): 374 - 380
> 	o for example
> Fisher Information of Sampled Packets: an Application to Flow Size
> Estimation
> Bruno Ribeiro, University of Masachusetts at Amherst; Don Towsley,
> University of Masachusetts at Amherst; Tao Ye, Sprint Advanced
> Technology Laboratories; Jean Bolot, Sprint Advanced Technology
> Laboratories
>
>    o in Sec. 8.3 Test Duration, some references to stability of networks
> would be useful.  Although changes are possible on almost any time
> scale, there are some reasonable rules of thumb to be considered.
> Typical networks are stable on the order of minutes.  However there are
> also long timescale variations associated with daily cycles.
>            o for example
> On the Constancy of Internet Path Properties. 
> Yin Zhang, Nick Duffield, Vern Paxson, and Scott Shenker -- AT&T Labs
> Research, Florham Park NJ; AT&T Center for Internet Research at ICSI,
> Berkeley CA.
>
>    o in Sec. 8.5, there is reference to distinguishing long delays from
> loss - as mentioned elsewhere, a reasonable threshold should be applied.
> Naturally, discards should be accounted for distinct from loss.
>
>   o in Appendix 12, also include various forms of equipment and
> configuration dysfunction as a separate cause.  For example, consider
> re-transmission effects in WiFi or slow-path processing in a router that
> has been sub-optimally employed for edge filtering.
>
>   o in Appendix 13, consider including code fragments for the described
> method.  This may be a special case of temporal composition (associating
> sets of data segmented intervals from a single testing period).
>
> -- Loki 
>
> _______________________________________________
> ippm mailing list
> [e-mail] 
> https://www1.ietf.org/mailman/listinfo/ippm
>   


_______________________________________________
ippm mailing list
[e-mail] 
https://www1.ietf.org/mailman/listinfo/ippm