Re: [ippm] http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-01

[Donald McLachlan <[e-mail]>]

All,

Below are some comments on 
http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-01 which I  
previously provided by e-mail to Al Morton.

Don


-------- Original Message --------
Subject: 	Re: IETF Anaheim.
Date: 	Tue, 30 Mar 2010 11:51:08 -0400
From: 	Donald McLachlan <[e-mail]>
To: 	Al Morton <[e-mail]>



I've given
http://tools.ietf.org/html/draft-ietf-ippm-reporting-metrics-01 a
preliminary read.  I will re-read it later but here are some initial
comments.

Re: section 4.1.3.  For all sorts of reasons (listed in "PDV" RFC) I
find PDV a much more useful metric than IPDV, and any/all received
packets are then valid, unlike the IPDV if/when every second packet is
lost, no measurements pairs are valid.  Thus I wonder whether it isn't
better to remove IPDV from this doc and just mention PDV?

Re: section 4.2.<begin edit>  should/could it also report the mode (or modes if there are
multiple equal peaks.)  Should/could it
also report several PDF percentile values.<end edit>

Re: section 5. Raw vs. Restricted Capacity.  The document (vis-a-vis
data uniqueness) implies, but does not state, that results from TCP
tests report values closer to the Restricted Capacity capacity because
TCP only returns 1 copy of duplicate data to the application layer.
Whereas UDP tests (esp with checksums disabled) report values closer to
Raw Capacity.

Re: section 7.2. Re: temporal aggregation.  It might be worth noting to
avoid possible synchronisation with network events by randomising the
start times.  e.g. if one started 20 second tests once every 10 minutes
via cron, it could sync with other periodic "top of the minute" load and
bias the results.  Automated tests should start on pseudo-random
(Poisson-like?) start times.  Then the aggregate should more correctly
reflect reality.

All for now,
Don