RFC 6534

Loss Episode Metrics for IP Performance Metrics (IPPM)

📅 published May 2012, from ietf

Loss Episode Metrics for IP Performance Metrics (IPPM) 🦋✨

Request for Comments: 6534 💖 Category: Standards Track 🎀 (it's an Internet Standards Track document, bestie!) ISSN: 2070-1721 🌈 Date: May 2012 🍓 Stream: Internet Engineering Task Force (IETF) 👑

Authors:

  • N. Duffield, AT&T Labs-Research 💅
  • A. Morton, AT&T Labs 🧚
  • J. Sommers, Colgate University 🫶

The title block doesn't list anything this RFC obsoletes or updates, so it's standing on its own, no cap 💜.

Abstract 🌸

Okay so the IETF already has a one-way packet loss metric that measures the loss rate on Poisson and Periodic probe streams between two hosts 📡. But here's the tea: apps don't just care about the average amount of loss. They care about how those lost packets are clumped together into loss episodes (aka maximal sets of consecutively lost probe packets) 🥺. This doc defines one-way packet loss episode metrics, specifically the frequency and average duration of loss episodes, plus a probing methodology for measuring them under the loss episode metrics 💅✨.

Status of This Memo 🧚

This is an Internet Standards Track document. 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, has had 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 📚.

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/rfc6534 🔗.

Copyright (c) 2012 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) in effect on the date of publication of this document. Please read these carefully, because they spell out your rights and restrictions with respect to 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 person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of that material outside the IETF Standards Process. Without getting an adequate license from the person(s) controlling the copyright in those materials, 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, except to format it for publication as an RFC or to translate it into languages other than English 🙈.

Table of Contents 🍓

   1. Introduction ....................................................4
      1.1. Background and Motivation ..................................4
           1.1.1. Requirements Language ...............................5
      1.2. Loss Episode Metrics and Bi-Packet Probes ..................5
      1.3. Outline and Contents .......................................6
   2. Singleton Definition for Type-P-One-way Bi-Packet Loss ..........7
      2.1. Metric Name ................................................7
      2.2. Metric Parameters ..........................................7
      2.3. Metric Units ...............................................7
      2.4. Metric Definition ..........................................7
      2.5. Discussion .................................................8
      2.6. Methodologies ..............................................8
      2.7. Errors and Uncertainties ...................................8
      2.8. Reporting the Metric .......................................8
   3. General Definition of Samples for
      Type-P-One-way-Bi-Packet-Loss ...................................8
      3.1. Metric Name ................................................9
      3.2. Metric Parameters ..........................................9
      3.3. Metric Units ...............................................9
      3.4. Metric Definition ..........................................9
      3.5. Discussion .................................................9
      3.6. Methodologies .............................................10
      3.7. Errors and Uncertainties ..................................10
      3.8. Reporting the Metric ......................................10
   4. An Active Probing Methodology for Bi-Packet Loss ...............10
      4.1. Metric Name ...............................................10
      4.2. Metric Parameters .........................................10
      4.3. Metric Units ..............................................11
      4.4. Metric Definition .........................................11
      4.5. Discussion ................................................11
      4.6. Methodologies .............................................11
      4.7. Errors and Uncertainties ..................................12
      4.8. Reporting the Metric ......................................12
   5. Loss Episode Proto-Metrics .....................................12
      5.1. Loss-Pair-Counts ..........................................13
      5.2. Bi-Packet-Loss-Ratio ......................................13
      5.3. Bi-Packet-Loss-Episode-Duration-Number ....................13
      5.4. Bi-Packet-Loss-Episode-Frequency-Number ...................13
   6. Loss Episode Metrics Derived from Bi-Packet Loss Probing .......14
      6.1. Geometric Stream: Loss Ratio ..............................14
           6.1.1. Metric Name ........................................14
           6.1.2. Metric Parameters ..................................14
           6.1.3. Metric Units .......................................15
           6.1.4. Metric Definition ..................................15
           6.1.5. Discussion .........................................15
           6.1.6. Methodologies ......................................15
           6.1.7. Errors and Uncertainties ...........................15
           6.1.8. Reporting the Metric ...............................15
      6.2. Geometric Stream: Loss Episode Duration ...................16
           6.2.1. Metric Name ........................................16
           6.2.2. Metric Parameters ..................................16
           6.2.3. Metric Units .......................................16
           6.2.4. Metric Definition ..................................16
           6.2.5. Discussion .........................................16
           6.2.6. Methodologies ......................................16
           6.2.7. Errors and Uncertainties ...........................17
           6.2.8. Reporting the Metric ...............................17
      6.3. Geometric Stream: Loss Episode Frequency ..................17
           6.3.1. Metric Name ........................................17
           6.3.2. Metric Parameters ..................................17
           6.3.3. Metric Units .......................................17
           6.3.4. Metric Definition ..................................18
           6.3.5. Discussion .........................................18
           6.3.6. Methodologies ......................................18
           6.3.7. Errors and Uncertainties ...........................18
           6.3.8. Reporting the Metric ...............................18
   7. Applicability of Loss Episode Metrics ..........................18
      7.1. Relation to Gilbert Model .................................18
   8. Security Considerations ........................................19
   9. References .....................................................20
      9.1. Normative References ......................................20
      9.2. Informative References ....................................20

1. Introduction ✨

1.1. Background and Motivation 🌷

Packet loss on the Internet is a whole complex situation 😭. Traffic is bursty, congestion is messy, and both end users and applications influence it, plus how transport protocols like TCP operate. For all those reasons, the simplest model of packet loss, the single parameter Bernoulli (independent) loss model, just doesn't capture what packet loss looks like over periods of time 🙈. Similarly, a single loss metric, the average packet loss ratio over some period of time, arising e.g. from a stream of Poisson probes as in [RFC2680], isn't enough to tell you how packet loss affects traffic in general 💀.

Moving past single parameter loss models, there are Markovian and Markov-modulated loss models with transitions between a good and a bad state, each with its own loss rate. Gilbert [Gilbert] proposed these, and Elliot [Elliot] generalized them 🧠. In principle, Markovian models can be built over state spaces that involve patterns of loss of any desired number of packets. But making the state space bigger makes these models cumbersome, both for parameter estimation (accuracy goes down) and for prediction in practice (because of computational complexity and sensitivity to parameter inaccuracy) 😩. Also, the relevance and importance of particular models can change over time, e.g. when new applications and services show up. So we're drawn to empirical metrics that don't depend on a particular model to be interpreted 🦋.

An empirical measure of packet loss complexity is the index of dispersion of counts (IDC). For each t >0, it's the ratio v(t) / a(t), where v(t) is the variance and a(t) is the average of the number of losses over successive measurement windows of duration t. But fully characterizing packet loss over time means specifying the IDC for each window size t>0 📊.

In the standards arena, loss pattern sample metrics are defined in [RFC3357]. Following the Gilbert-Elliot model, burst metrics specific to Voice over IP (VoIP), which characterize complete episodes of lost, transmitted, and discarded packets, are defined in [RFC3611] 🎧.

All of this motivates empirical metrics of one-way packet loss. These give the simplest generalization of [RFC2680], which is widely adopted but only defines a single loss-to-total ratio metric 🍓. The metrics defined here capture deviations from independent packet loss in a robust, model-independent way. The document also defines efficient measurement methodologies for these metrics 🌈✨.

1.1.1. 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] 🎀.

1.2. Loss Episode Metrics and Bi-Packet Probes 🦋

okay so when a packet stream loses stuff, the losses don't usually happen one at a time 🙈 they clump together into loss episodes, which are just the longest runs of packets that get lost back-to-back. ✨ This memo is all about one-way loss episode metrics: how often they happen and how long they last on average. The average loss ratio can be worked out from these, but they go way deeper and tell you what the loss patterns look like inside the probe stream 💅 That matters because apps don't only care about the overall loss rate. They care about when the losses land. Like, MPEG video might really feel it if an I-frame in a group of pictures gets hit, but more losses inside an episode that's short enough? Not making it worse, the damage is already done 😭

The loss episode metrics here have some seriously useful properties:

  1. the metrics are empirical and do not depend on an underlying model; e.g., the loss process is not assumed to be Markovian. Still, the metrics of this memo can be related to the special case of the Gilbert Model parameters; see Section 7. 🌸
  2. the metric units can be compared directly with what applications or users need or can tolerate for network loss performance, in terms of how often loss episodes happen and how long they last, plus the usual packet loss ratio. That ratio can be recovered from the loss episode metrics by dividing the average loss episode duration by the loss episode frequency. 🎀
  3. the metrics add the smallest possible amount of complexity on top of, and in the spirit of, the IP Performance Metrics (IPPM) average packet loss ratio metrics [RFC2680]. You go from one metric (average packet loss ratio) to a pair (loss episode frequency and average loss episode duration). 💜

The document also describes the probing method you use to measure loss episode metrics. You send probe packets in pairs, where the two packets in each pair have a fixed separation, and the gap between pairs is a geometrically distributed number multiplied by that same separation. Honestly, you can think of it as a generalization of Poisson probing where the probes are pairs instead of single packets as in [RFC2680], and also of the geometric probing described in [RFC2330]. Don't mix it up with back-to-back packet pairs, though, where the change in separation as they cross a link is used to probe bandwidth 🙅‍♀️ In this document, the separation between the packets in a pair is the temporal resolution at which different loss episodes get told apart. The method doesn't measure episodes of loss among consecutive background packets on the measured path. The big win here is efficiency: it estimates the average length of loss episodes without directly measuring the full episodes. Instead, that info is encoded in the observed relative frequencies of the four possible outcomes from losing or successfully delivering each of the two packets in the probe pairs. This is different from the approach of [RFC3611], which reports directly measured episodes. ✨

The metrics defined in this memo are "derived metrics", according to Section 6.1 of [RFC2330] (the IPPM framework). They're based on the singleton loss metric defined in Section 2 of [RFC2680] . 🧚

1.3. Outline and Contents 🗂️

  • Section 2 defines the fundamental singleton metric for the possible outcomes of a probe pair: Type-P-One-way-Bi-Packet-Loss. 💖
  • Section 3 defines sample sets of this metric derived from a general probe stream: Type-P-One-way-Bi-Packet-Loss-Stream. 🌈
  • Section 4 defines the prime example of the Bi-Packet-Loss-Stream metrics, specifically Type-P-One-way-Bi-Packet-Loss-Geometric-Stream, which comes from the geometric stream of packet-pair probes that was described informally in Section 1. 🍓
  • Section 5 defines loss episode proto-metrics that summarize the outcomes from a stream metric as an intermediate step toward the loss episode metrics. They don't generally need to be reported. 🫶
  • Section 6 defines the final loss episode metrics that are the focus of this memo, the new metrics: ⭐
    • Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Duration, the average duration, in seconds, of a loss episode.
    • Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Frequency, the average frequency, per second, at which loss episodes start.
    • Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Ratio, which is the average packet loss ratio metric arising from the geometric stream probing methodology.
  • Section 7 details applications and relations to existing loss models. 👑

2. Singleton Definition for Type-P-One-way Bi-Packet Loss 🎀

2.1. Metric Name

Type-P-One-way-Bi-Packet-Loss

2.2. Metric Parameters

  • Src, the IP address of a source host 💅
  • Dst, the IP address of a destination host 💅
  • T1, a sending time of the first packet 🕰️
  • T2, a sending time of the second packet, with T2>T1 ⏱️
  • F, a selection function defining unambiguously the two packets from the stream selected for the metric 🎯
  • P, the specification of the packet type, over and above the source and destination addresses 📦

2.3. Metric Units

A Loss Pair is a pair (l1, l2) where each of l1 and l2 is a binary value, 0 or 1. A 0 means the packet was transmitted successfully, and a 1 means it was lost. 🫧

The metric unit of Type-P-One-way-Bi-Packet-Loss is a Loss Pair. ✨

2.4. Metric Definition

  1. "The Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, T1, T2, F, P) is (1,1)" means that Src sent the first bit of a Type-P packet to Dst at wire-time T1, and the first bit of a Type-P packet to Dst at wire-time T2>T1, and that neither packet was received at Dst. 💔
  2. "The Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, T1, T2, F, P) is (1,0)" means that Src sent the first bit of a Type-P packet to Dst at wire-time T1, and the first bit of a Type-P packet to Dst at wire-time T2>T1, and that the first packet was not received at Dst, and the second packet was received at Dst. 🌤️
  3. "The Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, T1, T2, F, P) is (0,1)" means that Src sent the first bit of a Type-P packet to Dst at wire-time T1, and the first bit of a Type-P packet to Dst at wire-time T2>T1, and that the first packet was received at Dst, and the second packet was not received at Dst. 🌥️
  4. "The Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, T1, T2, F, P) is (0,0)" means that Src sent the first bit of a Type-P packet to Dst at wire-time T1, and the first bit of a Type-P packet to Dst at wire-time T2>T1, and that both packets were received at Dst. 🥳

2.5. Discussion

The whole point of the selection function is to pin down exactly which packets get used for measurement. 🔍 The idea is taken from Section 2.5 of [RFC3393], where examples get discussed. 📚

2.6. Methodologies

The methodologies for the Type-P-One-way-Packet-Loss metric in Section 2.6 of [RFC2680] are pretty similar for the Type-P-One-way-Bi-Packet-Loss metric described above. Specifically, the methodologies described in RFC 2680 apply to both packets of the pair. 🤝

2.7. Errors and Uncertainties

The sources of error listed for the Type-P-One-way-Packet-Loss metric in Section 2.7 of [RFC2680] apply to each packet of the pair for the Type-P-One-way-Bi-Packet-Loss metric. ⚠️

2.8. Reporting the Metric

Refer to Section 2.8 of [RFC2680]. 📝

3. General Definition of Samples for Type-P-One-way-Bi-Packet-Loss 🧁

Okay, so now that we've got the singleton metric, we can define examples of samples made of singletons. The basic idea goes like this: first you pick a set of times T1 < T2 <...<Tn, and each one acts as the first time of a packet pair for a single Type-P-One-way-Bi-Packet-Loss measurement. That gives you a set of n metric values of Type-P-One-way-Bi-Packet-Loss. 🍭

3.1. Metric Name

Type-P-One-way-Bi-Packet-Loss-Stream

3.2. Metric Parameters

  • Src, the IP address of a source host 💅
  • Dst, the IP address of a destination host 💅
  • (T11,T12), (T21,T22)....,(Tn1,Tn2) a set of n sending times for packet pairs, with T11 < T12 <= T21 < T22 <=...<= Tn1 < Tn2 🕰️
  • F, a selection function defining unambiguously the two packets from the stream selected for the metric 🎯
  • P, the specification of the packet type, over and above the source and destination address 📦

3.3. Metric Units

A set L1,L2,...,Ln of Loss Pairs. 🫧

3.4. Metric Definition

Each Loss Pair Li for i = 1,....n is the Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, Ti1, Ti2, Fi, P), where Fi is the restriction of the selection function F to the packet pair at time Ti1, Ti2. 🧩

3.5. Discussion

The metric definition of Type-P-One-way-Bi-Packet-Loss-Stream is general enough to cover packets sampled from a stream that already exists. 🌊 That's handy when there's a general purpose measurement stream set up between two hosts and you want to pull out a substream from it for loss episode measurement. Packet pairs picked as bi-packet loss probes don't have to be consecutive within such a stream. In the next section, we narrow this down to describe a purpose built packet stream for loss episode measurement more concretely. 🎁

3.6. Methodologies

The methodologies for the Type-P-One-way-Packet-Loss metric in Section 2.6 of [RFC2680] are similar for the Type-P-One-way-Bi-Packet-Loss-Stream metric described above. In particular, the methodologies described in RFC 2680 apply to both packets of each pair. 🤍

3.7. Errors and Uncertainties

The sources of error for the Type-P-One-way-Packet-Loss metric in Section 2.7 of [RFC2680] apply to each packet of each pair for the Type-P-One-way-Bi-Packet-Loss-Stream metric. 🙃

3.8. Reporting the Metric

Refer to Section 2.8 of [RFC2680]. 📝

4. An Active Probing Methodology for Bi-Packet Loss 🧚‍♀️

This section takes the previous one and makes it specific to an active probing method. The basic idea is as follows: we set up a sequence of evenly spaced times T1 < T2 < ... < Tn. Each time Ti could be the first packet time for a packet pair measurement. At each time, we make an independent random decision about whether to start one of these measurements, so the number of intervals between successive times where a pair gets started follows a geometric distribution. 🎲 We also say the spacing between successive times Ti is the same as the spacing between packets in a given pair. So if pairs happen to launch at successive times Ti and T(i+1), the second packet of the first pair actually gets used as the first packet of the second pair. 🔁

4.1. Metric Name

Type-P-One-way-Bi-Packet-Loss-Geometric-Stream 🌟

4.2. Metric Parameters ✨

okay so the metric parameters are the knobs you set before you run the test, and bestie, there are a lot of them 🎀

  • Src, the IP address of a source host 🌸
  • Dst, the IP address of a destination host 💖
  • T0, the randomly selected starting time [RFC3432] for periodic launch opportunities 🎲
  • d, the time spacing between potential launch times, Ti and T(i+1) ⏰
  • n, a count of potential measurement instants 🔢
  • q, a launch probability 🎰
  • F, a selection function defining unambiguously the two packets from the stream selected for the metric 🫶
  • P, the specification of the packet type, over and above the source and destination address 📦

4.3. Metric Units 💅

the output is a set of Loss Pairs, L1, L2, ..., Lm, for some m <= n. so m can never be bigger than n. make sense? 🧚

4.4. Metric Definition 🌈

okay this part is giving math, so pay attention 🤓

for each i = 0, 1, ..., n-1 we form the potential measurement time Ti = T0 + i*d. with probability q, a packet pair measurement is launched at Ti, which gives you a Type-P-One-way-Bi-Packet-Loss with parameters (Src, Dst, Ti, T(i+1), Fi, P), where Fi is the restriction of the selection function F to the packet pair at times Ti, T(i+1). then L1, L2,...Lm are the resulting Loss Pairs. m can be less than n since not all times Ti have an associated measurement ✨

4.5. Discussion 🦋

ngl this part is so satisfying. the geometric stream version is basically the regular stream version, as long as you give it a proper statistical definition of the selection function F. 💜

also, the number m of Loss Pairs can be less than the number of potential measurement instants, because if the launch probability q is strictly less than 1, not every instant is going to actually send a probe. some just don't launch, and that's totally normal 😭

4.6. Methodologies 🍓

the methodologies come from:

  • the specific time T0, which all the successive Ti follow from, and
  • the specific time spacing, and
  • the methodologies discussion given above for the singleton Type-P-One-way-Bi-Packet-Loss metric.

choosing a good time spacing (like one that matches the expected characteristics of loss episodes) is outside the scope of this document. that's a whole other conversation, bestie 🙈

and like with any active measurement methodology, you have to handle out-of-order arrival of packets. see also Section 3.6. of [RFC2680] 📬

4.7. Errors and Uncertainties 💀

on top of the errors and uncertainties for the singleton Type-P-One-way-Bi-Packet-Loss metric, there's a big one for Bi-Packet Loss: resource limits on the host sending the packets. the choice of T0, the time spacing, and the launch probability together make a schedule for sending packets. if the sending host doesn't have enough CPU, it might not be able to send packets on schedule 😩

the time spacing really matters here. picture a 100 microsecond spacing versus a 100 millisecond spacing. the host CPU has way more trouble keeping up with the tiny one 🔥

for other considerations, refer to Section 3.7 of [RFC2680] 🫶

4.8. Reporting the Metric 🎀

refer to Section 3.8. of [RFC2680] ✨

5. Loss Episode Proto-Metrics 👑

this section is about four generic proto-metric quantities that work on any set of Loss Pairs. they are the Loss-Pair-Counts, Bi-Packet-Loss-Ratio, Bi-Packet-Loss-Episode-Duration-Number, and Bi-Packet-Loss-Episode-Frequency-Number.

you can build specific loss episode metrics out of these when their inputs are sets of Loss Pairs generated by the Type-P-One-way-Bi-Packet-Loss-Stream and the Type-P-One-way-Bi-Packet-Loss-Geometric-Stream. the second one is the one described in Section 4 🧚

the big thing to know is that nobody is really expected to report these proto-metrics themselves. they're intermediate steps that get you to the final metrics in Section 6 below, and implementations could roll them up into metrics. 💅

also, these metrics report loss episode durations and frequencies in terms of packet counts, since they don't depend on the actual time between probe packets. the final metrics in Section 6 bring in timescales and give you durations in seconds and frequencies per second ⏰

5.1. Loss-Pair-Counts 🌸

Loss-Pair-Counts are the absolute frequencies of the four types of Loss Pair outcome in a sample. more precisely, the Loss-Pair-Counts for a set of Loss Pairs L1,,,,Ln are the numbers N(i,j) of those Loss Pairs that take each possible value (i,j) in the set ((0,0), (0,1), (1,0), (1,1)). 🍓

5.2. Bi-Packet-Loss-Ratio 💖

the Bi-Packet-Loss-Ratio for a set of n Loss Pairs L1,,,,Ln is defined using the Loss-Pair-Counts like this:

(N(1,0) + N(1,1))/n

note that this is formally equivalent to the loss metric Type-P-One-way-Packet-Loss-Average from [RFC2680], since it averages single packet losses. it's giving consistency 🦋

5.3. Bi-Packet-Loss-Episode-Duration-Number 🌈

the Bi-Packet-Loss-Episode-Duration-Number for a set of n Loss Pairs L1,,,,Ln is defined using the Loss-Pair-Counts in these cases:

  • (2*N(1,1) + N(0,1) + N(1,0)) / (N(0,1) + N(1,0)) if N(0,1) + N(1,0) > 0
  • 0 if N(0,1) + N(1,0) + N(1,1) = 0 (no probe packets lost)
  • Undefined if N(0,1) + N(1,0) + N(0,0) = 0 (all probe packets lost)

note that N(0,1) + N(1,0) is zero if there are no transitions between loss and no-loss outcomes. 🙃

5.4. Bi-Packet-Loss-Episode-Frequency-Number 🔥

the Bi-Packet-Loss-Episode-Frequency-Number for a set of n Loss Pairs L1,,,,Ln is defined with the Loss-Pair-Counts as Bi-Packet-Loss-Ratio / Bi-Packet-Loss-Episode-Duration-Number, when that can be defined. specifically, it goes like this:

  • (N(1,0) + N(1,1)) * (N(0,1) + N(1,0)) / (2*N(1,1) + N(0,1) + N(1,0) ) / n if N(0,1) + N(1,0) > 0
  • 0 if N(0,1) + N(1,0) + N(1,1) = 0 (no probe packets lost)
  • 1 if N(0,1) + N(1,0) + N(0,0) = 0 (all probe packets lost)

6. Loss Episode Metrics Derived from Bi-Packet Loss Probing 🧚

now for the main event 🎀 these metrics for how often and how long loss episodes happen are defined as functions of the set of n Loss Pairs L1,....,Ln. a loss episode is a maximal set of successive lost packets, but the loss episode metrics aren't defined directly from the sequential patterns of loss that Loss Pairs show. why? because samples (including the Type-P-One-way-Bi-Packet-Loss-Geometric-Stream) usually don't report every lost packet in each episode. so instead, the metrics are defined as functions of the sample's Loss-Pair-Counts. 💅

here's the reasoning. take an idealized Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample where the launch probability q =1. it's shown in [SBDR08] that the average number of packets in a loss episode of this ideal sample is exactly the Bi-Packet-Loss-Episode-Duration derived from its set of Loss Pairs. and this computation doesn't care where the lost packet is in the sequence of probes. iconic 👑

a general Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample with launch probability q < 1 independently samples each Loss Pair of an idealized sample with probability q. on average, the Loss-Pair-Counts (if you normalize them by the total number of pairs) come out the same as in the idealized sample. so the loss episode metrics in the general case are estimators of the idealized case. the statistical properties of this estimation, including a derivation of the estimation variance, are in [SBDR08] 🦋

6.1. Geometric Stream: Loss Ratio 🌸

6.1.1. Metric Name

Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Ratio

6.1.2. Metric Parameters

  • Src, the IP address of a source host 🌸
  • Dst, the IP address of a destination host 💖
  • T0, the randomly selected starting time [RFC3432] for periodic launch opportunities 🎲
  • d, the time spacing between potential launch times, Ti and T(i+1) ⏰
  • n, a count of potential measurement instants 🔢
  • q, a launch probability 🎰
  • F, a selection function defining unambiguously the two packets from the stream selected for the metric 🫶
  • P, the specification of the packet type, over and above the source and destination address 📦

6.1.3. Metric Units

a decimal number in the interval [0,1] 💜

6.1.4. Metric Definition

the result you get by computing the Bi-Packet-Loss-Ratio over a Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample with the metric parameters 🍓

6.1.5. Discussion

Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Ratio estimates the fraction of packets lost from the geometric stream of Bi-Packet probes. it's literally the loss fraction, bestie ✨

6.1.6. Methodologies

refer to Section 4.6.

6.1.7. Errors and Uncertainties

because Type-P-One-way-Bi-Packet-Loss-Geometric-Stream is sampled in general (when the launch probability q <1), the metrics in this section can be treated as statistical estimators of the matching idealized version, where q = 1. the estimation variance for Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Loss-Ratio is described in [SBDR08].

for other issues, refer to Section 4.7 🫶

6.1.8. Reporting the Metric

refer to Section 4.8.

6.2. Geometric Stream: Loss Episode Duration 🎀

6.2.1. Metric Name

Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Duration

6.2.2. Metric Parameters

  • Src, the IP address of a source host 🌸
  • Dst, the IP address of a destination host 💖
  • T0, the randomly selected starting time [RFC3432] for periodic launch opportunities 🎲
  • d, the time spacing between potential launch times, Ti and T(i+1) ⏰
  • n, a count of potential measurement instants 🔢
  • q, a launch probability 🎰
  • F, a selection function defining unambiguously the two packets from the stream selected for the metric 🫶
  • P, the specification of the packet type, over and above the source and destination address 📦

6.2.3. Metric Units

a non-negative number of seconds ⏰

6.2.4. Metric Definition

the result you get by computing the Bi-Packet-Loss-Episode-Duration-Number over a Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample with the metric parameters, and then multiplying that result by the launch spacing parameter d 🧮

6.2.5. Discussion

Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Duration estimates the average duration of a loss episode, measured in seconds. to get the duration measured in packets, you divide the metric value by the packet launch spacing parameter d 🌈

6.2.6. Methodologies

refer to Section 4.6.

6.2.7. Errors and Uncertainties

because Type-P-One-way-Bi-Packet-Loss-Geometric-Stream is sampled in general (when the launch probability q <1), the metrics in this section can be treated as statistical estimators of the matching idealized version, where q = 1. the estimation variance for Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Duration is described in [SBDR08].

for other issues, refer to Section 4.7 🫶

6.2.8. Reporting the Metric

refer to Section 4.8.

6.3. Geometric Stream: Loss Episode Frequency 🦋

6.3.1. Metric Name

Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Frequency

6.3.2. Metric Parameters ✨

Okay bestie, here are the knobs you get to turn 🎛️:

  • Src, the IP address of a source host
  • Dst, the IP address of a destination host
  • T0, the randomly selected starting time [RFC3432] for periodic launch opportunities
  • d, the time spacing between potential launch times, Ti and T(i+1)
  • n, a count of potential measurement instants
  • q, a launch probability
  • F, a selection function defining unambiguously the two packets from the stream selected for the metric
  • P, the specification of the packet type, over and above the source and destination address

6.3.3. Metric Units 💖

The unit is a positive number 🔢

6.3.4. Metric Definition 🧁

So the value is what you get from running the Bi-Packet-Loss-Episode-Frequency-Number over a Type-P-One-way-Bi-Packet-Loss-Geometric-Stream sample, using your metric parameters, and then dividing that result by the launch spacing parameter d. Simple, but make sure you divide 🙈

6.3.5. Discussion 🦋

Okay, this one is the vibe check. Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Frequency estimates the average frequency per unit time at which loss episodes start (or finish) ⏱️ If you want the frequency relative to the count of potential probe launches instead, you multiply the metric value by the packet launch spacing parameter d. That's the whole glow-up 🌸

6.3.6. Methodologies 💅

Refer to Section 4.6.

6.3.7. Errors and Uncertainties 🌧️

Here's the tea ☕ Since Type-P-One-way-Bi-Packet-Loss-Geometric-Stream is sampled in general (when the launch probability q <1), the metrics in this section are basically statistical estimators of the idealized version where q = 1. Estimation variance for Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Frequency is covered in [SBDR08], so go read that if you're curious 🤓

For other issues, refer to Section 4.7.

6.3.8. Reporting the Metric 📣

Refer to Section 4.8.

7. Applicability of Loss Episode Metrics 🌈

7.1. Relation to Gilbert Model 🧠

Okay, this is where it gets really good. The general Gilbert-Elliot model is a discrete-time Markov chain with two states, Good (g) and Bad (b), and each state has its own independent packet loss ratio 💜 In the simplest version, the Good state's loss ratio is 0 and the Bad state's loss ratio is 1. That leaves two independent parameters: the Markov transition probabilities P(g|b) = 1- P(b|b) and P(b|g) = 1- P(g|g). Here P(i|j) is the probability of moving from state j at step n to state i at step n+1. With those in hand, the fraction of steps spent in the Bad state is P(b|g)/(P(b|g) + P(g|b)), and the average length of a stay in the Bad state is 1/P(g|b) steps ✨

Now the plot twist 🎀 Map the steps of the Markov chain onto the possible sending times of packets for a Type-P-One-way-Bi-Packet-Loss-Geometric-Stream with launch spacing d. Say the loss episode metrics Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Ratio and Type-P-One-way-Bi-Packet-Loss-Geometric-Stream-Episode-Duration come out to r and m. Then, using the discussion in Section 6.1.5, these equal each other:

r = P(b|g)/(P(b|g) + P(g|b)) and m/d = 1/P(g|b).

And you can flip it around to recover the Gilbert model parameters 🔄

P(g|b) = d/m and P(b|g)=d/m/(1/r - 1)

8. Security Considerations 🔐

Okay, safety first, bestie 🫶 Doing Internet measurements raises both security and privacy concerns. This memo doesn't specify an implementation of the metrics, so it doesn't directly affect the security of the Internet or the apps running on it. BUT implementations of these metrics still need to be mindful of security and privacy concerns 👀

There are two kinds of security concern: potential harm caused by the measurements, and potential harm to the measurements 😱 The first one happens because the measurements are active and inject packets into the network. The measurement parameters MUST be carefully selected so the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results and, in extreme cases, cause congestion and denial of service. Yikes 💀

The second one: routers could give measurement traffic a different priority than "normal" traffic, or an attacker could inject fake measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements may not reflect actual user traffic. And if an attacker injects artificial traffic that gets accepted as legit, the loss rate will be artificially lowered 📉 So the measurement methodologies SHOULD include appropriate techniques to reduce the probability that measurement traffic can be told apart from "normal" traffic. Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks 🛡️

The privacy side is lowkey chill. Because these are active measurements, they involve no release of user data 🌸

9. References 📚

9.1. Normative References 💜

[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.

[RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
           Protocol Extended Reports (RTCP XR)", RFC 3611,
           November 2003.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3432]  Raisanen, V., Grotefeld, G., and A. Morton, "Network
           performance measurement with periodic streams", RFC 3432,
           November 2002.

9.2. Informative References 🦋

[RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
           "Framework for IP Performance Metrics", RFC 2330,
           May 1998.

[RFC3357]  Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
           Metrics", RFC 3357, August 2002.

[SBDR08]   IEEE/ACM Transactions on Networking, 16(2): 307-320, "A
           Geometric Approach to Improving Active Packet Loss
           Measurement", 2008.

[Gilbert]  Gilbert, E.N., "Capacity of a Burst-Noise Channel. Bell
           System Technical Journal 39 pp 1253-1265", 1960.

[Elliot]   Elliott, E.O., "Estimates of Error Rates for Codes on
           Burst-Noise Channels. Bell System Technical Journal 42 pp
           1977-1997", 1963.

Authors' Addresses 🎀

Nick Duffield
AT&T Labs-Research
180 Park Avenue
Florham Park, NJ  07932
USA

Phone: +1 973 360 8726
Fax:   +1 973 360 8871
EMail: duffield@research.att.com
URI:   http://www.research.att.com/people/Duffield_Nicholas_G


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/


Joel Sommers
Colgate University
304 McGregory Hall
Hamilton, NY  13346
USA

Phone: +1 315 228 7587
Fax:
EMail: jsommers@colgate.edu
URI:   http://cs.colgate.edu/faculty/jsommers
📦 where this page comes from