Subject: [ippm] One-Way Metric Applicability Statement

From: Victor Reijs <[email-masked]>
Date: Tue, 09 Jul 2002 12:15:56 +0100

Hello Henk,

A few remarks to the document:

Victor Reijs wrote:
> 
> Internet Draft                                    Henk Uijterwaal
> Document: draft-ietf-ippm-owmetric-as-00.txt      Merike Kaeo
> Expires: December 2002                            July 2002
> 
>                    One-Way Metric Applicability Statement
> 

> Uijterwaal et al.         Expires December 2001
> [Page 1]

Should this not be 'Expires December 2002'

> 3. Recommendations for one way delay and loss measurements.

> 
> [Question: Can we benefit from packet sampling BOF work here?
> Ideally,
> math to calculate that if an effect occurs with a rate of N Hz
> and we
> send traffic with M Hz, there is a probability >X that one packet
> will
> see this effect.]

Sorry I have no answers, but this info is indeed important. 
In general we need for every reported value an accuracy range (by
default). Although this is can problematic, e.g. if measuring the
ipdv, the two time stamps could be inaccurate looking at the
'atomic/synchronized time', but the ipdv calculated of these
values could be accurate enough (due to the strong correlation
between the two errors).

> When packets are sent larger than the minimum size required by
> the
> measurement device, the remainder of the packet should be padded
> with
> random bits in order to avoid compression being applied to any
> measurement packets.

Perhaps 'Packet content' is also worth a section. (which could
include the above section). I know of new interface types that
had some flaw depending on the packet content. And indeed
compression is another one.
I hope that tools have configurable 'packet content' by the way
(because of the mentioned reason).

> In the case of IPDV, there are 2 timestamps and initial
> errors
> can be huge.

Perhaps this sentence needs some explanation. I assume you mean
here that if the clock has been changed between the two
measurement packets, the ipdv result can/will be inaccurate. Do
you mean this circumstance?

> 
> How to report intermediate results?

Don't fully understand this question. I would say that reporting
intermediate values is a level higher (e.g. the publishing
software). But I think I misunderstand this statement.

> Lastly, make
> sure that
> the total test traffic volume sent or received by a machine is
> small
> compared to total link capacity, a number of 3% of the total
> capacity
> seems reasonable.

Is it in principle not 3% of the available bandwidth? Also when
the link is being used, I still don't want accessive load looking
from the available bandwidth standpoint.

> 4.3. Average/Sigma versus 2.5/median/97.5%
> 
> Since Average/Sigma for a one-way delay distribution is not well
> defined, and percentiles are,we should use the latter.

And for packet loss metric? What should we use?
Perhaps we need sections for each metric 'Reporting the
<metric>'.

Hope this is helpful.

All the best,

Victor
-- 
PGP public key:
http://www.heanet.ie/heanet/projects/nat_infrastruct/pubkey.html
H.323 GDS: <exit-zone>+00353 01101001
H.323 ViDiNet: <exit-zone>+61330060909 01101001
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm