RFC 6049
Spatial Composition of Metrics
RFC 6049: Spatial Composition of Metrics 💖
Okay bestie, this one is by A. Morton (AT&T Labs) and E. Stephan (France Telecom Orange) 🎀. It's from the IETF (Internet Engineering Task Force) and it's a Standards Track doc, so it's official and implementers are expected to follow it 👑. It came out in January 2011 🦋. The ISSN is 2070-1721 ✨. Its title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈.
Abstract
Okay so this memo is all about IP performance metrics that work for both complete paths and sub-paths 🛣️. It defines how to build a complete path metric out of sub-path metrics, and that composed number is only accurate to some degree compared to the real thing. RFC 2330 calls this "spatial composition," and it's giving main character energy 💅. The memo refers to the framework for metric composition, explains the background and why you'd even want to combine metrics, and then goes through several composed metrics and statistics 🔥.
Status of This Memo
This is an Internet Standards Track document 🎀.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6049 🌸.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🫶.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that older material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.
Table of Contents
1. Introduction ....................................................4
1.1. Motivation .................................................6
1.2. Requirements Language ......................................6
2. Scope and Application ...........................................6
2.1. Scope of Work ..............................................6
2.2. Application ................................................7
2.3. Incomplete Information .....................................7
3. Common Specifications for Composed Metrics ......................8
3.1. Name: Type-P ...............................................8
3.1.1. Metric Parameters ...................................8
3.1.2. Definition and Metric Units .........................9
3.1.3. Discussion and Other Details ........................9
3.1.4. Statistic ...........................................9
3.1.5. Composition Function ................................9
3.1.6. Statement of Conjecture and Assumptions ............10
3.1.7. Justification of the Composition Function ..........10
3.1.8. Sources of Deviation from the Ground Truth .........10
3.1.9. Specific Cases where the Conjecture Might Fail .....11
3.1.10. Application of Measurement Methodology ............12
4. One-Way Delay Composed Metrics and Statistics ..................12
4.1. Name: Type-P-Finite-One-way-Delay-<Sample>-Stream .........12
4.1.1. Metric Parameters ..................................12
4.1.2. Definition and Metric Units ........................12
4.1.3. Discussion and Other Details .......................13
4.1.4. Statistic ..........................................13
4.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean ..........13
4.2.1. Metric Parameters ..................................13
4.2.2. Definition and Metric Units of the Mean Statistic ..14
4.2.3. Discussion and Other Details .......................14
4.2.4. Statistic ..........................................14
4.2.5. Composition Function: Sum of Means .................14
4.2.6. Statement of Conjecture and Assumptions ............15
4.2.7. Justification of the Composition Function ..........15
4.2.8. Sources of Deviation from the Ground Truth .........15
4.2.9. Specific Cases where the Conjecture Might Fail .....15
4.2.10. Application of Measurement Methodology ............16
4.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum .......16
4.3.1. Metric Parameters ..................................16
4.3.2. Definition and Metric Units of the Minimum
Statistic ..........................................16
4.3.3. Discussion and Other Details .......................16
4.3.4. Statistic ..........................................16
4.3.5. Composition Function: Sum of Minima ................16
4.3.6. Statement of Conjecture and Assumptions ............17
4.3.7. Justification of the Composition Function ..........17
4.3.8. Sources of Deviation from the Ground Truth .........17
4.3.9. Specific Cases where the Conjecture Might Fail .....17
4.3.10. Application of Measurement Methodology ............17
5. Loss Metrics and Statistics ....................................18
5.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 18
5.1.1. Metric Parameters ..................................18
5.1.2. Definition and Metric Units ........................18
5.1.3. Discussion and Other Details .......................18
5.1.4. Statistic:
Type-P-One-way-Packet-Loss-Empirical-Probability ...18
5.1.5. Composition Function: Composition of
Empirical Probabilities ............................18
5.1.6. Statement of Conjecture and Assumptions ............19
5.1.7. Justification of the Composition Function ..........19
5.1.8. Sources of Deviation from the Ground Truth .........19
5.1.9. Specific Cases where the Conjecture Might Fail .....19
5.1.10. Application of Measurement Methodology ............19
6. Delay Variation Metrics and Statistics .........................20
6.1. Name: Type-P-One-way-pdv-refmin-<Sample>-Stream ...........20
6.1.1. Metric Parameters ..................................20
6.1.2. Definition and Metric Units ........................20
6.1.3. Discussion and Other Details .......................21
6.1.4. Statistics: Mean, Variance, Skewness, Quantile .....21
6.1.5. Composition Functions ..............................22
6.1.6. Statement of Conjecture and Assumptions ............23
6.1.7. Justification of the Composition Function ..........23
6.1.8. Sources of Deviation from the Ground Truth .........23
6.1.9. Specific Cases where the Conjecture Might Fail .....24
6.1.10. Application of Measurement Methodology ............24
7. Security Considerations ........................................24
7.1. Denial-of-Service Attacks .................................24
7.2. User Data Confidentiality .................................24
7.3. Interference with the Metrics .............................24
8. IANA Considerations ............................................25
9. Contributors and Acknowledgements ..............................27
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................281. Introduction ✨
The IP Performance Metrics (IPPM) framework [RFC2330] describes two forms of metric composition: spatial and temporal 🧚. The composition framework [RFC5835] expands those original forms and qualifies them further into three categories. This memo describes spatial composition, which is one of the categories under that composition framework umbrella 💖.
Spatial composition covers defining performance metrics that apply to a complete path, based on metrics collected on various sub-paths 🛣️.
The main purpose of this memo is to define the deterministic functions that produce complete path metrics from sub-path metrics. How well these metrics work depends on how useful they are for analysis and how practical they are with real measurement methods 📊.
The relationships may involve conjecture, and [RFC2330] lists four points that metric definitions should include 🌸:
- the specific conjecture applied to the metric and the assumptions of the statistical model of the process being measured (if any; see [RFC2330], Section 12),
- a justification of the practical utility of the composition in terms of making accurate measurements of the metric on the path,
- a justification of the usefulness of the composition in terms of making analysis of the path using A-frame concepts more effective, and
- an analysis of how the conjecture could be incorrect.
Also, [RFC2330] gives an example using the conjecture that the delay of a path is very nearly the sum of the delays of the exchanges and clouds of the corresponding path digest 🫶. This example is especially relevant if you want to assess the performance of an inter-domain path without measuring it directly. The performance estimate for the complete path is instead related to the measured results for various sub-paths 🦋.
Approximate functions between sub-path and complete path metrics are useful, as long as you know the circumstances where the relationships are, and aren't, applicable 🧠. For example, we wouldn't expect delay singletons from each sub-path to add up to an accurate estimate of a delay singleton for the complete path. The exception is if all the delays were essentially constant, which is very unlikely 💀. Other delay statistics, though, based on a reasonable sample size, may have a large enough set of circumstances where they are applicable 🌈.
1.1. Motivation ✨
okay so the one-way metrics in [RFC2679] and [RFC2680] are giving "just measure it from source to destination," and that's literally the assumption everything is built on 💅. but sometimes that just can't happen, bestie 😭. the path might cross a bunch of independent domains with totally different policies, measurement tools and methods, and measurement timing. so the move is to compose several sub-path measurements 🧩. each domain runs a one-way measurement on its own sub-path between two nodes that are part of the full path, using its own policy, tools, methods, and timing. and under the right conditions, you can combine those sub-path results to estimate the complete path's one-way metric, with some degree of accuracy 🎀.
1.2. Requirements Language 🌸
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
also, in this memo, the characters "<=" should be read as "less than or equal to," and ">=" as "greater than or equal to" 🤓.
2. Scope and Application ✨
2.1. Scope of Work 💖
for the primary IP Performance Metrics RFCs on loss [RFC2680], delay [RFC2679], and delay variation [RFC3393], this memo gives a set of metrics that can be composed from the same or similar sub-path metrics. so the composition function is allowed to use:
- the same metric for each sub-path;
- multiple metrics for each sub-path (possibly one that is the same as the complete path metric);
- a single sub-path metric that is different from the complete path metric;
- different measurement techniques, like active [RFC2330], [RFC3432] and passive [RFC5474].
we also note a possibility: you could use the complete path metric plus all but one sub-path metric to infer the performance of the missing sub-path, especially when the "last" sub-path metric is the one that's missing 👀. however, those de-composition calculations, and the set of issues they bring up, are beyond the scope of this memo 🙃.
2.2. Application 🦋
the composition framework [RFC5835] requires that the applicable circumstances for each metric be specified. in particular, each section covers whether the metric:
- requires the same test packets to traverse all sub-paths, or can use similar packets that are sent and collected separately in each sub-path;
- requires homogeneous measurement methodologies, or can allow a degree of flexibility (e.g., active, active spatial division [RFC5644], or passive methods produce the "same" metric). also, the applicable sending streams will be specified, such as Poisson, Periodic, or both;
- needs information or access that will only be available within an operator's domain, or is applicable to inter-domain composition;
- requires synchronized measurement start and stop times in all sub-paths, or largely overlapping measurement intervals, or no timing requirements at all;
- requires the assumption of sub-path independence with regard to the metric being defined or composed, or other assumptions;
- has known sources of inaccuracy or error, and identifies those sources.
2.3. Incomplete Information 🙈
in practice, measurements sometimes can't be started on a sub-path (and maybe the measurement system gives up partway through the test interval). when that happens, there won't be a value reported for that sub-path, and the entire test result SHOULD be recorded as "undefined." this case should be kept separate from the case where the measurement system kept sending packets the whole test interval but every single one was declared lost 😤.
when a composed metric needs measurements from sub-paths A, B, and C, and one or more of those sub-path results are undefined, then the composed metric SHOULD also be recorded as undefined 💀.
3. Common Specifications for Composed Metrics 🧚
to cut down on the repeated info in the detailed metric sections that come after, this section lays out the specs that two or more metrics have in common. it's organized with the same subsections as the individual metrics, so comparing them is easy peasy 🍓.
also, the index variables are written like this:
- m = index for packets sent.
- n = index for packets received.
- s = index for involved sub-paths.
3.1. Name: Type-P 💜
all metrics use the "Type-P" convention as described in [RFC2330]. the rest of each name is unique to that metric.
3.1.1. Metric Parameters 🎀
- Src, the IP address of a host.
- Dst, the IP address of a host.
- T, a time (start of test interval).
- Tf, a time (end of test interval).
- lambda, a rate in reciprocal seconds (for Poisson Streams).
- incT, the nominal duration of inter-packet interval, first bit to first bit (for Periodic Streams).
- dT, the duration of the allowed interval for Periodic Stream 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 (for Periodic Streams).
- TstampSrc, the wire time of the packet as measured at MP(Src) (measurement point at the source).
- TstampDst, the wire time of the packet as measured at MP(Dst), assigned to packets that arrive within a "reasonable" time.
- Tmax, a maximum waiting time for packets at the destination, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost). this way, the distribution of delay is not truncated 📈.
- M, the total number of packets sent between T0 and Tf.
- N, the total number of packets received at Dst (sent between T0 and Tf).
- S, the number of sub-paths involved in the complete Src-Dst path.
- Type-P, as defined in [RFC2330], which includes any field that may affect a packet's treatment as it traverses the network.
in metric names, the term <Sample> is meant to be swapped out for the name of the method used to define a sample of values of parameter TstampSrc. there are a few ways to do that, including:
- Poisson: a pseudo-random Poisson process of rate lambda, whose values fall between T and Tf. the time interval between successive values of TstampSrc will then average 1/lambda, as per [RFC2330].
- Periodic: a Periodic stream process with pseudo-random start time T0 between T and dT, and nominal inter-packet interval incT, as per [RFC3432].
3.1.2. Definition and Metric Units 🦄
this section is unique for every metric.
3.1.3. Discussion and Other Details 🌈
this section is unique for every metric.
3.1.4. Statistic ⭐
this section is unique for every metric.
3.1.5. Composition Function 🔥
this section is unique for every metric.
3.1.6. Statement of Conjecture and Assumptions 🧠
this section is unique for each metric. the term "ground truth" shows up a lot in these sections, and it's defined in Section 4.7 of [RFC5835] 📚.
3.1.7. Justification of the Composition Function 💅
it's sometimes impractical to run active measurements between every Src-Dst pair. since a full mesh of N measurement points grows as N x N, the scope of measurement may be limited by testing resources 😩.
there can also be different limits on active testing in different parts of the network. for example, it may not be possible to collect the desired sample size in each test interval when the access link speed is limited, because measurement traffic could hurt the user traffic's performance 🚫. the conditions on a low-speed access link may be understood well enough to allow a small sample size or rate, while a larger sample size or rate may be used on other sub-paths.
and since measurement operations have a real monetary cost, there's value in re-using measurements wherever they apply, rather than launching new measurements for every possible source-destination pair 💸.
3.1.8. Sources of Deviation from the Ground Truth 🕵️
3.1.8.1. Sub-Path List Differs from Complete Path 🛣️
the measurement packets, which have source and destination addresses meant for collection at the edges of the sub-path, may take a different specific path through the network equipment and links than packets with the source and destination addresses of the complete path. parallel paths can come from things like Equal Cost Multi-Path and parallel (or bundled) links 🔀. so the performance estimated from composing sub-path measurements may differ from the performance packets actually experience on the complete path. multiple measurements using enough sub-path address pairs might produce bounds on how big this error can be.
we also note the possibility of re-routing during a measurement interval, since it may affect the correspondence between packets traversing the complete path and the sub-paths that were "involved" before the re-route 🔁.
3.1.8.2. Sub-Path Contains Extra Network Elements 🔌
related to the alternate path case above is the case where elements in the measured path exist only because of the measurement system's connectivity. for example, a measurement system may use a dedicated link to a LAN switch, and packets on the complete path don't traverse that link. the performance of a dedicated link like that would be measured continuously, and its contribution to the sub-path metrics SHOULD be minimized as a source of error 🧹.
3.1.8.3. Sub-Paths Have Incomplete Coverage 🧩
measurements of sub-path performance may not cover all the network elements on the complete path. for example, network exchange points might be excluded unless a cooperative measurement is conducted. in that case, test packets on the previous sub-path are received just before the exchange point, and test packets on the next sub-path are injected just after the same exchange point 🙃. clearly, the set of sub-path measurements SHOULD cover all critical network elements in the complete path 🎯.
3.1.8.4. Absence of Route 🚧
at a specific point in time, there may be no viable route between the complete path source and destination. the routes selected for one or more sub-paths therefore differ from the complete path. as a result, spatial composition may produce a finite estimate of a ground truth metric (see Section 4.7 of [RFC5835]) between a source and a destination, even when the route between them is undefined 🤯.
3.1.9. Specific Cases where the Conjecture Might Fail 🔍
okay so this section is literally unique for every metric, bestie, so check the metric-specific sections too 💅
For delay metrics, one-way delay always depends on packet size and link capacity, since [RFC2679] measures it from first bit to last bit 📏 If the size of an IP packet changes along its route (because of encapsulation), that can mess with delay performance 🙈 But ngl the main error source might be the extra processing that comes with encapsulation and encryption/decryption, especially if you don't experience or account for it in sub-path measurements 💀
Fragmentation is a major issue for composition accuracy 😭 All metrics need every fragment to arrive before moving on, and fragmented complete-path performance is likely to be different from non-fragmented packets and from composed metrics built on non-fragmented sub-path measurements. It's giving chaos 🌀
Highly manipulated routing can cause measurement error if you don't expect it and compensate 🎀 For example, policy-based MPLS routing could change the class of service for the sub-paths and the complete path 🦋
3.1.10. Application of Measurement Methodology 🧪
- The methodology SHOULD use similar packets sent and collected separately in each sub-path 🫶 "Similar" here means that Type-P contains as many equal attributes as possible, while recognizing that there will be differences. Note that Type-P includes stream characteristics (e.g., Poisson, Periodic).
- The methodology allows a degree of flexibility regarding test stream generation (e.g., active or passive methods can produce an equivalent result, but the lack of control over the source, timing, and correlation of passive measurements is much more challenging) 🍓
- Poisson and/or Periodic streams are RECOMMENDED ✨
- The methodology applies to both inter-domain and intra-domain composition 🌈
- The methodology SHOULD have synchronized measurement time intervals in all sub-paths, but largely overlapping intervals MAY suffice 🧚
- Assumption of sub-path independence with regard to the metric being defined/composed is REQUIRED 👑
4. One-Way Delay Composed Metrics and Statistics 🚀
4.1. Name: Type-P-Finite-One-way-Delay-<Sample>-Stream 🎀
This metric is a necessary element of delay composition metrics, and its definition doesn't formally exist anywhere else in IPPM literature 🤓
4.1.1. Metric Parameters
See the common parameters section (Section 3.1.1) 💖
4.1.2. Definition and Metric Units
Using the parameters above, we get the value of the Type-P-One-way-Delay singleton as per [RFC2679] ✨
For each packet "[i]" that has a finite one-way delay (in other words, excluding packets that have undefined one-way delay):
Type-P-Finite-One-way-Delay-<Sample>-Stream[i] =
FiniteDelay[i] = TstampDst - TstampSrcThis metric is measured in units of time in seconds, expressed in sufficiently low resolution to convey meaningful quantitative information. For example, microseconds resolution is usually sufficient ⏱️
4.1.3. Discussion and Other Details
The "Type-P-Finite-One-way-Delay" metric lets you calculate the sample mean statistic 🧠 This solves the problem of including lost packets in the sample (whose delay is undefined) and the issue with informally assigning infinite delay to lost packets (practical systems can only assign some very large value) 🙃
The Finite-One-way-Delay approach handles lost packets by shrinking the event space 💅 We look at conditional statistics and estimate the mean one-way delay, conditioned on the event that all packets in the sample arrive at the destination (within the specified waiting time, Tmax). This lets us make some valid statements about one-way delay while avoiding events with undefined outcomes 🫧 The approach is derived from the treatment of lost packets in [RFC3393], and it's similar to [Y.1540] 🔥
4.1.4. Statistic
All statistics defined in [RFC2679] apply to the finite one-way delay, and additional metrics are possible, such as the mean (see below) 📊
4.2. Name: Type-P-Finite-Composite-One-way-Delay-Mean 🌸
This section describes a statistic based on the Type-P-Finite-One-way-Delay-<Sample>-Stream metric 💜
4.2.1. Metric Parameters
See the common parameters section (Section 3.1.1) 🦋
4.2.2. Definition and Metric Units of the Mean Statistic
We define:
Type-P-Finite-One-way-Delay-Mean =
N
---
1 \
MeanDelay = - * > (FiniteDelay [n])
N /
---
n = 1where all packets n = 1 through N have finite singleton delays.
This metric is measured in units of time in seconds, expressed in sufficiently fine resolution to convey meaningful quantitative information. For example, microseconds resolution is usually sufficient 🧁
4.2.3. Discussion and Other Details
The Type-P-Finite-One-way-Delay-Mean metric requires the conditional delay distribution described in Section 4.1.3 🎯
4.2.4. Statistic
This metric, a mean, doesn't need additional statistics 💅
4.2.5. Composition Function: Sum of Means
The Type-P-Finite-Composite-One-way-Delay-Mean, or CompMeanDelay, for the complete source-to-destination path can be calculated by adding up the mean delays of all of its S constituent sub-paths ➕
So the:
Type-P-Finite-Composite-One-way-Delay-Mean =
S
---
\
CompMeanDelay = > (MeanDelay [s])
/
---
s = 1where sub-paths s = 1 to S are involved in the complete path 🛤️
4.2.6. Statement of Conjecture and Assumptions
The mean of a sufficiently large stream of packets measured on each sub-path during the interval [T, Tf] will be representative of the ground truth mean of the delay distribution (and the distributions themselves are sufficiently independent), so the means can be added to produce an estimate of the complete path mean delay 🥰
It's assumed that the one-way delay distributions of the sub-paths and the complete path are continuous. The mean of multi-modal distributions has the unfortunate property that such a value may never occur 😬
4.2.7. Justification of the Composition Function
See the common section (Section 3) 📚
4.2.8. Sources of Deviation from the Ground Truth
See the common section (Section 3) 🕵️
4.2.9. Specific Cases where the Conjecture Might Fail
If any of the sub-path distributions are multi-modal, then the measured means may not be stable, and in that case the mean won't be a particularly useful statistic for describing the delay distribution of the complete path 🫠
The mean may not be a robust enough statistic to produce a reliable estimate, or to be useful even if it can be measured 🙈
If a link that contributes non-negligible delay is erroneously included or excluded, the composition will be in error 🚨
4.2.10. Application of Measurement Methodology
The requirements of the common section (Section 3) apply here as well 🫶
4.3. Name: Type-P-Finite-Composite-One-way-Delay-Minimum 🌟
This section describes a statistic based on the Type-P-Finite-One-way-Delay-<Sample>-Stream metric, and the composed metric based on that statistic 🧩
4.3.1. Metric Parameters
See the common parameters section (Section 3.1.1) 💫
4.3.2. Definition and Metric Units of the Minimum Statistic
We define:
Type-P-Finite-One-way-Delay-Minimum =
MinDelay = (FiniteDelay [j])
such that for some index, j, where 1 <= j <= N
FiniteDelay[j] <= FiniteDelay[n] for all nwhere all packets n = 1 through N have finite singleton delays.
This metric is measured in units of time in seconds, expressed in sufficiently fine resolution to convey meaningful quantitative information. For example, microseconds resolution is usually sufficient ⏲️
4.3.3. Discussion and Other Details
The Type-P-Finite-One-way-Delay-Minimum metric requires the conditional delay distribution described in Section 4.1.3 🎀
4.3.4. Statistic
This metric, a minimum, doesn't need additional statistics 🦄
4.3.5. Composition Function: Sum of Minima
The Type-P-Finite-Composite-One-way-Delay-Minimum, or CompMinDelay, for the complete source-to-destination path can be calculated by adding up the minimum delays of all of its S constituent sub-paths 🧮
Type-P-Finite-Composite-One-way-Delay-Minimum =
S
---
\
CompMinDelay = > (MinDelay [s])
/
---
s = 14.3.6. Statement of Conjecture and Assumptions
The minimum of a sufficiently large stream of packets measured on each sub-path during the interval [T, Tf] will be representative of the ground truth minimum of the delay distribution (and the distributions themselves are sufficiently independent), so the minima can be added to produce an estimate of the complete path minimum delay 🌷
It's assumed that the one-way delay distributions of the sub-paths and the complete path are continuous 🫧
4.3.7. Justification of the Composition Function
See the common section (Section 3) 📖
4.3.8. Sources of Deviation from the Ground Truth
See the common section (Section 3) 🔎
4.3.9. Specific Cases where the Conjecture Might Fail
If the routing on any of the sub-paths isn't stable, then the measured minimum may not be stable either 😵💫 In that case the composite minimum would tend to produce an estimate for the complete path that may be too low for the current path 📉
4.3.10. Application of Measurement Methodology
The requirements of the common section (Section 3) apply here as well 💖
5. Loss Metrics and Statistics 🫧
5.1. Type-P-Composite-One-way-Packet-Loss-Empirical-Probability 🌈
5.1.1. Metric Parameters
See the common parameters section (Section 3.1.1) 🎀
5.1.2. Definition and Metric Units
Using the parameters above, we get the value of the Type-P-One-way-Packet-Loss singleton and stream as per [RFC2680] 🧠
We get a sequence of pairs with these elements:
- TstampSrc, as above.
- L, either zero or one, where L = 1 indicates loss and L = 0 indicates arrival at the destination within TstampSrc + Tmax.
5.1.3. Discussion and Other Details
None. 🤷♀️
5.1.4. Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability
Given the stream parameter M, the number of packets sent, we can define the Empirical Probability of Loss Statistic (Ep), consistent with average loss in [RFC2680], like this 📉
Type-P-One-way-Packet-Loss-Empirical-Probability =
M
---
1 \
Ep = - * > (L[m])
M /
---
m = 1where all packets m = 1 through M have a value for L. 🫶
5.1.5. Composition Function: Composition of Empirical Probabilities ✨
okay so this is the formula for stitching together the empirical loss probability of a whole source-to-destination path 🧵 you take the CompEp (the Type-P-One-way-Composite-Packet-Loss-Empirical-Probability) and build it from every sub-path's Ep (Ep1, Ep2, Ep3, all the way to Epn) like this:
Type-P-Composite-One-way-Packet-Loss-Empirical-Probability =
CompEp = 1 - {(1 - Ep1) x (1 - Ep2) x (1 - Ep3) x ... x (1 - EpS)}and if any of the Eps is undefined for a measurement interval (maybe a measurement system failed to report a value 😭), then any CompEp that uses that sub-path for that interval is also undefined. no shortcuts, bestie 🫶
5.1.6. Statement of Conjecture and Assumptions 🎀
here's the vibe check: if you take a big enough stream of packets on each sub-path during the interval [T, Tf], the empirical loss probability you get should represent the ground truth loss probability 🎯 (and the probabilities are sufficiently independent of each other 💅). that's what lets you combine the sub-path probabilities into an estimate for the complete path loss probability ✨
5.1.7. Justification of the Composition Function 🦋
check the common section (Section 3), it's the same story there 💖
5.1.8. Sources of Deviation from the Ground Truth 🌸
same deal here, the common section (Section 3) has the full tea ☕
5.1.9. Specific Cases where the Conjecture Might Fail 💀
okay so the big worry with combining loss measurements like this is that the root causes might be correlated to some degree 😬
like, if the links of different networks follow the same physical route, one catastrophic event (say, a fire in a tunnel) could cause an outage or congestion on the remaining paths in several networks at once 🔥 so it's really important not to combine measurements taken before the event with ones taken after it when you're estimating the composite performance 🙈
or, when traffic volumes spike because an email-borne worm is spreading fast, loss from queue overflow in one network might actually help another network carry its own traffic without loss 🤯 the chaos is real 🌪️
5.1.10. Application of Measurement Methodology 🧚
check the common section (Section 3) again, it's all there 🍓
6. Delay Variation Metrics and Statistics 💜
6.1. Name: Type-P-One-way-pdv-refmin-<Sample>-Stream 🦋
this packet delay variation (PDV) metric is a necessary piece of Composed Delay Variation metrics 🫶 and fun fact, its definition doesn't formally exist anywhere else in the IPPM literature (the one exception is [RFC5481]) 🤓
6.1.1. Metric Parameters 🎀
on top of the parameters from Section 3.1.1, we've got:
TstampSrc[i], the wire time of packet[i] as measured at MP(Src) (the measurement point at the source) 🌟TstampDst[i], the wire time of packet[i] as measured at MP(Dst), assigned to packets that arrive within a "reasonable" time ⏰B, a packet length in bits 📏F, a selection function that unambiguously defines which packets from the stream get picked for the packet-pair computation of this metric 💅F(current packet), which is the first packet of the pair, MUST have a validType-P-Finite-One-way-Delayless thanTmax(so basically, packets with undefined one-way delay are out 🙅♀️), and it MUST have been transmitted during the interval[T, Tf]. the second packet in the pair,F(min_delay packet), MUST be the packet with the minimum valid value ofType-P-Finite-One-way-Delayfor the stream, on top of the criteria forF(current packet). if several packets tie for the minimumType-P-Finite-One-way-Delayvalue, then the earliest arriving packet SHOULD be used 🏆MinDelay, theType-P-Finite-One-way-Delayvalue forF(min_delay packet)from above ⬇️N, the number of packets received at the destination that meet theF(current packet)criteria 🔢
6.1.2. Definition and Metric Units 💖
using the definition from Section 5.1.2, we get Type-P-Finite-One-way-Delay-<Sample>-Stream[n], the singleton for each packet[i] in the stream (a.k.a. FiniteDelay[i]) ✨
for each packet[n] that meets the F(first packet) criteria from above:
Type-P-One-way-pdv-refmin-<Sample>-Stream[n] =
PDV[n] = FiniteDelay[n] - MinDelaywhere PDV[i] is in units of time in seconds, at a resolution fine enough to convey meaningful quantitative information 📐 for example, microsecond resolution is usually plenty 🌸
6.1.3. Discussion and Other Details 🌈
this metric gives you a sample of delay variation normalized to the minimum delay of the sample 🎯 the resulting delay variation distribution doesn't depend on the sending sequence (though specific FiniteDelay values inside the distribution might be correlated, depending on stream parameters like packet spacing 🤔). this metric is equivalent to the IP Packet Delay Variation parameter defined in [Y.1540] 🫶
6.1.4. Statistics: Mean, Variance, Skewness, Quantile 📊
okay the mean PDV is defined as follows (where every packet n = 1 through N has a value for PDV[n]) 💜
Type-P-One-way-pdv-refmin-Mean = MeanPDV =
N
---
1 \
- * > (PDV[n])
N /
---
n = 1and the variance of PDV is:
Type-P-One-way-pdv-refmin-Variance = VarPDV =
N
---
1 \ 2
------- > (PDV[n] - MeanPDV)
(N - 1) /
---
n = 1and the skewness of PDV is:
Type-P-One-way-pdv-refmin-Skewness = SkewPDV =
N
--- 3
\ / \
> | PDV[n] - MeanPDV |
/ \ /
---
n = 1
-----------------------------------
/ \
| ( 3/2 ) |
\ (N - 1) * VarPDV /(see Appendix X of [Y.1541] for extra background info 📚)
and the quantile of the PDV sample is the value where the specified fraction of singletons is less than the given value 🎀
6.1.5. Composition Functions 🧩
this section gives two alternative composition functions 💅 the goal is to estimate a quantile of the complete path delay variation distribution, and the composed quantile gets estimated using info from the sub-path delay variation distributions ✨
6.1.5.1. Approximate Convolution 🌊
the Type-P-Finite-One-way-Delay-<Sample>-Stream samples from each sub-path get summarized as a histogram with 1-ms bins representing the one-way delay distribution 📊
from [STATS], the distribution of the sum of independent random variables can be derived using this relation:
Type-P-Composite-One-way-pdv-refmin-quantile-a =
. .
/ /
P(X + Y + Z <= a) = | | P(X <= a - y - z) * P(Y = y) * P(Z = z) dy dz
/ /
` `
z yquick note: dy and dz indicate partial integration above, and y and z are the integration variables 🤓 the probability of an outcome is written P(outcome), where X, Y, and Z are random variables representing the delay variation distributions of the sub-paths of the complete path (in this case there are three sub-paths), and "a" is the quantile of interest 🎯
you can use this relation to compose a quantile of interest for the complete path from the sub-path delay distributions 🫶 the histograms with 1-ms bins are just discrete approximations of the delay distributions 💜
6.1.5.2. Normal Power Approximation (NPA) ⚡
Type-P-One-way-Composite-pdv-refmin-NPA for the complete source to destination path can be calculated by combining the statistics of all the constituent sub-paths, using the process described in [Y.1541], Clause 8 and Appendix X 🎀
6.1.6. Statement of Conjecture and Assumptions 🌟
the delay distribution of a sufficiently large stream of packets measured on each sub-path during the interval [T, Tf] will be sufficiently stationary 🧘♀️ and the sub-path distributions themselves are sufficiently independent, so the summary info describing the sub-path distributions can be combined to estimate the delay distribution of the complete path 💅
it's also assumed that the one-way delay distributions of the sub-paths and the complete path are continuous 🌈
6.1.7. Justification of the Composition Function 🦋
check the common section (Section 3) 💖
6.1.8. Sources of Deviation from the Ground Truth 🍓
okay so there are a few extra deviation sources here on top of the common ones 🙈 first, very tight distributions with ranges around a few milliseconds don't get represented accurately by a histogram with 1-ms bins 📉 that bin size was picked assuming an implicit accuracy requirement: errors of a few milliseconds are acceptable when you're assessing a composed distribution quantile ⏱️
also, summary statistics can't describe the subtleties of an empirical distribution exactly, especially when the distribution looks really different from a classical form 😵💫 any procedure that uses these statistics alone may pick up error 🫠
6.1.9. Specific Cases where the Conjecture Might Fail 💀
if the delay distributions of the sub-paths are somehow correlated, then neither of these composition functions will be a reliable estimator of the complete path distribution 😭
and in practice, sub-path delay distributions with extreme outliers have increased the error of the composed metric estimate 🚨
6.1.10. Application of Measurement Methodology 🧚
check the common section (Section 3) once more 🍓
7. Security Considerations 🔐
⚠️ this part is seriously important, bestie, so read it all 🫶
7.1. Denial-of-Service Attacks 🚨
this metric needs a stream of packets sent from one host (the source) to another host (the destination) through intervening networks 🛰️ that means the method could be abused for denial-of-service attacks aimed at the destination and/or the intervening network(s) 😱
so the administrators of the source, destination, and intervening networks should set up bilateral or multilateral 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 or discarding of packets, or for other escalation procedures defined between the affected parties 🚫
7.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 🫶 but passive measurement MUST restrict attention to the headers of interest 👀 and since user payloads may be temporarily stored for length analysis, suitable precautions MUST be taken to keep that info safe and confidential 🔐 in most cases, a hashing function will produce a value suitable for payload comparisons 🧁
7.3. Interference with the Metrics ✨
Okay so, it might be possible to figure out that a certain packet or stream of packets is part of a sample 👀. Once the destination or the networks in between know that, they could mess with how those packets get handled (like adding or cutting delay 🐢), and that can totally warp the measured performance 😭. It's also possible to make extra packets that look like they belong to the sample metric, and those are likely to throw off the results 💀.
To discourage that kind of meddling, packet interference checks, like a cryptographic hash, may be used 🔐.
8. IANA Considerations 🎀
Metrics defined in the IETF are usually registered in the IANA IPPM Metrics Registry, as described in the initial version of the registry [RFC4148] 📋.
IANA has registered the following metrics in the IANA-IPPM-METRICS-REGISTRY-MIB 🌸:
ietfFiniteOneWayDelayStream OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Finite-One-way-Delay-Stream"
REFERENCE "RFC 6049, Section 4.1."
::= { ianaIppmMetrics 71 }
ietfFiniteOneWayDelayMean OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Finite-One-way-Delay-Mean"
REFERENCE "RFC 6049, Section 4.2."
::= { ianaIppmMetrics 72 }
ietfCompositeOneWayDelayMean OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Finite-Composite-One-way-Delay-Mean"
REFERENCE "RFC 6049, Section 4.2.5."
::= { ianaIppmMetrics 73 }
ietfFiniteOneWayDelayMinimum OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Finite-One-way-Delay-Minimum"
REFERENCE "RFC 6049, Section 4.3.2."
::= { ianaIppmMetrics 74 }
ietfCompositeOneWayDelayMinimum OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Finite-Composite-One-way-Delay-Minimum"
REFERENCE "RFC 6049, Section 4.3."
::= { ianaIppmMetrics 75 }
ietfOneWayPktLossEmpiricProb OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-way-Packet-Loss-Empirical-Probability"
REFERENCE "RFC 6049, Section 5.1.4"
::= { ianaIppmMetrics 76 }
ietfCompositeOneWayPktLossEmpiricProb OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Composite-One-way-Packet-Loss-Empirical-Probability"
REFERENCE "RFC 6049, Section 5.1."
::= { ianaIppmMetrics 77 }
ietfOneWayPdvRefminStream OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-way-pdv-refmin-Stream"
REFERENCE "RFC 6049, Section 6.1."
::= { ianaIppmMetrics 78 }
ietfOneWayPdvRefminMean OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-way-pdv-refmin-Mean"
REFERENCE "RFC 6049, Section 6.1.4."
::= { ianaIppmMetrics 79 }
ietfOneWayPdvRefminVariance OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-way-pdv-refmin-Variance"
REFERENCE "RFC 6049, Section 6.1.4."
::= { ianaIppmMetrics 80 }
ietfOneWayPdvRefminSkewness OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-way-pdv-refmin-Skewness"
REFERENCE "RFC 6049, Section 6.1.4."
::= { ianaIppmMetrics 81 }
ietfCompositeOneWayPdvRefminQtil OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-Composite-One-way-pdv-refmin-quantile-a"
REFERENCE "RFC 6049, Section 6.1.5.1."
::= { ianaIppmMetrics 82 }
ietfCompositeOneWayPdvRefminNPA OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Type-P-One-way-Composite-pdv-refmin-NPA"
REFERENCE "RFC 6049, Section 6.1.5.2."
::= { ianaIppmMetrics 83 }9. Contributors and Acknowledgements 🫶
These lovely people contributed useful ideas, suggestions, or the text of sections that ended up in this memo 💖:
- Phil Chimento <vze275m9@verizon.net>
- Reza Fardid <RFardid@cariden.com>
- Roman Krzanowski <roman.krzanowski@verizon.com>
- Maurizio Molina <maurizio.molina@dante.org.uk>
- Lei Liang <L.Liang@surrey.ac.uk>
- Dave Hoeflin <dhoeflin@att.com>
Way back in a galaxy far, far away (Minneapolis 🌌), Will Leland suggested the simple and elegant Type-P-Finite-One-way-Delay concept. Thank you, Will 🥹✨.
Yaakov Stein and Donald McLachlan also provided useful comments along the way 💜.
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432,
November 2002.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics
Registry", BCP 108, RFC 4148, August 2005.
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric
Composition", RFC 5835, April 2010.10.2. Informative References
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, March 2009.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009.
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance
Metrics (IPPM): Spatial and Multicast", RFC 5644,
October 2009.
[STATS] Mood, A., Graybill, F., and D. Boes, "Introduction to the
Theory of Statistics, 3rd Edition", McGraw-Hill, New York,
NY, 1974.
[Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data
communication service - IP packet transfer and
availability performance parameters", November 2007.
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance
Objectives for IP-based Services", February 2006.Authors' Addresses 🦋
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
EMail: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Stephan Emile
France Telecom Orange
2 avenue Pierre Marzin
Lannion, F-22307
France
EMail: emile.stephan@orange-ftgroup.com📦 where this page comes from
- ietf: rfc6049 2011-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms