[ippm] comments on draft-ietf-ippm-framework-compagg-04
"Loki Jorgenson" <ljorgenson@apparentnetworks.com> Tue, 07 August 2007 17:20 UTC
Return-path: <ippm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISjr-0004MD-5C; Tue, 07 Aug 2007 13:20:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IISjn-0004M4-ED for ippm@ietf.org; Tue, 07 Aug 2007 13:20:57 -0400
Received: from relay.jaalam.net ([209.139.228.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IISjl-0004cS-W8 for ippm@ietf.org; Tue, 07 Aug 2007 13:20:55 -0400
Received: from jsrvr8.jaalam.net ([172.16.128.105]) by relay.jaalam.net (SMSSMTP 4.1.0.19) with SMTP id M2007080710204905305 for <ippm@ietf.org>; Tue, 07 Aug 2007 10:20:49 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 07 Aug 2007 10:20:48 -0700
Message-ID: <F09324DCDD2F5D488EAC603D6B299DC703B4527E@jsrvr8.jaalam.net>
In-Reply-To: <E1IFBBb-0006DV-Me@megatron.ietf.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: comments on draft-ietf-ippm-framework-compagg-04
Thread-Index: AcfR+aF6KMNSCTIGToOvmZfSb+9n9gHGvQJQ
References: <E1IFBBb-0006DV-Me@megatron.ietf.org>
From: Loki Jorgenson <ljorgenson@apparentnetworks.com>
To: ippm@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc:
Subject: [ippm] comments on draft-ietf-ippm-framework-compagg-04
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Errors-To: ippm-bounces@ietf.org
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) 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 ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm
- [ippm] comments on draft-ietf-ippm-framework-comp… Loki Jorgenson
- comments on draft-morton-ippm-delay-var-as-03 [wa… Al Morton
- RE: comments on draft-morton-ippm-delay-var-as-03… Loki Jorgenson
- [Fwd: comments on draft-morton-ippm-delay-var-as-… Benoit Claise