RFC 5835
Framework for Metric Composition
RFC 5835: Framework for Metric Composition 💖
Okay bestie, this one is RFC 5835, titled Framework for Metric Composition 🦋. It came out in April 2010 and it's Informational, so it's guidance, not a standard you're forced to follow 🌸. The editors are A. Morton, Ed. (AT&T Labs) and S. Van den Berghe, Ed. (Alcatel-Lucent), and it's got ISSN 2070-1721. The title block doesn't list any RFCs it obsoletes or updates, so it's not replacing or patching anything else ✨.
Abstract
Okay so this memo is a detailed framework for composing and aggregating metrics, both across time and across space 🧚. Those metrics were originally defined by the IP Performance Metrics (IPPM) work in RFC 2330, and the IETF has developed them since. This framework memo describes the generic composition and aggregation mechanisms. It's basically the foundation, and other documents can build on it to define detailed compositions and aggregations that are actually useful in practice 💅.
Status of This Memo
This document is not an Internet Standards Track specification. It's published purely for informational purposes 🎀.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 👀.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5835. That's the spot 💜.
Copyright Notice
Copyright (c) 2010 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, which you can find at http://trustee.ietf.org/license-info, as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🫶. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. 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 .................................................4
1.1.1. Reducing Measurement Overhead .......................4
1.1.2. Measurement Re-Use ..................................5
1.1.3. Data Reduction and Consolidation ....................5
1.1.4. Implications on Measurement Design and Reporting ....6
2. Requirements Language ...........................................6
3. Purpose and Scope ...............................................6
4. Terminology .....................................................7
4.1. Measurement Point ..........................................7
4.2. Complete Path ..............................................7
4.3. Complete Path Metric .......................................7
4.4. Complete Time Interval .....................................7
4.5. Composed Metric ............................................7
4.6. Composition Function .......................................7
4.7. Ground Truth ...............................................8
4.8. Interval ...................................................8
4.9. Sub-Interval ...............................................8
4.10. Sub-Path ..................................................8
4.11. Sub-Path Metrics ..........................................8
5. Description of Metric Types .....................................9
5.1. Temporal Aggregation Description ...........................9
5.2. Spatial Aggregation Description ............................9
5.3. Spatial Composition Description ...........................10
5.4. Help Metrics ..............................................10
5.5. Higher-Order Composition ..................................11
6. Requirements for Composed Metrics ..............................11
6.1. Note on Intellectual Property Rights (IPR) ................12
7. Guidelines for Defining Composed Metrics .......................12
7.1. Ground Truth: Comparison with Other IPPM Metrics ..........12
7.1.1. Ground Truth for Temporal Aggregation ..............14
7.1.2. Ground Truth for Spatial Aggregation ...............15
7.2. Deviation from the Ground Truth ...........................15
7.3. Incomplete Information ....................................15
7.4. Time-Varying Metrics ......................................15
8. Security Considerations ........................................16
9. Acknowledgements ...............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................171. Introduction ✨
The IP Performance Metrics (IPPM) framework [RFC2330] describes two forms of metric composition, spatial and temporal 🦋. The text also suggests that the concepts of the analytical framework (or A-frame) would help derive composed metrics from real metrics. How useful composed metrics are depends on how useful they are in analysis and how well they apply to real measurement situations 💖.
This memo expands on the idea of composition and gives a detailed framework for several classes of metrics that the original IPPM framework described. Those classes are temporal aggregation, spatial aggregation, and spatial composition 🌈.
1.1. Motivation 🧠
Network operators have deployed measurement systems for lots of reasons, like performance monitoring, maintenance support, network engineering, and reporting performance to customers 📊. Collecting elementary measurements alone isn't enough to understand how a network behaves. Usually the measurements need post-processing so you can pull out what matters for each purpose. The first step is often "composition," which means combining single measurements or sets of measurements into other forms. Composition and aggregation give the operator even more post-processing options, and the key motivations are below 💅.
1.1.1. Reducing Measurement Overhead 📉
Okay so here's the thing: a network's measurement possibilities grow with the square of the number of nodes 😭. Every measurement has overhead, though. There's storage for the results, traffic on the network (if the methods are active), and the operation and administration of the measurement system itself. In a big network, it's impossible to measure from every node to every other node 🙈.
An individual network operator should be able to arrange their measurement paths along physical topology lines, or along routing areas or Autonomous Systems. That keeps dependencies and overlap between measurement paths low. This way the sheer number of measurements can go down, as long as the operator has methods to estimate performance between any particular pair of nodes when needed 🫶.
Composition and aggregation are a big deal when the path of interest crosses multiple networks and each operator runs its own measurements. In that case, the complete path performance can be estimated from measurements of its component parts 🧚.
Operators who use composition and aggregation know the estimates may carry some extra error on top of the error already in the measurements. So they're making a trade-off to keep measurement system overhead reasonable ⚖️.
1.1.2. Measurement Re-Use 🔁
Different measurement users have different needs for reporting timescales 🕰️. Network managers and maintenance teams want results super fast, so they can spot problems quickly or check whether their fix worked 🔥. Network capacity planners, and even network users, sometimes prefer a long-term view instead, like checking trends 📈. So how can one set of measurements serve both needs? 🤔
The answer is temporal aggregation. The short-term measurements the operations community needs get combined to estimate a longer-term result for everyone else 💜. Also, if there's a problem with the measurement system itself, it can be isolated to one or more of the short-term measurements. That's better than invalidating an entire long-term measurement because the problem went undetected 😤.
1.1.3. Data Reduction and Consolidation 🗂️
Another motivation is data reduction 🍓. Say there's a network where delay measurements happen among a subset of its nodes. A network manager might ask whether the network delay is a problem in general. It would be great to get a single value that indicates overall network delay. Spatial aggregation methods address this need and can produce that "single figure of merit," which could also be handy for trend analysis 🎯.
The overall value gets calculated from the elementary delay measurements, but it's not obvious how 🤷♀️. For example, it may not be reasonable to average all the delay measurements, because some paths (like ones with higher bandwidth or more important customers) might be more critical than others 👑.
Metric composition can help turn raw measurement data into some tangible, well-understood, and agreed-upon information about the service guarantees a network provides 🌸. That information can then be used in Service Level Agreement/Service Level Specification (SLA/SLS) contracts between a service provider and its customers 📝.
1.1.4. Implications on Measurement Design and Reporting 📐
If a network measurement system operator expects to need overall metrics from composition, it's smart to keep that in mind when designing measurements and the sampling plan 🧠. Also, some summary statistics are more composition-friendly than others, and that really matters when you design measurements and report results 💅.
2. Requirements Language 💅
Here's the vibe: 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] 🎀.
3. Purpose and Scope ✨
okay so the whole point of this memo is to give us one shared framework for all the different kinds of metrics that get built out of primary metrics 🧩. The scope is limited to definitions of metrics that are composed from primary metrics using a deterministic function. For each composed metric, it also keeps the key info, like the assumptions under which the relationship holds and the possible sources of error or circumstances where the composition may fail 🙈.
Right now the scope is only composed metrics for packet loss, delay, and delay variation, as defined in [RFC2679], [RFC2680], [RFC2681], [RFC3393], [RFC5481], and the comparable metrics in [Y.1540]. Composing packet reordering metrics [RFC4737] and duplication metrics [RFC5560] are research topics at the time this memo was prepared, so they're beyond the scope of this document 🔬.
This memo keeps the terminology of the IPPM Framework [RFC2330] as much as possible, but extends it when necessary 📚. It assumes you already know the concepts from [RFC2330], because they won't be repeated here 💜.
4. Terminology 💅
This section defines the terminology for the processes of metric composition and aggregation, so everyone's speaking the same language 🗣️.
4.1. Measurement Point 📍
A measurement point is the logical or physical location where packet observations are made. The term "measurement point" is synonymous with the term "observation position" used in [RFC2330] when describing the notion of wire time. A measurement point may be at the boundary between a host and an adjacent link (physical), or it may be within a host (logical) that performs measurements where the difference between host time and wire time is understood.
4.2. Complete Path 🛣️
The complete path is the actual path that a packet would follow as it travels from the packet's Source to its Destination. A complete path may span the administrative boundaries of one or more networks.
4.3. Complete Path Metric 🎯
The complete path metric is the Source-to-Destination metric that a composed metric attempts to estimate. A complete path metric represents the ground-truth for a composed metric. 👑
4.4. Complete Time Interval ⏳
The complete time interval is made up of two or more contiguous sub-intervals, and it's the interval whose performance will be estimated through temporal aggregation.
4.5. Composed Metric 🧁
A composed metric is an estimate of an actual metric describing the performance of a path over some time interval. A composed metric is derived from other metrics by applying a deterministic process or function (e.g., a composition function). The process may use metrics that are identical to the metric being composed, or metrics that are dissimilar, or some combination of both types 🌈.
4.6. Composition Function 🧪
A composition function is a deterministic process applied to individual metrics to derive another metric (such as a composed metric).
4.7. Ground Truth 🔍
As applied here, "ground truth" means the actual performance of a network path over some time interval. The ground truth is a metric on the (unavailable) packet transfer information for the desired path and time interval that a composed metric seeks to estimate. It's the real tea, but we can't directly see it 🫣.
4.8. Interval ⏱️
An interval refers to a span of time.
4.9. Sub-Interval 🧩
A sub-interval is a time interval that is included in another interval.
4.10. Sub-Path 🛤️
A sub-path is a portion of the complete path where at least the sub-path Source and Destination hosts are constituents of the complete path. We say that such a sub-path is "involved" in the complete path.
Since sub-paths terminate on hosts, it's important to describe how sub-paths are considered to be joined. In practice, the Source and Destination hosts may perform the function of measurement points.
If the Destination and Source hosts of two adjoining paths are co-located and the link between them would contribute negligible performance, then these hosts can be considered equivalent (even if there is no physical link between them, this is a practical concession) 🤝.
If the Destination and Source hosts of two adjoining paths have a link between them that contributes to the complete path performance, then the link and hosts constitute another sub-path that is involved in the complete path, and should be characterized and included in the composed metric 🔗.
4.11. Sub-Path Metrics 📊
A sub-path path metric is an element of the process to derive a composed metric, quantifying some aspect of the performance of a particular sub-path from its Source to Destination.
5. Description of Metric Types 🎀
This section defines the various classes of composition. There are two classes that are more accurately described as aggregation over time and space, and the third involves concatenation in space 🧠.
5.1. Temporal Aggregation Description ⏰
Aggregation in time is defined as the composition of metrics with the same type and scope obtained at different time instants or time windows. For example, starting from a time series of measurements of maximum and minimum one-way delay (OWD) on a certain network path obtained over 5-minute intervals, we get a time series measurement with a coarser resolution (60 minutes) by taking the maximum of 12 consecutive 5-minute maxima and the minimum of 12 consecutive 5-minute minima 📉.
The main reason for doing time aggregation is to reduce the amount of data that has to be stored, and to make it easier to visualize or spot regular cycles and/or growing or decreasing trends. Another useful application is detecting anomalies or abnormal changes in the network characteristics 🚨.
In RFC 2330, the term "temporal composition" is introduced, and it differs from temporal aggregation in that it refers to methodologies to predict future metrics on the basis of past observations (of the same metrics), exploiting the time correlation that certain metrics can exhibit. We do not consider this type of composition here 🔮.
5.2. Spatial Aggregation Description 🗺️
Aggregation in space is defined as the combination of metrics of the same type and different scope, in order to estimate the overall performance of a larger network. This combination may involve weighing the contributions of the input metrics ⚖️.
Suppose we want to compose the average one-way delay (OWD) experienced by flows traversing all the origin-destination (OD) pairs of a network (where the inputs are already metric "statistics"). Since we wish to include the effect of the traffic matrix on the result, it makes sense to weight each metric according to the traffic carried on the corresponding OD pair:
OWD_sum=f1*OWD_1+f2*OWD_2+...+fn*OWD_n
where fi=load_OD_i/total_load.A simple average OWD across all network OD pairs would not use the traffic weighting.
Another example metric that is "aggregated in space" is the maximum edge-to-edge delay across a single network. Assume that a Service Provider wants to advertise the maximum delay that transit traffic will experience while passing through his/her network. There can be multiple edge-to-edge paths across a network, and the Service Provider chooses either to publish a list of delays (each corresponding to a specific edge-to-edge path), or to publish a single maximum value. The latter approach simplifies the publication of measurement information, and may be sufficient for some purposes. Similar operations can be provided to other metrics, e.g., "maximum edge-to-edge packet loss", etc. 📡
We suggest that space aggregation is generally useful for getting a summary view of the behaviour of large network portions, or of coarser aggregates in general 🌍. The metric collection time instant, i.e., the metric collection time window of measured metrics, is not considered in space aggregation. We assume that either it is consistent for all the composed metrics (e.g., compose a set of average delays that all refer to the same time window), or the time window of each composed metric does not affect the aggregated metric 🪟.
5.3. Spatial Composition Description 🔗
Concatenation in space is defined as the composition of metrics of the same type with (ideally) different spatial scope, so that the resulting metric is representative of what the metric would be if obtained with a direct measurement over the sequence of the several spatial scopes. An example is the sum of mean OWDs of adjacent edge-to-edge networks, where the intermediate edge points are close to each other or happen to be the same. In this way, we can, for example, estimate OWD_AC starting from the knowledge of OWD_AB and OWD_BC. Note that there may be small gaps in measurement coverage; likewise, there may be small overlaps (e.g., the link where test equipment connects to the network) 🧵.
One key difference from examples of aggregation in space is that all sub-paths contribute equally to the composed metric, independent of the traffic load present 🤷♀️.
5.4. Help Metrics 🆘
In practice, there is often a need to compute a new metric using one or more metrics with the same spatial and time scope. For example, the metric rtt_sample_variance may be computed from two different metrics: the help metrics rtt_square_sum and rtt_sum 🧮.
The process of using help metrics is a simple calculation and not an aggregation or a concatenation, and it will not be investigated further in this memo ✋.
5.5. Higher-Order Composition 👑
Composed metrics might themselves be subject to further steps of composition or aggregation. An example would be the delay of a maximal path obtained through the spatial composition of several composed delays for each complete path in the maximal path (obtained through spatial composition). All requirements for first-order composition metrics apply to higher-order composition 🪜.
An example using temporal aggregation: twelve 5-minute metrics are aggregated to estimate the performance over an hour. The second step of aggregation would take 24 hourly metrics and estimate the performance over a day 🌸.
6. Requirements for Composed Metrics ✨
okay bestie, every single composed metric MUST come with sections that cover the following stuff 📋
Each metric description has to clearly spell out:
- the definition (and the statistic, if it applies) 💅
- the composition or aggregation relationship 🔗
- the specific conjecture the relationship is built on, plus any assumptions about the statistical model of the process being measured, if there are any (see [RFC2330], Section 12) 🧠
- a justification of practical utility or usefulness for analysis using the A-frame concepts 🎀
- one or more examples of how the conjecture could be wrong and lead to inaccuracy 💀
- the information to be reported 📝
Then, for each metric, you have to say when it applies, meaning whether the composition or aggregation:
- Requires homogeneity of measurement methodologies, or can allow a degree of flexibility (e.g., active or passive methods produce the "same" metric). It also has to say which sending streams apply, like Poisson, Periodic, or both 🌸
- Needs information or access that will only be available within an operator's network, or is applicable to inter-network composition 🌐
- Requires precisely synchronized measurement time intervals in all component metrics, or perhaps only loosely synchronized ones, or has no timing requirements at all ⏰
- Requires assumption of component metric independence with regard to the metric being defined/composed, or other assumptions 🦋
- Has known sources of inaccuracy/error, and identifies the sources 🙈
6.1. Note on Intellectual Property Rights (IPR)
okay, IP check 🫶 If one or more parts of the composition process are encumbered by Intellectual Property Rights (IPR), then the resulting composed metrics may be encumbered as well. For the IETF's policies on IPR disclosure, check out BCP 79 [RFC3979] 💜
7. Guidelines for Defining Composed Metrics 🧁
7.1. Ground Truth: Comparison with Other IPPM Metrics
Figure 1 shows the process for deriving a metric using spatial composition, and it compares the composed metric to other IPPM metrics. It's giving diagram energy 👑
Metrics <M1, M2, M3> describe the performance of sub-paths between the Source and Destination of interest during time interval <T, Tf>. These metrics are the inputs for a composition function that produces a composed metric ✨
Sub-Path Metrics
++ M1 ++ ++ M2 ++ ++ M3 ++
Src ||.......|| ||.......|| ||.......|| Dst
++ `. ++ ++ | ++ ++ .' ++
`. | .-'
`-. | .'
`._..|.._.'
,-' `-.
,' `.
| Composition |
\ Function '
`._ _,'
`--.....--'
|
++ | ++
Src ||...............................|| Dst
++ Composed Metric ++
++ Complete Path Metric ++
Src ||...............................|| Dst
++ ++
Spatial Metric
++ S1 ++ S2 ++ S3 ++
Src ||........||.........||..........|| Dst
++ ++ ++ ++
Figure 1: Comparison with Other IPPM MetricsThe composed metric is an estimate of an actual metric collected over the complete Source-to-Destination path. The complete path metric is the ground truth for the composed metric. In other words, composed metrics are trying to minimize error with regard to the complete path metric 🎯
Also, a spatial metric [RFC5644] collected for packets traveling over the same set of sub-paths gives you a basis for the ground truth of the individual sub-path metrics. Mathematical operations may be needed to isolate the performance of each sub-path 🧮
Next up, multiparty metrics (as defined in [RFC5644]) and their spatial composition 🥹 Measurements to each of the receivers produce an element of the one-to-group metric. Those elements can be composed from sub-path metrics, and the composed metrics can then be combined to create a composed one-to-group metric. Figure 2 shows how that works 🦋
Sub-Path Metrics
++ M1 ++ ++ M2 ++ ++ M3 ++
Src ||.......|| ||.......|| ||.......||Rcvr1
++ ++ ++`. ++ ++ ++
`-.
M4`.++ ++ M5 ++
|| ||.......||Rcvr2
++ ++`. ++
`-.
M6`.++
||Rcvr3
++
One-to-Group Metric
++ ++ ++ ++
Src ||........||.........||..........||Rcvr1
++ ++. ++ ++
`-.
`-. ++ ++
`-||..........||Rcvr2
++. ++
`-.
`-. ++
`-.||Rcvr3
++
Figure 2: Composition of One-to-Group MetricsHere, sub-path metrics M1, M2, and M3 get combined using a relationship to compose the metric for the Src-Rcvr1 path. Same energy for the others: M1, M4, and M5 compose the Src-Rcvr2 metric, and M1, M4, and M6 compose the Src-Rcvr3 metric 🌈
The composed one-to-group metric would list the Src-Rcvr metrics for each receiver in the group:
(Composed-Rcvr1, Composed-Rcvr2, Composed-Rcvr3)The ground truth for this composed metric is, of course, an actual one-to-group metric, where a single Source packet has been measured after traversing the complete paths to the various receivers 💖
7.1.1. Ground Truth for Temporal Aggregation
Temporal aggregation involves measurements made over sub-intervals of the complete time interval between the same Source and Destination. So the ground truth is the metric measured over the desired interval 🕰️
7.1.2. Ground Truth for Spatial Aggregation
Spatial aggregation combines lots of measurements using a weighting function, so it gives the same emphasis as if the measurements were based on actual traffic, with inherent weights. So the ground truth is the metric measured on the actual traffic, not the active streams that sample the performance 🍓
7.2. Deviation from the Ground Truth
A metric composition can deviate from the ground truth for several reasons. Two main ones are:
- The propagation of the inaccuracies of the underlying measurements when composing the metric. As part of the composition function, errors of measurements might propagate. Where possible, this analysis should be made and included with the description of each metric 📉
- A difference in scope. When you concatenate many active measurement results (from two or more sub-paths) to get the complete path metric, the actual measured path won't be identical to the complete path. It's generally hard to quantify this deviation exactly, but a metric definition might identify guidelines for keeping the deviation as small as possible 🧩
The description of the metric composition MUST include a section identifying the deviation from the ground truth 🔍
7.3. Incomplete Information
Real talk, sometimes measurements can't start on a sub-path, or during a particular measurement interval (and maybe the measurement system just gives up during the test interval) 😭 In that case there won't be a value reported for the sub-path, and the result SHOULD be recorded as "undefined" 🫠
7.4. Time-Varying Metrics
Lots of metrics depend on time-variant factors, like how much traffic is on the Source-to-Destination path. Traffic levels often have diurnal (or daily) variation, but a 24-hour measurement interval would hide it 🌙 Temporal aggregation of hourly results to estimate the daily metric would have the same effect, so the same cautions apply 🚨
Some metrics are predominantly* time-invariant, like the actual minimum one-way delay of a fixed path. That means temporal aggregation doesn't hide the results as long as the path is stable. But paths do change, and sometimes on less predictable time intervals than traffic variations 🛣️ (* Note: It's recognized that propagation delay on transmission facilities may have diurnal, seasonal, and even longer-term variations.) 🌍
8. Security Considerations 🔐
The security considerations that apply to any active measurement of live networks are relevant here too. See [RFC4656] and [RFC5357].
The exchange of sub-path measurements among network providers may be a source of concern. The information should be anonymized enough to avoid revealing unnecessary operational details (e.g., the network addresses of measurement devices) 🕵️ However, the schema for measurement exchange is beyond the scope of this memo, and it's likely to be covered by bilateral agreements for some time to come 🤝
9. Acknowledgements 🫶
The authors would like to thank Maurizio Molina, Andy Van Maele, Andreas Haneman, Igor Velimirovic, Andreas Solberg, Athanassios Liakopulos, David Schitz, Nicolas Simar, and the Geant2 Project. They also acknowledge comments and suggestions from Phil Chimento, Emile Stephan, Lei Liang, Stephen Wolff, Reza Fardid, Loki Jorgenson, and Alan Clark. Iconic cast 👑💖
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.
[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
M. Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
J. Babiarz, "A Two-Way Active Measurement Protocol
(TWAMP)", RFC 5357, October 2008.10.2. Informative References 📚
Okay bestie, this is the extra reading list 🧚 Not required to get the main idea, but so worth bookmarking if you want the full story on delay, loss, reordering, and duplication. Here's the lineup:
- [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. 📉
- [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. 🔁
- [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 🌊
- [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. 🔀
- [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009. 🦋
- [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. 👯
- [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance Metrics (IPPM): Spatial and Multicast", RFC 5644, October 2009. 🌈
- [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data communication service - IP packet transfer and availability performance parameters", November 2007. 🛰️
Authors' Addresses 🎀
And here are the people who wrote this, with their contact info, verbatim so nothing gets lost in translation 💌
Al Morton (editor)
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/
Steven Van den Berghe (editor)
Alcatel-Lucent
Copernicuslaan 50
Antwerp 2018
Belgium
Phone: +32 3 240 3983
EMail: steven.van_den_berghe@alcatel-lucent.comMain character editors, no cap 👑✨
📦 where this page comes from
- ietf: rfc5835 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms