RFC 7312
Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)
Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) ✨
Okay bestie, the paperwork first 📋. This is RFC 7312, published in August 2014 as an Informational doc (not a Standards Track spec) with ISSN 2070-1721. The authors are J. Fabini from Vienna University of Technology and A. Morton from AT&T Labs. It updates RFC 2330, which is the big IPPM framework doc, and the header doesn't list anything it obsoletes. 🎀
Internet Engineering Task Force (IETF) J. Fabini
Request for Comments: 7312 Vienna University of Technology
Updates: 2330 A. Morton
Category: Informational AT&T Labs
ISSN: 2070-1721 August 2014Abstract 🦋
Modern networks are wild, and if you want repeatable test results you need a bigger stream parameter framework. It also needs to level up the stuff that's specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with fresh considerations for measurement methodology and testing. 💅
The old framework mostly assumes deterministic connectivity, and it assumes a single test stream will represent the path's characteristics even when it's mixed in with other flows. Networks have evolved, so test stream descriptions have to evolve too. Otherwise, unexpected network features might dominate what you measure, and that is so not it. 💀 This memo describes new stream parameters for both network characterization and supporting application design using IPPM metrics. ✨
Status of This Memo 📝
This document is not an Internet Standards Track specification. It's published for informational purposes. 🌸
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details. 🧚
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7312. 🔥
Copyright Notice 💜
Copyright (c) 2014 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're in effect on the date of publication. 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 come without warranty as described in the Simplified BSD License.
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definition: Reactive Path Behavior . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. New or Revised Stream Parameters . . . . . . . . . . . . . . 5
3.1. Test Packet Type-P . . . . . . . . . . . . . . . . . . . 6
3.1.1. Multiple Test Packet Lengths . . . . . . . . . . . . 7
3.1.2. Test Packet Payload Content Optimization . . . . . . 7
3.2. Packet History . . . . . . . . . . . . . . . . . . . . . 8
3.3. Access Technology Change . . . . . . . . . . . . . . . . 8
3.4. Time-Slotted Randomness Cancellation . . . . . . . . . . 9
4. Quality of Metrics and Methodologies . . . . . . . . . . . . 10
4.1. Revised Definition of Repeatability . . . . . . . . . . . 10
4.2. Continuity No Longer an Alternative Repeatability
Criterion . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Metrics Should Be Actionable . . . . . . . . . . . . . . 12
4.4. It May Not Be Possible To Be Conservative . . . . . . . . 13
4.5. Spatial and Temporal Composition Support Unbiased
Sampling . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. When to Truncate the Poisson Sampling Distribution . . . 13
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 161. Introduction 🌈
Okay so the IETF IPPM working group first made a framework for metric development in [RFC2330]. This framework has stood the test of time 👑. It enabled a bunch of fundamental metrics, and it's only been updated once in a specific area, which is [RFC5835]. Iconic behavior, honestly.
The IPPM framework [RFC2330] mostly relies on several assumptions. One of them isn't stated outright but is assumed anyway: lightly loaded paths follow the linear "serialization delay = packet size / capacity" equation, and they're state-less or history-less. (There are some exceptions, like firewalls, which get a mention.) 🙈 But this does not hold true for lots of modern network technologies, such as reactive paths (the ones with demand-driven resource allocation) and links with time-slotted operation. Per-flow state can be observed on test packet streams, and if you don't account for that treatment, it will mess with network characterization. Flow history also affects application performance and is something users actually feel. 😭
Also, Sections 4 and 6.2 of [RFC2330] explicitly recommend repeatable measurement metrics and methodologies. Measurements in today's access networks show that the methodological guidelines of [RFC2330] need to be extended to capture how reactive these networks are. 💅 There are proposed extensions that let methodologies fulfill the continuity requirement stated in Section 6.2 of [RFC2330], but nobody can guarantee they will actually do so. Practical measurements confirm that some link types respond differently to repeated measurements with identical stimulus, meaning identical traffic patterns. If it's feasible, careful fine-tuning of measurement traffic patterns can improve measurement continuity and repeatability for these link types, as shown in [IBD]. ✨
This memo updates the IPPM framework [RFC2330] with advanced considerations for measurement methodology and testing. Quick note: when [RFC2330] was published (and for more than a decade after), IPPM work was limited to active techniques, meaning techniques that generate packet streams dedicated to measurement and don't monitor user traffic. This memo keeps that same scope. 🦋
We want to stress that this update of [RFC2330] does not invalidate or require changes to the analytic metric definitions the IPPM working group has prepared so far. Instead, it adds considerations for active measurement methodologies and expands the importance of existing conventions and notions in [RFC2330], such as "packets of Type-P". 🫶
Among these evolving networking changes is a phenomenon we call "reactive behavior", defined below. 🧚
1.1. Definition: Reactive Path Behavior
Reactive path behavior shows up in the test packet stream as a repeatable phenomenon, where packet transfer performance characteristics change according to prior observations of the packet flow of interest (at the reactive host or link). So reactive path behavior is nominally deterministic with respect to the flow of interest. Other flows or traffic load conditions may cause additional performance-affecting reactions, but those are external to the characteristics of the flow of interest. 🌸
In practice, a sender may not have absolute control over the ingress packet stream characteristics at a reactive host or link, but that doesn't change the deterministic reactions happening there. If we measure a path, the arrival characteristics at the reactive host or link are determined by the sending characteristics and the transfer characteristics of the intervening hosts and links. Identical traffic patterns at the sending host might generate different patterns at the input of the reactive host or link because of impairments in the intermediate subpath. The reactive host or link is expected to give a deterministic response to identical input patterns (composed of all flows, including the flow of interest). 🔥
Other than the size of the payload at the layer of interest and the header itself, packet content does not influence the measurement. For example, reactive behavior at the IP layer is not influenced by the TCP ports in use. Therefore, the indication of reactive behavior must include the layer at which measurements are instituted. 💜
Examples include links with Active/Inactive state detectors, and hosts or links that revise their traffic serving and forwarding rates (up or down) based on packet arrival history. 🍓
Reactive paths are tricky to measure, but their entities are usually designed to improve overall network performance and user experience. For example, they make capacity available to an active user. ✨ Reactive behavior may be an artifact of solutions that allocate scarce resources according to user demand, so it's an important problem to solve for measurement and other disciplines, such as application design. 👑
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]. 💖
2. Scope 🎀
The purpose of this memo is to foster repeatable measurement results in modern networks. It does this by highlighting the key aspects of test streams and packets and making them part of the IPPM framework. 💅
The scope is to update key sections of [RFC2330] and add considerations that will help develop new measurement methodologies for today's IP networks. Specifically, this memo describes useful stream parameters that complement the parameters discussed in Section 11.1 of [RFC2330], and the parameters described in Section 4.2 of [RFC3432] for periodic streams. 🦋
The memo also provides new considerations for updating the criteria for metrics in Section 4 of [RFC2330], the measurement methodology in Section 6.2 of [RFC2330], and other topics related to the quality of metrics and methods (see Section 4). ✨
Other topics in [RFC2330] that might be updated or augmented are deferred to future work. That includes passive measurements and various forms of hybrid active/passive measurements. 🌈
3. New or Revised Stream Parameters ✨
okay so this part is where the measuring gets seriously nuanced 🔍 There are a bunch of spots where the way you define a test and the way you read the results both get way better once you understand the stream's characteristics and the (sometimes totally unknown) network conditions that mess with the metrics 💅
- Network treatment leans heavily on the whole "packet of Type-P" definition in [RFC2330], and it has been that way for a while 👑
- State is often kept on a per-flow basis at various points along the path, where "flows" are figured out by IP and other layers. Big treatment differences happen with the simplest Type-P parameter of all: packet length. Use of multiple lengths is RECOMMENDED 🎀
- Payload content optimization (compression or format conversion) in intermediate segments breaks the convention of payload correspondence when correlating measurements are made at different points in a path 🙈
- Packet history (instantaneous or recent test rate or inactivity, also for non-test traffic) really shapes measured performance, on top of all the Type-P parameters described in [RFC2330] 🦋
- Access technology can switch mid-test 📶 A range of transfer capacities and access methods might show up during one test session. When different interfaces are involved, the host trying to get access knows about the technology change, and that's what makes this kind of path change different from other network state changes. Section 14 of [RFC2330] covers the possibility that a host has more than one attachment to the network, and also that checking the measurement path (route) stays valid for some length of time (in Sections 5 and 7 of [RFC2330]). Here we mash those two considerations together, on the assumption that changes may be more frequent and possibly have bigger consequences for performance metrics 😳
- Paths with links or nodes that offer time-slotted service opportunities are a whole challenge for measuring, especially when the service time period is noticeable 🧩
- Random/unbiased sampling is not possible beyond one such link in the path.
- That's why a segmented approach to end-to-end measurement is encouraged, as described in [RFC6049] for Network Characterization (as defined in [RFC6703]), so you can understand the full range of delay and delay variation on the path. On the other hand, if application performance estimation is the goal (also defined in [RFC6703]), then a stream with unbiased or known-bias properties [RFC3432] may be enough ✨
- Multi-modal delay variation means central statistics aren't the main character anymore, so other statistics have to step up 💜
Each of these topics gets a deep dive below 🫶
3.1. Test Packet Type-P
okay so we recommend adding two Type-P parameters to the list of factors that affect path performance measurements: packet length and payload type 🌸 Choosing these carefully can make measurement methodologies more continuous and repeatable when they're deployed in reactive paths 💖
3.1.1. Multiple Test Packet Lengths
so a lot of network characterization using IPPM metrics has relied on one single test packet length 🙃 When testing to assess application performance or an aggregate of traffic, benchmarking methods have used a range of fixed lengths, and they often mix fixed-size tests with a blend of sizes, called Internet Mix (IMIX), as described in [RFC6985] 🍓
Test packet length affects delay measurements, because the IPPM one-way delay metric [RFC2679] includes serialization time in its first-bit to last-bit timestamping requirements. But different sizes can have a bigger impact on link delay and link delay variation than serialization alone would explain 😭 This effect can be non-linear, and it can change the instantaneous network performance when a different size is used, or the performance of packets that come after the size change 🌈
Repeatability is a main measurement methodology goal, as stated in Section 6.2 of [RFC2330]. To take packet length off the list of possible measurement uncertainty factors, successive measurements must use identical traffic patterns 🔒 In practice, a combination of random payload and random start time can give representative results, as illustrated in [IRR] ✨
3.1.2. Test Packet Payload Content Optimization
the push for efficient network resource use has led to server-only or client-server lossless or lossy payload compression techniques getting deployed on some links or paths 🗜️ These optimizers try to compress high-volume traffic to cut down network load. Files get analyzed by application-layer parsers, and parts (like comments) might get dropped 👀 Even though they usually act on HTTP or JPEG files, compression might affect measurement packets too. Specifically, measurement packets qualify for efficient compression when they use standard plain-text payload. Also, transport-layer encryption will counteract network-based analysis and may reduce how much payload optimization gets adopted, but still 🔐
IPPM-conforming measurements should add packet payload content as a Type-P parameter, because it can help improve measurement determinism 💅 Some payloads are more susceptible to compression than others, but optimizers in the measurement path can be ruled out by using incompressible packet payload. That payload content could come from a pseudo-random sequence generator, or from part of a compressed file (e.g., a part of a ZIP compressed archive) 🎁
Optimization can go beyond one single data or measurement stream 🌍 Lots of client- or network-centric optimization technologies have been proposed or standardized so far, including Robust Header Compression (ROHC) and Voice over IP aggregation as presented, for instance, in [EEAW]. Where optimization is feasible and valuable, even more of these technologies may follow 🚀 As a general observation, the more concurrent flows an intermediate host handles and the longer the paths shared by flows are, the stronger the incentive for hosts to aggregate flows that belong to distinct sources. Measurements should consider this extra source of uncertainty with respect to repeatability 🧐 Aggregating flows in networking devices can, for instance, cause reciprocal timing and performance influence among those flows, and that can exceed typical reciprocal queueing effects by orders of magnitude 🤯
3.2. Packet History
recent packet history and instantaneous data rate both influence measurement results for reactive links that support on-demand capacity allocation 📈 Measurement uncertainty may go down when you know the measurement packet history and total host load 🧠 Also, small changes in history, e.g., because of lost packets along the path, can cause big performance variations 😱
For instance, delay in reactive 3G networks like High Speed Packet Access (HSPA) depends a lot on the test traffic data rate 🐢 The reactive resource allocation strategy in these networks affects the uplink direction in particular. Small changes in data rate can cause more than a 200% increase in delay, depending on the specific packet size 💀 A detailed theoretical and practical analysis of Radio Resource Control (RRC) link transitions, which can cause this behavior in Universal Mobile Terrestrial System (UMTS) networks, is presented, e.g., in [RRC] 📚
3.3. Access Technology Change
[RFC2330] discussed the scenario of multi-homed hosts 🏠 If hosts become aware of access technology changes (e.g., because of IP address changes or lower-layer information) and make that information available, measurement methodologies can use it to improve measurement representativeness and relevance 🎯
BUT today's access network technologies can present the same physical interface to the host 🫠 A host may or may not become aware when its access technology changes on such an interface. So measurements for paths that support on-demand capacity allocation are challenging, because it's hard to tell apart access technology changes (e.g., because of mobility) and reactive path behavior (e.g., because of data rate change) 🌀
3.4. Time-Slotted Randomness Cancellation
time-slotted operation of path entities (interfaces, routers, or links) in a network path is a particular challenge for measurements, especially when the time-slot period is substantial 🥲 The central observation, as an extension to Poisson stream sampling in [RFC2330], is that the first such time-slotted component cancels unbiased measurement stream sampling. In the worst case, time-slotted operation turns an unbiased, random measurement packet stream into a periodic packet stream 😵 Because these packets are heavily biased, they may interact with the periodic behavior of subsequent time-slotted network entities [TSRC] 🌀
Time-slotted randomness cancellation (TSRC) sources can be found in basically any system, network component, or path 🧚 Their impact on measurements is a matter of order of magnitude compared to the metric under observation. Examples of TSRC sources include, but are not limited to, system clock resolution, operating system ticks, time-slotted component or network operation, etc. The amount of measurement bias is determined by the particular measurement stream, the relative offset between allocated time slots in subsequent path entities, delay variation in these paths, and other sources of variation 🫧 Measurement results might change over time, depending on how accurately the sending host, the receiving host, and the time-slotted components in the measurement path are synchronized to each other and to global time ⏰ If path segments maintain flow state, flow parameter changes or flow reallocations can cause substantial variation in measurement results 💥
Practical measurements confirm that this kind of interference limits delay measurement variation to a subset of the theoretical value range 🎀 Measurement samples in these cases can pile up on artificial limits, which generates multi-modal distributions, as demonstrated in [IRR] 📊 In this context, the desirable measurement sample statistics help tell apart multi-modal delay distributions caused by reactive path behavior from the ones caused by time-slotted interference 🕵️♀️
Measurement methodology selection for time-slotted paths depends a lot on your viewpoint 👀 End-to-end metrics can give accurate results for short-term sessions with a low likelihood of flow state modifications 💫 So applications or services that want to approximate path performance over a short time interval (on the order of minutes) and expect stable path conditions should prefer end-to-end metrics ✅ Here, stable path conditions refer to any kind of global knowledge about the measurement path's flow state and flow parameters 🫶
However, if a long-term forecast of time-slotted path performance is the main measurement goal, a segmented approach that relies on measuring subpath metrics is preferred 🗺️ Regenerating unbiased measurement traffic at any hop can help reveal the true range of path performance for all path segments 🌈
4. Quality of Metrics and Methodologies ✨
okay so [RFC6808] suggests repeatability and continuity as properties you can use to judge measurement quality 🧐. Here's the tea: depending mainly on which measurement parameters you control, measuring the same network path with the same methodology might or might not give you repeatable results 🤷♀️. The hardest scenarios for controlling parameters are wireless, reactive, or time-slotted networks, which we already talked about earlier in this document 📶. This section gives an expanded definition of "repeatability" beyond the one in [RFC2330], and takes a closer look at "continuity" in [RFC2330] and how limited it really is 💅.
4.1. Revised Definition of Repeatability
[RFC2330] defines repeatability in a general way:
"A methodology for a metric should have the property that it is repeatable: if the methodology is used multiple times under identical conditions, the same measurements should result in the same measurements."
The challenge is to push this definition further so it becomes an objective, measurable criterion, one that doesn't depend on continuity (which we'll get to below) 🎯. Good news, bestie: other IPPM work already tackled this 🙌. In BCP 176 [RFC6576], the criteria of equivalent results was agreed on as the stand-in for interoperability when assessing metric RFCs for Standards Track advancement. The equivalence criteria were written as objective statistical requirements for comparison, both across the same implementations and across independent implementations, in the test plans for each RFC being evaluated ([RFC2679] in the test plan of [RFC6808]).
The tests in [RFC6808] rely on nearly identical conditions being present for analysis, and they accept that those conditions can't be exactly identical in the production network paths used 🛣️. The test plans allow some correction factors to be applied (some statistical tests are hyper-sensitive to differences in the mean of distributions), and they recognize the original findings of [RFC2330] about excess sample sizes 📊.
One way to look at the reliance on identical conditions is as a challenge: how few parameters and path conditions need to be controlled while still producing repeatable methods and measurements? 🤔
Although the test plan in [RFC6808] documented numerical criteria for equivalence, we cannot specify the exact numerical criteria for repeatability in general. 🙃 The process in the BCP [RFC6576] and the statistics in [RFC6808] have been used successfully, and the numerical criteria to declare a metric repeatable should be agreed by all interested parties prior to measurement.
So we revise the definition slightly, like this:
A methodology for a metric should have the property that it is repeatable: if the methodology is used multiple times under identical conditions, the methods should produce equivalent measurement results.
4.2. Continuity No Longer an Alternative Repeatability Criterion
In the original framework [RFC2330], continuity was introduced as a relaxed way to judge repeatability. Section 6.2 of [RFC2330] put it like this:
"...a methodology for a given metric exhibits continuity if, for small variations in conditions, it results in small variations in the resulting measurements."
Sure, there are conditions where a metric may show continuity 👍. But there are plenty of others where this criterion fails, for both user traffic and active measurement traffic 😬. Take link fragmentation: delay increases non-linearly when you push packet size just past the limit of a single fragment. An active measurement packet would see that same delay jump once it exceeds the fragment size 📦.
The Bulk Transfer Capacity (BTC) [RFC3148] gives another example in Section 1, bottom of page 2:
There is also evidence that most TCP implementations exhibit non- linear performance over some portion of their operating region. It is possible to construct simple simulation examples where incremental improvements to a path (such as raising the link data rate) results in lower overall TCP throughput (or BTC) [Mat98].
And clearly, the time-slotted network elements described in Section 3.4 of this document also qualify as a new exception to the ideal of continuity ⏰. So yeah, we're officially done treating it as a reliable yardstick 💅.
Therefore, we deprecate continuity as an alternate criterion on metrics and prefer the more exact evaluation of repeatability instead.
4.3. Metrics Should Be Actionable
The IP Performance Metrics Framework [RFC2330] lists usefulness as a metric criterion:
"...The metrics must be useful to users and providers in understanding the performance they experience or provide...".
When measurements are part of a maintenance process, evaluating results for a path under observation can flag potential performance problems "somewhere" on that path 🕵️♀️. So anomaly detection is an important first step, and for many metrics it already satisfies the usefulness criterion ✅.
This idea of usefulness can be extended into what we call the "actionable" criterion. Quick note: this is not the term from law ⚖️, so no need to panic.
Maintenance is all about isolating the root cause of reported anomalies down to a specific subpath, link, or host, and metrics should support this second step too 🔍. Detecting a path anomaly might come out of an ongoing monitoring process, but cause isolation is specific, directed, on-demand measurement of components and subpaths. Metrics have to support users in that directed search, which makes them actionable:
Metrics must enable users and operators to understand path performance and SHOULD help to direct corrective actions when warranted, based on the measurement results.
Usefulness and actionable properties also apply to methodologies and measurements, not just to metrics 🧩.
4.4. It May Not Be Possible To Be Conservative
[RFC2330] uses the term "conservative" for measurement methodologies where:
"... the act of measurement does not modify, or only slightly modifies, the value of the performance metric the methodology attempts to measure."
Here's the thing: this definition of "conservative" in the sense of [RFC2330] depends a lot on the measurement path's technology and characteristics 🛠️. Specifically, when it's deployed on reactive paths, subpaths, links, or hosts that conform to the definition in Section 1.1 of this document, measurement packets can trigger capacity (re)allocations 🌀. And small variations in the measurement flow can make other users on the same path see big swings in their own measurement results 😵. So:
It is not always possible for the method to be conservative.
4.5. Spatial and Temporal Composition Support Unbiased Sampling
The concepts of temporal and spatial composition of metrics from Section 9 of [RFC2330] were extended in [RFC5835]. [RFC5835] defines several new types of metrics, including Spatial Composition, Temporal Aggregation, and Spatial Aggregation 🧠. So far, only the Spatial Composition metrics have been standardized [RFC6049], which gives you the ability to estimate the performance of a complete path from subpath metrics 🧮. Spatial Composition lines up with the finding in [TSRC] that unbiased sampling isn't possible beyond the first time-slotted link within a measurement path ⏱️.
In cases where unbiased measurement for all segments of a path is not feasible due to the presence of a time-slotted link, restoring randomness of measurement samples when necessary is recommended as presented in [TSRC], in combination with Spatial Composition [RFC6049].
4.6. When to Truncate the Poisson Sampling Distribution
Section 11.1.1 of [RFC2330] describes Poisson sampling, where the inter-packet send times follow a Poisson distribution 🎲. The catch: a path element with reactive behavior that's sensitive to flow inactivity could change state if a random inter-packet time gets too long 😱.
It is recommended to truncate the tail of Poisson distribution when needed to avoid reactive element state changes.
Tail truncation has been used without issue to make sure minimum sample sizes can be reached in a fixed-test interval 🎯.
5. Conclusions 🎀
Safeguarding repeatability as a key property of measurement methodologies is super challenging, and sometimes impossible, on reactive paths 🥲. Measurements on paths with demand-driven allocation strategies must use a prototypical application packet stream to infer a specific application's performance. Repeating measurements with unbiased network and flow states (for example, by rebooting measurement hosts) can help avoid interference with periodic network behavior, and randomness is a mandatory feature for avoiding correlation with network timing 🎰.
Inferring path performance from one measurement session or packet stream and applying it to other sessions or streams with different characteristics is generally discouraged on reactive paths. Why? Because there's a huge set of global parameters influencing instantaneous path performance 🌍.
6. Security Considerations 🔐
The security considerations that apply to any active measurement of live paths are relevant here as well. See [RFC4656] and [RFC5357].
When considering the privacy of those involved in measurement, or of those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using the active techniques within this scope of work 🕶️. Passive observation of user traffic for measurement purposes raises many privacy issues. We refer the reader to the privacy considerations described in the Large Scale Measurement of Broadband Performance (LMAP) Framework [LMAP], which covers both active and passive techniques.
7. Acknowledgements 🫶
The authors thank Rudiger Geib, Matt Mathis, Konstantinos Pentikousis, and Robert Sparks for their helpful comments on this memo. They also thank Alissa Cooper and Kathleen Moriarty for suggesting ways to "update the update" for heightened privacy awareness and its consequences, and Ann Cerveny for her editorial review and comments, which helped improve readability overall 💜.
8. References 📚
8.1. Normative References 📚
okay so these are the must-read docs 💅 the ones this spec leans on for real, and the BCP 14 key words get their meaning from RFC 2119 🫶
[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.[RFC3432]Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002.[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.[RFC5835]Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010.[RFC6049]Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, January 2011.[RFC6576]Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, March 2012.[RFC6703]Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, August 2012.
8.2. Informative References 🦋
these ones are the extra reading 🤓 super useful for the backstory, but the spec doesn't need them to work, so no pressure bestie 🌸
[EEAW]Pentikousis, K., Piri, E., Pinola, J., Fitzek, F., Nissilae, T., and I. Harjula, "Empirical Evaluation of VoIP Aggregation over a Fixed WiMAX Testbed", Proceedings of the 4th International Conference on Testbeds and research infrastructures for the development of networks and communities (TridentCom '08), Article No. 19, March 2008,<http://dl.acm.org/citation.cfm?id=139059>.[IBD]Fabini, J., Karner, W., Wallentin, L., and T. Baumgartner, "The Illusion of Being Deterministic - Application-Level Considerations on Delay in 3G HSPA Networks", Lecture Notes in Computer Science, Volume 5550, pp. 301-312 , May 2009.[IRR]Fabini, J., Wallentin, L., and P. Reichl, "The Importance of Being Really Random: Methodological Aspects of IP-Layer 2G and 3G Network Delay Assessment", ICC'09 Proceedings of the 2009 IEEE International Conference on Communications, doi: 10.1109/ICC.2009.5199514, June 2009.[LMAP]Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A framework for large-scale measurement platforms (LMAP)", Work in Progress, June 2014.[Mat98]Mathis, M., "Empirical Bulk Transfer Capacity", IP Performance Metrics Working Group report in Proceedings of the Forty-Third Internet Engineering Task Force, Orlando, FL, December 1998,<http://www.ietf.org/proceedings/43/slides/ippm-mathis-98dec.pdf>.[RFC3148]Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001.[RFC6808]Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track", RFC 6808, December 2012.[RFC6985]Morton, A., "IMIX Genome: Specification of Variable Packet Sizes for Additional Testing", RFC 6985, July 2013.[RRC]Peraelae, P., Barbuzzi, A., Boggia, G., and K. Pentikousis, "Theory and Practice of RRC State Transitions in UMTS Networks", IEEE Globecom 2009 Workshops, doi: 10.1109/GLOCOMW.2009.5360763, November 2009.[TSRC]Fabini, J. and M. Abmayer, "Delay Measurement Methodology Revisited: Time-slotted Randomness Cancellation", IEEE Transactions on Instrumentation and Measurement, Volume 62, Issue 10, doi:10.1109/TIM.2013.2263914, October 2013.
Authors' Addresses 💖
meet the brains behind it 🧚 two super smart people who clearly know their stuff 🔥
Joachim Fabini
Vienna University of Technology
Gusshausstrasse 25/E389
Vienna 1040
Austria
Phone: +43 1 58801 38813
Fax: +43 1 58801 38898
EMail: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
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/📦 where this page comes from
- ietf: rfc7312 2014-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms