One Way Delay
This section contains the definition of the One Way Delay (OWD), it's accuracy,
some recommnedations about the sampling and the statistics
which should be retrieved from the samples.
A Singleton Definition for One-way Delay
The definition below is the one from the IETF IPPM RFC 2679 with
some slight changes to highligths our needs (introduction of ToS and version field) .
Metric Parameters
- Src, the IP address of a host
- Dst, the IP address of a host
- T, a time
- S, a ToS value
- V, the IP version field
- L, the packet lenght in bits
Metric Units
The value of a One-way-Delay is either a real number, or an undefined (informally, infinite)
number of seconds.
Definition
- For a real number dT, >>the *One-way-Delay* from Src to Dst at T for a given S, V and L, is dT<< means that Src sent
the first bit of a packet to Dst at wire-time* T and that Dst received the last bit of that packet at wire-time T+dT.
- >>The *One-way-Delay* from Src to Dst at T for a given S, V and L, is undefined (informally, infinite)<< means that
Src sent the first bit of a packet to Dst at wire-time T and that Dst did not receive that packet.
Accuracy
The expected accuracy of this metric is lower than one ms inside a domain.
An very interresting point is which accuracy could be expected, when presenting a "e2e" measurement as being the sum
of several mesurements. ("e2e" means either end-to-end or edge-to-edge across several networks)
Methodologies
Generally, the methodology would proceed as follows:
- Arrange that Src and Dst are synchronized; that is, that they have clocks that are very closely synchronized with
each other and each fairly close to the actual time.
- At the Src host, select Src and Dst IP addresses, Type of Service and IP version, and form a test packet of with these parameters. Any
'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized
bits to avoid a situation in which the measured delay is lower than it would otherwise be due to compression techniques
along the path.
- At the Dst host, arrange to receive the packet.
- At the Src host, place a timestamp in the prepared packet, and send it towards Dst.
- If the packet arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt
of the packet. By subtracting the two timestamps, an estimate of one-way delay can be computed. Error analysis of a
given implementation of the method must take into account the closeness of synchronization between Src and Dst.
If the delay between Src's timestamp and the actual sending of the packet is known, then the estimate could be adjusted
by subtracting this amount; uncertainty in this value must be taken into account in error analysis. Similarly, if the
delay between the actual receipt of the packet and Dst's timestamp is known, then the estimate could be adjusted by
subtracting this amount; uncertainty in this value must be taken into account in error analysis.
- If the packet fails to arrive within a reasonable period of time, the one-way delay is taken to be undefined
(informally, infinite).
Sample
This section will present the recommendation on how to sample the packets to measure the OWD.
The challenge here is to find out how the measurements could be significant. How many packets have to be sent to give
meaningfull information without impacting the line? How log should be these test? Which "traffic pattern" should be used?
(poisson distribution, predefined pattern, else)
Statistics
This section will present the statistics which have to be retrieve from the samples.
Which statistics are should be presented to which user? (average, SDR, median, percentiles?) How can the statistics
be added according to the distribution used? (statistics related question)
Performance mointoring main page.
Contact: Performance monitoring mailing list or
Nicolas Simar