A One-Way Delay Metric for IP Performance Metrics (IPPM)
Extracted elements (28)
Any 'padding' portion of test packets should be filled with randomized bits to prevent compression techniques along the path from artificially lowering the measured delay.
One-way delay measurement is preferred over round-trip delay because Internet paths are often asymmetric (different forward and reverse routes), asymmetric queuing can produce radically different performance even on symmetric paths, and application performance often depends primarily on one direction of communication.
Poisson sampling is used for the stream definition to avoid self-synchronization effects and to capture a statistically unbiased sample; the Poisson process schedules measurement, not actual packet arrival at Dst.
The 95% confidence interval was chosen for calibration error because some confidence level is needed to remove outliers in physical measurement, a specific level allows comparison between independent implementations, and 95% was loose enough to exclude outliers even in prototype user-level implementations.
Erratum EID 398 (status 'Held for Document Update') for RFC 2679 was incorporated into this document in Section 5.1, clarifying the computation of percentiles when the sample contains an even number of values.
If a packet is duplicated along the path so that multiple non-corrupt copies arrive at the destination, the packet is counted as received and the first copy to arrive determines the one-way delay. If a fragmented packet is not reassembled, it is deemed lost.
Post-processing to enforce a constant waiting time threshold on stored singletons of one-way delay is compliant with this specification and may allow results to serve more than one reporting audience, as confirmed by RFC 6808 testing.
Calibration results SHOULD include removal of systematic error from measured values, reporting of calibration error e (such that true value is reported value ± e with 95% confidence), and reporting conditions under which finite-delay packets are reported as lost due to resource exhaustion.
Measurement methodologies SHOULD include appropriate techniques to reduce the probability that measurement traffic can be distinguished from 'normal' traffic, preventing routers from giving it different priority treatment.
Measurement parameters MUST be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure, to avoid skewing results or causing congestion and denial of service.
The calibration and context for the underlying singletons MUST be reported along with a Type-P-One-way-Delay-Poisson-Stream sample.
The calibration and context in which the metric is measured MUST be carefully considered and SHOULD always be reported along with metric results.
The exact Type-P used to make the measurements MUST be accurately reported, as metric values may depend on protocol, port number, size, DS Field, ECN, or other packet distinctions.
The path traversed by the packet SHOULD be reported if possible, though in practice it is often impractical to know the precise path; partial information such as the initial link is still valuable context.
The threshold (or methodology to distinguish) between a large finite delay and loss MUST be reported.
Active measurement techniques reduce exposure of sensitive user information compared to passive observation; passive observation of user traffic raises significant privacy issues. Measurement results or systems should be protected against access for reconnaissance purposes in support of subsequent system attacks.
Calibration error 'e' is defined such that the reported value is within (true value - e) to (true value + e) at least 95% of the time; the total calibration error includes clock-related uncertainty plus the largest absolute deviation at the 2.5th or 97.5th percentile of host error measurements.
Four clock uncertainty concepts are defined: synchronization (extent two clocks agree on the time), accuracy (extent a clock agrees with UTC), resolution (smallest unit by which a clock is updated), and skew (change of accuracy or synchronization over time).
Metric parameters for Type-P-One-way-Delay are: Src (IP address of source host), Dst (IP address of destination host), T (a time), and Tmax (a loss threshold waiting time).
Total clock-related measurement uncertainty is bounded by Esynch(t) + Rsource + Rdest, where Esynch(t) is the upper bound on synchronization uncertainty and Rsource/Rdest are the clock resolutions of source and destination hosts.
Type-P-One-way-Delay-Inverse-Percentile (deprecated in this document due to lack of use) is the fraction of dT values in a stream less than or equal to a given time duration threshold.
Type-P-One-way-Delay is defined as the time dT such that Src sent the first bit of a Type-P packet at wire time T and Dst received the last bit at wire time T+dT. If the packet does not arrive within the loss threshold Tmax, the value is undefined (informally, infinite).
Type-P-One-way-Delay-Median is the median of all dT values in a Poisson stream, treating undefined values as infinitely large; when the sample has an even number of values, the mean of the two central values is used.
Type-P-One-way-Delay-Minimum is the minimum dT value in a Poisson stream, treating undefined values as infinitely large; it is undefined if the sample is empty or all values are undefined.
Type-P-One-way-Delay-Percentile is the Xth percentile of all dT values in a Poisson stream, treating undefined values as infinitely large. The statistic is itself undefined if the sample is empty.
Type-P-One-way-Delay-Poisson-Stream is a sample metric defined by parameters Src, Dst, T0, Tf, Tmax, and lambda (rate in reciprocal seconds). It consists of a sequence of <time, delay> pairs obtained by sending test packets at times drawn from a Poisson process with average rate lambda between T0 and Tf.
Wire time vs. host time uncertainty is bounded by Hsource + Hdest, representing the upper bounds on uncertainty in the difference between wire time and host time on the Src and Dst hosts respectively.
Two security threats are identified: harm caused by measurements (active packet injection that could cause congestion or denial of service if not carefully parameterized) and harm to measurements (routers prioritizing measurement traffic differently, or attackers injecting fake measurement packets to corrupt results). Authentication techniques such as digital signatures may guard against injected traffic attacks.