RFC 3432

Network performance measurement with periodic streams

📅 published December 2002, from ietf

RFC 3432: Network performance measurement with periodic streams 🎀

Okay bestie, here's the basic tea before we dive in 💅 This is RFC 3432, a Standards Track doc from November 2002, written by V. Raisanen (Nokia), G. Grotefeld (Motorola), and A. Morton (AT&T Labs). It came out of the Network Working Group. The header doesn't list any Obsoletes or Updates lines, so it isn't replacing or updating anything else 🦋

Status of This Memo ✨

So this doc is an Internet standards track protocol spec for the Internet community, and it's basically asking for discussion and suggestions to make it better 🫶 If you want to know where it sits in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1). Also, distribution is unlimited, so share away 💖

Copyright Notice 🌸

Abstract 🦋

Okay, the big idea: this memo describes a periodic sampling method plus the metrics you use to check how well IP networks are performing 📡 It starts by explaining why periodic sampling is worth having as an alternative to the Poisson sampling from RFC 2330. The perks are that it works for both active and passive measurements, it can simulate constant bit rate (CBR) traffic (like multimedia calls, or near-CBR stuff like voice activity detection), and it makes a bunch of analysis way simpler 🧚 The method dodges predictability by requiring random start times and finite-length tests. After that, it covers the sampling method, the sample metric parameters, and how measurements and errors work. Last but not least, it wraps up with extra info on periodic measurements, including security considerations 🔐

Table of Contents 🎀

1.  Conventions used in this document...........................  2
2.  Introduction................................................  3
    2.1 Motivation..............................................  3
3.  Periodic Sampling Methodology...............................  4
4.  Sample metrics for periodic streams.........................  5
    4.1 Metric name.............................................  5
    4.2 Metric parameters.......................................  5
    4.3 High level description of the procedure to collect a
        sample..................................................  7
    4.4 Discussion..............................................  8
    4.5 Additional Methodology Aspects..........................  9
    4.6 Errors and uncertainties................................  9
    4.7 Reporting............................................... 13
5.  Additional discussion on periodic sampling.................. 14
    5.1 Measurement applications................................ 15
    5.2 Statistics calculable from one sample................... 18
    5.3 Statistics calculable from multiple samples............. 18
    5.4 Background conditions................................... 19
    5.5 Considerations related to delay......................... 19
6.  Security Considerations..................................... 19
    6.1 Denial of Service Attacks............................... 19
    6.2 User data confidentiality............................... 20
    6.3 Interference with the metric............................ 20
7.  IANA Considerations......................................... 20
8.  Normative References........................................ 20
9.  Informative References...................................... 21
10. Acknowledgments............................................. 21
11. Author's Addresses.......................................... 22
12. Full Copyright Statement.................................... 23

1. Conventions used in this document 💅

Here's where the capital-letter key words come in. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way BCP 14, RFC 2119 [2] describes 🫶 Now, RFC 2119 was written with protocols in mind, but these words get used here for similar reasons. The point is making sure measurement results from two different implementations are comparable, and calling out spots where an implementation could mess with the network 👀

2. Introduction 🌈

This memo covers a sampling method and performance metrics that matter for certain IP network applications ✨ The original reason for all this was Quality of Service for interactive periodic streams, like multimedia conferencing over IP. But periodic sampling and measurement is useful beyond that. Interactive multimedia traffic is used as an example below, just to make the idea click 🎀

Sending equally sized packets (or mostly same-size packets) through a network at regular intervals simulates a constant bit-rate (CBR) stream, or a nearly CBR multimedia bit stream 🦋 From here on, these packets are called periodic streams. "Mostly same-size packets" shows up in apps with multiple coding methods, like digitally coded comfort noise during silence gaps in speech 🌸

The next sections lay out a sampling methodology and metrics for periodic streams. The measurement results can feed into derivative metrics like average and maximum delays 📊 The whole point is to formalize periodic stream measurements so independent implementations get comparable results 💖

2.1 Motivation 🧚

As the IPPM framework RFC 2330 [3] points out, a sample metric using regularly spaced singleton tests has some limits when you look at it from a general measurement point of view: only part of the network performance spectrum gets sampled 👀 Still, some applications also sample that limited spectrum, and their performance can be critically important to them 🔥

Periodic sampling is useful for these reasons:

It is applicable to passive measurement, as well as active measurement.
An active measurement can be configured to match the characteristics of media flows, and simplifies the estimation of application performance.
Measurements of many network impairments (e.g., delay variation, consecutive loss, reordering) are sensitive to the sampling frequency. When the impairments themselves are time-varying (and the variations are somewhat rare, yet important), a constant sampling frequency simplifies analysis.
Frequency Domain analysis is simplified when the samples are equally spaced.

Simulating CBR flows with periodic streams encourages dense sampling of network performance, since typical multimedia flows have 10 to 100 packets in each second 🍓 Dense sampling lets you characterize network phenomena with short duration. Main character energy 😭

3. Periodic Sampling Methodology 💜

The Framework RFC [3] flags a couple of potential problems with periodic sampling 👀

The performance sampled may be synchronized with some other periodic behavior, or the samples may be anticipated and the results manipulated. Unpredictable sampling is preferred.
Active measurements can cause congestion, and periodic sampling might drive congestion-aware senders into a synchronized state, producing atypical results.

Poisson sampling gives you an unbiased sample for the various IP performance metrics, yet there are situations where alternative sampling methods are advantageous (as discussed under Motivation) 🌸

So we can prescribe periodic sampling methods that tackle the problems above ✨ Predictability and some forms of synchronization can be mitigated with random start times and limited stream duration over a test interval 🔐 The periodic sampling parameters produce bias, and smart selection can produce a known bias of interest 🎯 The total traffic generated by this or any sampling method should be limited so it doesn't cause adverse effects on non-test traffic. Packet size, packet rate, and sample duration and frequency should all be considered 🫶

The configuration parameters of periodic sampling are:

T, the beginning of a time interval where a periodic sample is desired.
dT, the duration of the interval for allowed sample start times.
T0, a time that MUST be selected at random from the interval [T, T+dT] to start generating packets and taking measurements.
Tf, a time, greater than T0, for stopping generation of packets for a sample (Tf may be relative to T0 if desired).
incT, the nominal duration of inter-packet interval, first bit to first bit.

T0 may be drawn from a uniform distribution, or T0 = T + Unif(0,dT). Other distributions may also be appropriate. Start times in successive time intervals MUST use an independent value drawn from the distribution. In passive measurement, the arrival of user media flows may have sufficient randomness, or a randomized start time of the measurement during a flow may be needed to meet this requirement 🎲

When you want a mix of packet sizes, passive measurements usually have the sequence and statistics of sizes already in actual use. Active measurements would need to reproduce the intended distribution of sizes 📦

4. Sample metrics for periodic streams 🍓

The sample metric here is similar to the sample metric Type-P-One-way-Delay-Poisson-Stream from RFC 2679 [4] 💖 Singletons defined in [3] and [4] apply here too ✨

4.1 Metric name 🦋

Type-P-One-way-Delay-Periodic-Stream

4.2 Metric parameters 🌈

4.2.1 Global metric parameters 🎀

These parameters apply in the following sub-sections (4.2.2, 4.2.3, and 4.2.4).

Parameters that each Singleton usually includes:

Src, the IP address of a host
Dst, the IP address of a host
IPV, the IP version (IPv4/IPv6) used in the measurement
dTloss, a time interval, the maximum waiting time for a packet before declaring it lost.
packet size p(j), the desired number of bytes in the Type-P packet, where j is the size index.

Optional parameters:

PktType, any additional qualifiers (transport address)
Tcons, a time interval for consolidating parameters collected at the measurement points.

While a number of applications will use one packet size (j = 1), other applications may use packets of different sizes (j > 1). Especially in cases of congestion, it may be useful to use packets smaller than the maximum or predominant size of packets in the periodic stream 📉

A topology where Src and Dst are separate from the measurement points is assumed 🗺️

4.2.2 Parameters collected at the measurement point MP(Src) 💜

Parameters that each Singleton usually includes:

Tstamp(Src)[i], for each packet [i], the time of the packet as measured at MP(Src)

Additional parameters:

PktID(Src) [i], for each packet [i], a unique identification or sequence number.
PktSi(Src) [i], for each packet [i], the actual packet size.

Some applications may use packets of different sizes, either because of application requirements or in response to IP performance experienced 🌸

4.2.3 Parameters collected at the measurement point MP(Dst) ✨

Okay bestie, now we're on the receiving side 🎀 At MP(Dst), these are the things we collect:

Tstamp(Dst)[i], for each packet [i], the time of the packet as measured at MP(Dst) 🕐
PktID(Dst)[i], for each packet [i], a unique identification or sequence number 🪪
PktSi(Dst)[i], for each packet [i], the actual packet size 📦

Optional parameters 💅

dTstop, a time interval, used to add to time Tf to determine when to stop collecting metrics for a sample ⏳
PktStatus[i], for each packet [i], the status of the packet received. Possible status includes OK, packet header corrupt, packet payload corrupt, duplicate, fragment. The criteria to determine the status MUST be specified, if used. 🚨

4.2.4 Sample Metrics resulting from combining parameters at MP(Src) and MP(Dst) 🧮

Using everything we've got so far, a delay singleton gets calculated like this 🦋

Delay [i], for each packet [i], the time interval:

Delay[i] = Tstamp(Dst)[i] - Tstamp(Src)[i]

Now the cases where we can't compute a delay singleton, because it's just not possible 💀

Spurious: There will be no Tstamp(Src)[i] time.
Not received: There will be no Tstamp (Dst) [i].
Corrupt packet header: There will be no Tstamp (Dst) [i].
Duplicate: Only the first non-corrupt copy of the packet received at Dst should have Delay [i] computed.

A sample metric for average delay looks like this 📊

AveDelay = (1/N)Sum(from i=1 to N, Delay[i])

This assumes all packets i= 1 through N have valid singletons.

We can also compute a delay variation [5] singleton 🌊

IPDV[i], for each packet [i] except the first one, delay variation between successive packets gets calculated as:

IPDV[i] = Delay[i] - Delay [i-1]

IPDV[i] may be negative, zero, or positive. Delay singletons for packets i and i-1 must be calculable or IPDV[i] is undefined. Not complicated, but it's giving precision 💖

And an example metric for the IPDV sample is the range 🌈

RangeIPDV = max(IPDV[]) - min(IPDV[])

4.3 High level description of the procedure to collect a sample 🎬

Here's the vibe of how a sample actually goes down. Starting on or after time T0, Type-P packets are generated by Src and sent to Dst until time Tf is reached. The nominal interval between the first bit of successive packets is incT, as measured at MP(Src). ✨

But incT is only nominal, lowkey, because it can wobble for a bunch of reasons: variation in packet generation at Src, clock issues (see section 4.6), etc. 🫠

MP(Src) records the parameters above only for packets with timestamps between and including T0 and Tf, as long as they have the required Src, Dst, and any other qualifiers. MP (Dst) also records packets with timestamps between T0 and (Tf + dTstop) 🌸

Optionally, at a time Tf + Tcons (but eventually in all cases), the data from MP(Src) and MP(Dst) gets consolidated to derive the sample metric results. To keep us from stopping data collection too soon, dTcons should be greater than or equal to dTstop. Conversely, to keep collection reasonably efficient, dTstop should be some reasonable time interval (seconds/minutes/hours), even if dTloss is infinite or extremely long. ⏰

4.4 Discussion 💭

This sampling methodology is all about quantifying the delays and the delay variation as experienced by an application's multimedia streams 🎥 Because of how these metrics are defined, packet loss status gets recorded too. And the nominal interval between packets assesses network performance variations on a specific time scale. Very sus-free logic 🧠

There are a bunch of factors to keep in mind when collecting a sample metric of Type-P-One-way-Delay-Periodic-Stream 👑

The interval T0 to Tf should be specified to cover a long enough time interval to represent a reasonable use of the application under test, yet not excessively long in the same context (e.g. phone calls last longer than 100ms, but less than one week). 📞
The nominal interval between packets (incT) and the packet size(s) (p(j)) should not define an equivalent bit rate that exceeds the capacity of the egress port of Src, the ingress port of Dst, or the capacity of the intervening network(s), if known. There may be exceptional cases to test the response of the application to overload conditions in the transport networks, but these cases should be strictly controlled. Overload chaos is only allowed with a plan 🚧
Real delay values will be positive. Therefore, it does not make sense to report a negative value as a real delay. However, an individual zero or negative delay value might be useful as part of a stream when trying to discover a distribution of the delay errors. Negative delays are a red flag, but they can still help us debug 🔍
Depending on measurement topology, delay values may be as low as 100 usec to 10 msec, so it may be important for Src and Dst to synchronize very closely. GPS systems afford one way to achieve synchronization to within several 10s of usec. Ordinary application of NTP may allow synchronization to within several msec, but this depends on the stability and symmetry of delay properties among the NTP agents used, and this delay is what we are trying to measure. Tricky, bestie 🫣
A given methodology will have to include a way to determine whether a packet was lost or whether delay is merely very large (and the packet is yet to arrive at Dst). The global metric parameter dTloss defines a time interval such that delays larger than dTloss are interpreted as losses. {Comment: For many applications, the treatment of a large delay as infinite/loss will be inconsequential. A TCP data packet, for example, that arrives only after several multiples of the usual RTT may as well have been lost.} 🙈

4.5 Additional Methodology Aspects 🧩

As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). It's all about the context, babe 💜

4.6 Errors and uncertainties 😬

Any specific measurement method should include an accounting and analysis of its various sources of error or uncertainty. The Framework RFC [3] gives general guidance on this, but here are the specifics for periodic streams and delay metrics:

Error due to variation of incT. The reasons for this can be uneven process scheduling, possibly due to CPU load. 🖥️
Errors or uncertainties due to uncertainties in the clocks of the MP(Src) and MP(Dst) measurement points. ⏱️
Errors or uncertainties due to the difference between 'wire time' and 'host time'. 🔌

The uncertainty in a one-way delay measurement is related, in part, to uncertainties in the clocks of MP(Src) and MP(Dst). From here on, we call the clock used to measure when the packet was measured at MP(Src) the MP(Src) clock, and the clock used to measure when the packet was received at MP(Dst) the MP(Dst) clock. Alluding to the notions of synchronization, accuracy, resolution, and skew, here's the tea 🫖

Any error in the synchronization between the MP(Src) clock and the MP(Dst) clock will contribute to error in the delay measurement. We say that the two clocks have a synchronization error of Tsynch if the MP(Src) clock is Tsynch ahead of the MP(Dst) clock. So if we know the value of Tsynch exactly, we could correct for clock synchronization by adding Tsynch to the uncorrected value of Tstamp(Dst)[i] - Tstamp(Src) [i] 🧽
The resolution of a clock adds to uncertainty about any time measured with it. So if the MP(Src) clock has a resolution of 10 msec, that adds 10 msec of uncertainty to any time value measured with it. We'll denote the resolution of the source clock and the MP(Dst) clock as ResMP(Src) and ResMP(Dst), respectively. 🔬
The skew of a clock isn't really an extra issue, it's more a realization that Tsynch is itself a function of time. So if we try to measure or bound Tsynch, that measurement or calculation has to be repeated periodically. Over some periods of time, this function can be approximated as a linear function plus some higher order terms. In those cases, one option is to use knowledge of the linear component to correct the clock. With that correction, the residual Tsynch gets smaller, but it's still a source of uncertainty that must be accounted for. We use the function Esynch(t) to denote an upper bound on the uncertainty in synchronization, so |Tsynch(t)| <= Esynch(t). 📉

Taking all of this together, the naive computation Tstamp(Dst)[i] - Tstamp(Src) [i] will be off by Tsynch(t) +/- (ResMP(SRc) + ResMP(Dst)). Using Esynch(t), these clock-related problems add up to a total uncertainty of Esynch(t)+ Rsource + Rdest. This estimate of total clock-related uncertainty should be included in the error/uncertainty analysis of any measurement implementation. Clock drama, but make it math 🌈

We'd love to measure the time between when a packet is measured and time-stamped at MP(Src) and when it arrives and is time-stamped at MP(Dst). We call these "wire times." 😌 But if software on Src and Dst applies the timestamps, that software can only directly measure the time between when Src generates the packet just prior to sending the test packet and when Dst has started to process the packet after receiving it. We call these two points "host times." 🖥️

To the extent that the difference between wire time and host time is accurately known, that knowledge can be used to correct wire time measurements. The corrected value estimates the desired (host time) metric more accurately, and vice versa. ✨

To the extent, however, that the difference between wire time and host time is uncertain, that uncertainty must be accounted for in an analysis of a given measurement method. We denote by Hsource an upper bound on the uncertainty in the difference between the wire time of MP(Src) and the host time on the Src host. Similarly, Hdest covers the difference between the host time on the Dst host and the wire time of MP(Dst). These problems together introduce a total uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of any measurement implementation. 🫶

4.6.3. Calibration

okay so, the measured values can be broken down like this 🧠✨

   measured value = true value + systematic error + random error

If the systematic error (the constant bias in measured values) can be figured out, it can be compensated for in the reported results 💖

   reported value = measured value - systematic error

so then

   reported value = true value + random error

The goal of calibration is to pin down the systematic and random error the instruments themselves create, in as much detail as possible 🔍 At the very least, you need a bound ("e") so that the reported value lands in the range (true value - e) to (true value + e) at least 95 percent of the time 🎀 We call "e" the calibration error for the measurements. It shows how repeatable the values from the measurement instrument are, basically how closely an actual delay of 30 ms gets reported as 30 ms 🌸 {Comment: 95 percent was chosen due to reasons discussed in [4], briefly summarized as (1) some confidence level is desirable to be able to remove outliers, which will be found in measuring any physical property; (2) a particular confidence level should be specified so that the results of independent implementations can be compared.}

Based on the last two sections, you can bound the error in measurements by finding every individual uncertainty and adding them all together, like this 🧮

           Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest

But reasonable bounds are totally possible for both parts: the clock-related uncertainty (the first three terms) and the host-related uncertainty (the last two terms) 🙌 You get there with careful design and by calibrating the instruments on a known, isolated network in a lab 🧪

For example, clock-related uncertainties are way smaller when you use a GPS time source 🛰️ The sum of Esynch(t) + ResMP(Src) + ResMP(Dst) is small, and it's also bounded for the whole duration of the measurement because of that global time source 👑 The host-related uncertainties, Hsource + Hdest, could be bounded by connecting two instruments back-to-back with a high-speed serial link or an isolated LAN segment 💅 In this setup, repeated measurements are all measuring the same one-way delay.

If the test packets are small, a network connection like that has a minimal delay that can be approximated as zero ✨ So the measured delay only contains systematic and random error from the instrumentation. The "average value" of repeated measurements is the systematic error, and the variation is the random error 🦋 One way to work out the systematic error and the random error, to 95% confidence, is to repeat the experiment many times, at least hundreds of tests 😭 The systematic error would then be the median. The random error could then be found by removing the systematic error from the measured values. The 95% confidence interval would be the range from the 2.5th percentile to the 97.5th percentile of these deviations from the true value. The calibration error "e" could then be taken as the largest absolute value of these two numbers, plus the clock-related uncertainty 🧁 {Comment: as described, this bound is relatively loose since the uncertainties are added, and the absolute value of the largest deviation is used. As long as the resulting value is not a significant fraction of the measured values, it is a reasonable bound. If the resulting value is a significant fraction of the measured values, then more exact methods will be needed to compute the calibration error.}

Note that random error depends on measurement load 📈 For example, if one instrument measures many paths, that can increase interrupts, process scheduling, and disk I/O (like recording the measurements), and all of that can bump up the random error in measured singletons 🌪️ So on top of minimal-load measurements to find the systematic error, calibration measurements should be done under the same measurement load the instruments will see in the field 🫶

We really want to say this again: this statistical treatment is about calibrating the instrument. It's how you "calibrate the meter stick" and say how well the meter stick reflects reality 📏💜

4.6.4 Errors in incT

The nominal interval between packets, incT, can vary during either active or passive measurements 🌈 In passive measurement, packet headers may include a timestamp applied before most of the protocol stack, and the actual sending time may vary because of processor scheduling. For example, H.323 systems are required to have packets ready for the network stack within 5 ms of their ideal time ⏱️ There may be extra variation from the network between the Src and the MP(Src). Active measurement systems may run into similar errors, but to a smaller extent 🙈 These errors must be accounted for in some types of analysis.

4.7 Reporting

The calibration and context in which the method is used MUST be carefully considered, and SHOULD always be reported along with metric results 📝✨ We'll go through five things to think about: the Type-P of test packets, the threshold of delay equivalent to loss, error calibration, the path traversed by the test packets, and background conditions at Src, Dst, and the intervening networks during a sample 🎀 This list isn't exhaustive, though! Any other info that could help interpret how the metrics get applied should be reported too 💖

4.7.1. Type-P

As noted in the Framework document [3], the value of a metric may depend on the type of IP packets used to make the measurement, or "type-P" 🦋 The value of Type-P-One-way-Periodic-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes. The exact Type-P used to make the measurements MUST be reported 💅

4.7.2. Threshold for delay equivalent to loss

Also, the threshold for delay equivalent to loss (or the methodology to determine this threshold) MUST be reported 🌸

4.7.3. Calibration results

If the systematic error can be determined, it SHOULD be removed from the measured values 🧹
You SHOULD also report the calibration error, e, such that the true value is the reported value plus or minus e, with 95% confidence (see the last section.) 📊
If possible, the conditions under which a test packet with finite delay is reported as lost due to resource exhaustion on the measurement instrument SHOULD be reported 🫠

4.7.4. Path

The path traversed by the packets SHOULD be reported, if possible 🗺️ In general, it's impractical to know the precise path a given packet takes through the network 😵‍💫 The precise path may be known for certain Type-P packets on short or stable paths. If Type-P includes the record route (or loose-source route) option in the IP header, and the path is short enough, and all routers on the path support record (or loose-source) route, then the path will be precisely recorded.

This can be impractical, because the route has to be short enough. Lots of routers don't support record route (or aren't configured for it), and using this feature would often make the observed performance artificially worse by pulling the packet out of common-case processing 🙃

Partial info is still valuable context though 💜 For example, if a host can choose between two links (and so two separate routes from Src to Dst), then the initial link used is valuable context 🧚 {Comment: For example, with one commercial setup, a Src on one NAP can reach a Dst on another NAP by either of several different backbone networks.}

5. Additional discussion on periodic sampling

Fig.1 shows measurements on multiple protocol levels that matter for this memo 🌈 The user's focus is on transport quality evaluation from the application point of view. But to properly separate the quality contribution of the operating system and codec on packet voice, for example, it helps to be able to measure quality at the IP level [6]. Link layer monitoring gives you a way to account for link layer characteristics like bit error rates 🔥

        ---------------
        | application |
        ---------------
        |  transport  | <--
        ---------------
        |   network   | <--
        ---------------
        |    link     | <--
        ---------------
        |   physical  |
        ---------------

Fig. 1: Different possibilities for performing measurements: a protocol view. Above, "application" refers to all layers above L4 and is not used in the OSI sense.

In general, measurement results may be influenced by individual application requirements and responses related to these issues 👑

Lost packets: Applications may have varying tolerance to lost packets. Another consideration is the distribution of lost packets (i.e. random or bursty).
Long delays: Many applications will consider packets delayed longer than a certain value to be equivalent to lost packets (i.e. real time applications).
Duplicate packets: Some applications may be perturbed if duplicate packets are received.
Reordering: Some applications may be perturbed if packets arrive out of sequence. This may be in addition to the possibility of exceeding the "long" delay threshold as a result of being out of sequence.
Corrupt packet header: Most applications will probably treat a packet with a corrupt header as equivalent to a lost packet.
Corrupt packet payload: Some applications (e.g. digital voice codecs) may accept corrupt packet payload. In some cases, the packet payload may contain application specific forward error correction (FEC) that can compensate for some level of corruption.
Spurious packet: Dst may receive spurious packets (i.e. packets that are not sent by the Src as part of the metric). Many applications may be perturbed by spurious packets.

Depending on, e.g., the observed protocol level, some of the issues above may be indistinguishable from others by the application. It may be important to preserve that distinction for the operators of Src, Dst, and/or the intermediate network(s) 🎀💖

5.1 Measurement applications ✨

okay so this sampling method is giving "I don't care what QoS mechanism you're running" 💅 It works the same whether or not the IP network has any fancy QoS going on. For example, if a QoS mechanism doesn't come with hard guarantees, you can use measurements to check whether the "best" class is actually getting the service it was promised for that traffic class 👀 You could also study a cheap, low-guarantee service that runs on leftover slack bandwidth in other classes. You can do these measurements when you're figuring out whether a new service is worth it, or on a regular schedule. Very planner brain 🧠

IP delivery service measurements have been discussed inside the International Telecommunications Union (ITU). A framework for IP service level measurements, which references the framework for IP performance [3], is meant to be good for service planning and has been approved as I.380 [7]. ITU-T Recommendation I.380 covers abstract definitions of performance metrics. This memo describes a method that's useful for both service planning and end-user testing, and it works for active and passive measurements 🎀

Delay measurements can be one-way [3,4], paired one-way, or round-trip [8]. Depending on the type, the measurements may use synchronized or unsynchronized Src/Dst host clocks. The different possibilities are listed below 🦋

The reference measurement setup for all measurement types is shown in Fig. 2.

        ----------------< IP >--------------------
        |          |                  |          |
      -------   -------           --------    --------
      | Src |   | MP  |           | MP   |    | Dst  |
      -------   |(Src)|           |(Dst) |    --------
                -------           --------

                    Fig. 2: Example measurement setup.

Here's an example setup: a source host (Src), a destination host (Dst), and their measurement points (MP(Src) and MP(Dst)), like in Figure 2 🌸 If having Src and/or Dst run the measurement could seriously mess with the delay performance you're trying to measure, you can use separate equipment for the measurement points instead. MP(Src) should be placed or measured close to where packets leave Src, and MP(Dst) should be placed or measured close to where packets come into Dst. "Close" means close enough that the application-level performance you measure (like delay) can be expected to match the performance between Src and Dst with reasonable accuracy. The big idea is that results between MP(Src) and MP(Dst) should match a measurement between Src and Dst, within the general error margin target for the measurement (for example, < 1 ms, and the number of lost packets is the same) 🫶 If that's not possible, the difference between the MP-MP measurement and the Src-Dst measurement should preferably be systematic.

This test setup hits two important criteria 🔥

The test uses realistic stream metrics, emulating something like a full-duplex Voice over IP (VoIP) call.
You can get either one-way or round-trip characteristics.

You can also have intermediate measurement points between MP(Src) and MP(Dst), but that's beyond the scope of this document 🧚

5.1.1 One way measurement

okay so we want metrics that work for as many situations as possible, which is why the example metrics use application-level measurements based on one-way delays 💖 How this applies to bi-directional applications, like interactive multimedia conferencing, is discussed below.

A single one-way measurement only tells you about the network's behavior in one direction 🙈 Also, the stream at the network transport level doesn't really copy a full-duplex multimedia connection.

5.1.2 Paired one way measurement

Paired one-way delay means two multimedia streams: Src to Dst, and Dst to Src, for the same Src and Dst 💜 For some applications, the delay on each one-way path matters more than the round-trip delay. That's the case for delay-limited signals like VoIP. The difference between the one-way delays can happen because the streams from Src to Dst and from Dst to Src take different routes.

Here's an example. A paired one-way measurement might show that Src to Dst has an average delay of 30ms, while Dst to Src averages 120ms. A round-trip delay measurement would make this look like an average of 150ms 😭 Without knowing about the asymmetry, you might miss a problem the application at either end has with delays averaging more than 100ms.

Paired one-way delay measurement also emulates a full-duplex VoIP call more accurately than a single one-way measurement does 🦋

5.1.3 Round trip measurement

From the point of view of periodic multimedia streams, round-trip measurements have two big perks: they don't need host clock synchronization, and they simulate full-duplex communication ✨ Not needing clock synchronization means the measurement is easy to run, since you don't need any special equipment or NTP setup. Simulating full-duplex means the measurement streams go in both directions, so you get information about the quality of service that two-way applications actually experience 💅

The downsides are that round-trip measurement needs more bandwidth than a one-way test, and packet loss is more complicated to account for 😬 The stream returning to the original sender may also be burstier than the stream on the first "leg" of the round trip. In practice, that means the returning stream may get worse QoS than the outgoing one, so the performance estimates you get are pessimistic ones 🌈 Asymmetric routing and queuing have to be taken into account when you analyze the results.

Note that with suitable arrangements, round-trip measurements can be done using paired one-way measurements 🎀

5.2 Statistics calculable from one sample

Some statistics are especially relevant to applications simulated by periodic streams, like the range of delay values recorded during the sample 🍓

For example, a sample metric generates 100 packets at MP(Src), and MP(Dst) records the following:

80 packets received with delay [i] <= 20 ms
8 packets received with delay [i] > 20 ms
5 packets received with corrupt packet headers
4 packets from MP(Src) with no matching packet recorded at MP(Dst) (effectively lost)
3 packets received with corrupt packet payload and delay [i] <= 20 ms
2 packets that duplicate one of the 80 packets received correctly as indicated in the first item

For this example, packets count as acceptable if they arrive with a delay of less than or equal to 20ms and without corrupt packet headers or packet payload. That makes the percentage of acceptable packets 80/100 = 80% 💯

For a different application that accepts packets with corrupt packet payload and has no delay bounds (as long as the packet arrives), the percentage of acceptable packets is (80+8+3)/100 = 91% 🌟

5.3 Statistics calculable from multiple samples

There can be value in running multiple tests with this method to collect a "sample of samples" 🧁 For example, it may be more appropriate to simulate 1,000 two-minute VoIP calls than a single 2,000 minute call. When you're looking at a collection of multiple samples, you should think about the interval between samples (e.g. minutes, hours), the composition of the samples (e.g. equal Tf-T0 duration, different packet sizes), and network considerations (e.g. running different samples over different intervening link-host combinations). For things like the interval between samples, you should consider the usage pattern of the application you care about 🗓️

When you compute statistics for multiple samples, more general statistics (e.g. median, percentile, etc.) may be more relevant with a larger number of packets 📊

5.4 Background conditions

Results can often be influenced by conditions at Src, Dst, and/or any intervening networks 🌧️ Factors that may affect the results include traffic levels and/or bursts during the sample, link and/or host failures, and so on. The info about background conditions may only be available through external means (e.g. phone calls, television), and it may only show up days after the samples are taken 📞

For interactive multimedia sessions, end-to-end delay is a big deal 😤 Too much delay makes the multimedia session worse for the people in it. One approach to managing end-to-end delay on an Internet path that uses heterogeneous link layer technologies is per-domain delay quotas (e.g. 50 ms for a particular IP domain). But this scheme has clear inefficiencies, and it can over-constrain the problem of hitting some end-to-end delay objective 🙃 A more flexible implementation ought to deal with things like asymmetric delays on paths, and how sensitive an application is to delay variations in a given domain. There are several alternatives for which delay statistic to use when managing end-to-end QoS. That question is really interesting, but it's not within the scope of this memo, so we won't go further into it here 🧚‍♀️

6. Security Considerations 🔐

6.1 Denial of Service Attacks

This method generates a periodic stream of packets from one host (Src) to another host (Dst) through intervening networks. Yikes, this method could be abused for denial of service attacks aimed at Dst and/or the intervening network(s) 💀

Administrators of Src, Dst, and the intervening network(s) should set up bilateral or multi-lateral agreements about the timing, size, and frequency of collecting sample metrics. Using this method beyond the terms the participants agreed on may be cause for immediate rejection, discard of packets, or other escalation procedures defined between the affected parties 🚨

6.2 User data confidentiality

Active use of this method generates packets for a sample, rather than taking samples from user data, so it doesn't threaten user data confidentiality 🫧 Passive measurement has to restrict its attention to the headers of interest. Since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep this information safe and confidential 🔒

6.3 Interference with the metric

It may be possible to figure out that a certain packet or stream of packets is part of a sample 👀 If Dst and/or the intervening networks know that, they could change how they process those packets (e.g. increasing or decreasing delay), which may distort the measured performance. It may also be possible to generate extra packets that look like they're part of the sample metric. These additional packets are likely to perturb the results of the sample measurement 😵

To discourage the kind of interference mentioned above, packet interference checks, such as a cryptographic hash, MAY be used 🛡️

7. IANA Considerations 🌷

Since this method and metric don't define a protocol or well-known values, there are no IANA considerations in this memo 🎀

8. Normative References ✨

These are the must-reads, bestie 📚

[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[4] Almes, G., Kalidindi, S. and M. Zekauskas, "A one-way delay metric for IPPM", RFC 2679, September 1999.
[5] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.

9. Informative References 📖

Extra reading if you want to go deeper 🫶

[6] "End-to-end Quality of Service in TIPHON systems; Part 5: Quality of Service (QoS) measurement methodologies", ETSI TS 101 329-5 V1.1.2, January 2002.
[7] International Telecommunications Union, "Internet protocol data communication service _ IP packet transfer and availability performance parameters", Telecommunications Sector Recommendation I.380 (re-numbered Y.1540), February 1999.
[8] Almes, G., Kalidindi, S. and M. Zekauskas, "A round-trip delay metric for IPPM", RFC 2681, September 1999.

10. Acknowledgments 🌸

Okay, the shoutouts are SO important 💖

The authors thanked the chairs of the IPPM WG, Matt Zekauskas and Merike Kaeo 👑, for their comments, which made the document way clearer and more focused. Howard Stanislevic and Will Leland also dropped some useful comments and questions 🧚. Henk Uijterwaal kept challenging the team to build out the motivation for this method, and that pushed everyone to level up 🔥. The authors also built on the big foundation that the framework authors laid for IP performance, which is cited as [3] 🦋.

11. Author's Addresses 🎀

Here's where to find the authors, lowkey iconic ✨

Vilho Raisanen
Nokia Networks
P.O. Box 300
FIN-00045 Nokia Group
Finland

Phone: +358 7180 8000
Fax:   +358 9 4376 6852
EMail: Vilho.Raisanen@nokia.com


Glenn Grotefeld
Motorola, Inc.
1501 W. Shure Drive, MS 2F1
Arlington Heights, IL 60004 USA

Phone:  +1 847 435-0730
Fax:    +1 847 632-6800
EMail: g.grotefeld@motorola.com


Al Morton
AT&T Labs
Room D3 - 3C06
200 Laurel Ave. South
Middletown, NJ 07748 USA

Phone:  +1 732 420 1571
Fax:    +1 732 368 1192
EMail: acmorton@att.com

12. Full Copyright Statement 💜

The legal stuff gets copied word for word, no cap, because it has to stay exactly right 🙈

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🫶💅

📦 where this page comes from

ietf: rfc3432 2002-12
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms