RFC 3357

One-way Loss Pattern Sample Metrics

📅 published August 2002, from ietf

RFC 3357: One-way Loss Pattern Sample Metrics 🎀

Okay bestie, let's get into this one. It's RFC 3357: One-way Loss Pattern Sample Metrics ✨, written by R. Koodli from Nokia Research Center and R. Ravikanth from Axiowave. It's an Informational doc, dated August 2002, and its header doesn't list anything it obsoletes or updates. 💅

Status of This Memo 📝

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

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

Abstract 🦋

Okay so this doc uses the base loss metric from RFC 2680 and builds two derived metrics, "loss distance" and "loss period," plus the stats that go with them. Together they capture the loss patterns packet streams actually hit on the Internet. The Internet has specific behaviors, like bursty packet loss, that can mess with performance for both users and operators. 😭

The loss pattern (or loss distribution) is a key parameter for real-time stuff like packet voice and video. For the same loss rate, two different loss distributions could give wildly different experiences. Main character energy, but make it packet loss. 🔥

Table of Contents 🗂️

   1. Introduction                                                     3
   2. Terminology                                                      3
   3. The Approach                                                     3
   4. Basic Definitions                                                4
   5.  Definitions for Samples of One-way Loss Distance, and One-way
        Loss Period                                                    5
       5.1. Metric Names  . . . . . . . . . . . . . . . . . . . . . .  5
             5.1.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . .  5
             5.1.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . .  5
       5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . .  5
       5.3. Metric Units  . . . . . . . . . . . . . . . . . . . . . .  5
             5.3.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . .  5
             5.3.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . .  5
       5.4. Definitions . . . . . . . . . . . . . . . . . . . . . . .  6
             5.4.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . .  6
             5.4.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . .  6
             5.4.3. Examples  . . . . . . . . . . . . . . . . . . . .  6
       5.5. Methodologies . . . . . . . . . . . . . . . . . . . . . .  7
       5.6. Discussion  . . . . . . . . . . . . . . . . . . . . . . .  8
       5.7. Sampling Considerations . . . . . . . . . . . . . . . . .  8
       5.8. Errors and Uncertainties  . . . . . . . . . . . . . . . .  8
   6. Statistics                                                       9
       6.1. Type-P-One-Way-Loss-Noticeable-Rate . . . . . . . . . . .  9
       6.2. Type-P-One-Way-Loss-Period-Total  . . . . . . . . . . . .  9
       6.3. Type-P-One-Way-Loss-Period-Lengths  . . . . . . . . . . . 10
       6.4. Type-P-One-Way-Inter-Loss-Period-Lengths  . . . . . . . . 10
       6.5. Examples  . . . . . . . . . . . . . . . . . . . . . . . . 10
   7. Security Considerations                                         11
       7.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
       7.2. Privacy / Confidentiality . . . . . . . . . . . . . . . . 12
       7.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 12
   8. IANA Considerations                                             12
   9. Acknowledgements                                                12
   10. Normative References                                           12
   11. Informative References                                         13
   Authors' Addresses                                                 14
   Full Copyright Statement                                           15

1. Introduction 🌸

So in certain real-time apps (think packet voice and video), the loss pattern is a huge deal for how users experience things. Same loss rate, different loss distribution, totally different vibes. 🫶 It matters for non-real-time apps too, especially ones that use an adaptive protocol like TCP. Check out [4], [5], [6], [11] if you want the receipts on how bursty loss exists and how it hits voice and video.

Before this, the IPPM crew focused on base metrics like delay, loss, and connectivity under the framework in RFC 2330. But specific Internet behaviors can also fit under the IPPM umbrella, as long as we add new concepts and reuse existing guidelines wherever we can. ✨

This doc proposes two derived metrics, "loss distance" and "loss period," with associated statistics, to capture packet loss patterns. The loss period metric captures how often loss happens and how long (the burstiness) it lasts once it starts. The loss distance metric captures the spacing between loss periods. 🧚 Important note: these metrics are derived from the base metric Type-P-One-Way-packet-Loss. 💜

2. Terminology 📖

Here are the key words that matter. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. Read them as written. 🙈

3. The Approach 🧭

This doc closely follows the guidelines in [3]. So the concepts of singleton, sample, statistic, measurement principles, Type-P packets, and standard-formed packets all still apply. 🎀 But since this doc is capturing specific Internet behaviors, modifications to the sampling process MAY be needed. This is mentioned in [1], which says alternate sampling procedures may be useful depending on the situation. 👀

The approach is to capture the specific behaviors as "derived" metrics from the base metrics they relate to. Here's why that's the move:

  • it provides consistent usage of singleton metric definition for different behaviors (e.g., a single definition of packet loss is needed for capturing burst of losses, 'm out of n' losses etc.)
  • it allows re-use of the methodologies specified for the singleton metric with modifications whenever necessary
  • it clearly separates few base metrics from many Internet behaviors

Following [3], this means deriving sample metrics from the respective singletons. The process for doing that is specified in [3], [1], and others. 💅

In the next sections, we apply this approach to one particular Internet behavior: the packet loss process. ✨

4. Basic Definitions 🍓

Sequence number: Consecutive packets in a time series sample get sequence numbers that are consecutive integers. This doc doesn't specify exactly how to link sequence numbers to packets. The sequence numbers could live inside the test packets themselves, or they could be derived through post-processing of the sample. 🔢

Bursty loss: Loss involving consecutive packets of a stream. 💥

Loss Distance: The difference in sequence numbers of two successively lost packets, which may or may not be separated by successfully received packets. 🦋

Example, in a packet stream: the packet with sequence number 20 is lost, followed by the packet with sequence number 50. The loss distance is 30.

   Example: In a packet stream, the packet with sequence number 20 is
            considered lost, followed by the packet with sequence number
            50.  The loss distance is 30.

Loss period: Let P_i be the i'th packet. Define f(P_i) = 1 if P_i is lost, 0 otherwise. Then a loss period begins if f(P_i) = 1 and f(P_(i-1)) = 0. 🌈

Here's an example sequence of lost (x) and received (r) packets. 👇

         r r r x r r x x x r x r r x x x

With i assigned as follows:

                               1 1 1 1 1 1
   i:      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

f(P_i) is:

   f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1

So there are four loss periods in that sequence, beginning at P_3, P_6, P_10, and P_13. Four loss periods, and you can count every single one! 🔥

To be continued in part 2 👑

5.4.3. Examples

okay so let's walk through a sample together 💖 Here's a set of pairs that represents a Type-P-One-Way-Loss-Stream:

{<T1,0>,<T2,1>,<T3,0>,<T4,0>,<T5,1>,<T6,0>,<T7,1>,<T8,0>,
 <T9,1>,<T10,1>}

where T1, T2,..,T10 are in increasing order 🧚

Packets sent at T2, T5, T7, T9, T10 are lost 🙈 From this one sample we can get both of the derived metrics, and it's honestly so satisfying to watch them fall out 🦋

(i) Type-P-One-Way-Loss-Distance-Stream:

Packet 2 is the first lost packet, so its loss distance is zero 🌸 For the next lost packet (packet 5), the loss distance is 5-2 or 3. The rest work the same way: packets 7, 9, and 10 have loss distances of 2, 2, and 1 respectively ✨ So the Type-P-One-Way-Loss-Distance-Stream ends up as:

{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}

(ii) The Type-P-One-Way-Loss-Period-Stream:

Packet 2 sets the counter 'n' to 1 💅 It gets bumped by one for packets 5, 7 and 9, following the definition in 4. Then for packet 10 the counter stays at 4, which still fits the definition in 4 (periodt 💀). So the Type-P-One-Way-Loss-Period-Stream is:

{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}

5.5. Methodologies

the same methodology outlined in [1] can be used to run these sample experiments 🎀 Here's a quick synopsis.

Generally, for a given Type-P, one possible methodology goes like this:

  • okay first, assume Src and Dst have clocks that are synchronized with each other ⏰ How tightly synced they need to be is a parameter of the methodology, and it depends on the threshold used to decide loss (more on that below).
  • At the Src host, pick the Src and Dst IP addresses, and build a test packet of Type-P with those addresses 🧁
  • At the Dst host, set things up so it's ready to receive the packet 👂
  • At the Src host, put a timestamp in the prepared Type-P packet, then send it off toward Dst 🚀
  • If the packet shows up within a reasonable period of time, the one-way packet-loss is taken to be zero ✅
  • If the packet doesn't arrive within a reasonable period of time, the one-way packet-loss is taken to be one 😭 Just note that the threshold of "reasonable" here is a parameter of the methodology, so you get to decide it.

5.6. Discussion

the Loss-Distance-Stream metric lets you study the separation between packet losses 🌈 This could be really useful for figuring out a "spread factor" tied to the packet loss rate. Put it together with the Loss-Period-Stream metric and you can study loss burstiness for each occurrence of loss, which is so main character 💜 A single loss period of length 'n' can account for a big chunk of the overall loss rate, so don't sleep on it 👑 Also, it's possible to measure the distance between loss bursts that are separated by one or more successfully received packets. (Refer to Sections 6.4 and 6.5.)

5.7. Sampling Considerations

the proposed metrics can be used no matter which sampling method you pick 🦋 That said, Poisson sampling may not give appropriate values for these metrics for certain real-time applications like voice over IP, and also for TCP-based applications 🙈 For real-time applications, it may be a better fit to use the ON-OFF [10] model. In that model, an ON period starts with a certain probability 'p', and during it a certain number of packets get transmitted, with mean 'lambda-on', following a geometric distribution. An OFF period starts with probability '1-p' and lasts for a period of time based on an exponential distribution with rate 'lambda-off' ✨

For TCP-based applications, one may use the model proposed in [8]. See [9] for an application of that model 🫶

5.8. Errors and Uncertainties

the measurement stuff, like packet size, loss threshold, the type of test machine you pick, and so on, basically always influences the packet loss metric itself, and that means the derived metrics in this document get affected too 😩 So when you're assessing results for the metrics in this document, you have to pay attention to all of this. For a detailed look at errors and uncertainties in measuring the base packet loss metric, see [1].

6. Statistics

6.1. Type-P-One-Way-Loss-Noticeable-Rate

okay so a loss of a packet counts as "noticeable" [7] if the distance between the lost packet and the previously lost packet is no greater than delta, where delta is a positive integer called the "loss constraint" 🎀

Example: let delta = 99. Say packet 50 is lost, and then there's a bursty loss of length 3 starting at packet 125. All three losses starting from packet 125 are noticeable 💀

Given a Type-P-One-Way-Loss-Distance-Stream, you can compute this statistic pretty simply: count the losses that violate some constraint delta, then divide by the number of losses. (Alternatively, you can define it as the number of "noticeable losses" divided by the number of successfully received packets.) This statistic is useful when the actual distance between successive losses matters 🌸 For instance, lots of multimedia codecs can sustain losses by "concealing" the effect of loss using past history information. Their ability to do that gets worse when there's poor history because losses are close together. So by picking delta based on that sensitivity, you can measure how "noticeable" a loss might be for quality purposes 🔥

A noticeable loss needs a certain "spread factor" for the losses in the timeseries. In the example above, where the loss constraint is 99, a loss rate of one percent with a spread of 100 between losses (e.g., 100, 200, 300, 400, 500 out of 500 packets) might be more desirable for some applications than the same loss rate with a spread that violates the loss constraint (e.g., 100, 175, 275, 290, 400: losses occurring at 175 and 290 violate delta = 99) 😤 The spread is the whole vibe, bestie.

6.2. Type-P-One-Way-Loss-Period-Total

this one tells you the total number of loss periods, and you can derive it from the loss period metric Type-P-One-Way-Loss-Period-Stream like this:

Type-P-One-Way-Loss-Period-Total = maximum value of the first entry
of the set of pairs, <loss period, loss>, representing the loss
metric Type-P-One-Way-Loss-Period-Stream.

Just a heads up, this statistic doesn't describe the duration of each loss period itself. If it's large, that does NOT mean the losses are more spread out than they otherwise would be, since one or more loss periods may include bursty losses 👀 Generally, it's useful for getting a first order approximation of loss spread 🧚

6.3. Type-P-One-Way-Loss-Period-Lengths

this statistic is a sequence of pairs <loss period, length>, where the "loss period" entry ranges from 1 - Type-P-One-Way-Loss-Period-Total. So the total number of pairs in this statistic equals Type-P-One-Way-Loss-Period-Total ✨ For each pair, the "length" comes from counting the number of pairs, <loss period, loss>, in the metric Type-P-One-Way-Loss-Period-Stream whose first entry equals that "loss period."

Since this tells you how many packets were lost in each loss period, it's an indicator of how bursty each loss period is 🍓 Paired with the loss-period-total statistic, it's generally useful for spotting which loss periods might be more influential than others from a quality perspective 💅

6.4. Type-P-One-Way-Inter-Loss-Period-Lengths

this statistic measures the distance between successive loss periods 🦋 It's a set of pairs <loss period, inter-loss-period-length>, where the "loss period" entry ranges from 1 - Type-P-One-Way-Loss-Period-Total. The "inter-loss-period-length" is the loss distance between the last packet considered lost in "loss period" 'i-1' and the first packet considered lost in "loss period" 'i', where 'i' ranges from 2 to Type-P-One-Way-Loss-Period-Total. The "inter-loss-period-length" for the first "loss period" is defined to be zero.

This statistic lets you consider things like two loss periods that are each longer than one (which implies a loss burst) but separated by a distance of 2, and decide whether they belong to the same loss burst, if that's useful for you 🤔 When the Inter-Loss-Period-Length between two bursty loss periods is smaller, it could affect how well multimedia codecs can conceal losses, since there's relatively less history. When it's larger, an application may be able to rebuild its history, which could dampen the effect of an impending loss (period) 🫶

6.5. Examples

we're continuing with the same example from Section 5.4.3 🎀 The three statistics defined above come out to these values:

  • Let delta = 2. In the Type-P-One-Way-Loss-Distance-Stream
{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>},

there are 3 loss distances that violate the delta of 2. So, Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable losses)/(number of total losses)) 🔥

  • In the Type-P-One-Way-Loss-Period-Stream
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},

the largest of the first entry in the sequence of <loss period,loss> pairs is 4. Thus,

Type-P-One-Way-Loss-Period-Total = 4
  • In the same Type-P-One-Way-Loss-Period-Stream
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},

the lengths of the individual loss periods are 1, 1, 1 and 2 respectively. Thus,

Type-P-One-Way-Loss-Period-Lengths =

   {<1,1>,<2,1>,<3,1>,<4,2>}
  • In that same Type-P-One-Way-Loss-Period-Stream, loss periods 1 and 2 are separated by 3 (5-2), loss periods 2 and 3 are separated by 2 (7-5), and loss periods 3 and 4 are separated by 2 (9-7). Thus, Type-P-One-Way-Inter-Loss-Period-Lengths =
{<1,0>,<2,3>,<3,2>,<4,2>}

7. Security Considerations

conducting Internet measurements raises both security and privacy concerns 🔐 This document doesn't specify a particular implementation of metrics, so it doesn't directly affect the security of the Internet or of the applications that run on it. However, implementations of these metrics must be mindful of security and privacy concerns 💜

The derived sample metrics in this document are based on the loss metric defined in RFC 2680 [1], so they inherit the security considerations of that document. Readers should consult [1] for a more detailed treatment of security considerations. Nevertheless, there are a few things to highlight 👑

7.1. Denial of Service Attacks

the lambda specified in the Type-P-Loss-Distance-Stream and Type-P-Loss-Period-Stream controls the rate at which test packets are sent 🚨 So if it's set inappropriately large, it could perturb the network under test, cause congestion, or at worst be a denial-of-service attack on that network. Legitimate measurements must have their parameters selected carefully so they don't interfere with normal traffic in the network 😱

7.2. Privacy / Confidentiality

privacy of user data isn't a concern here, since the underlying metric is intended to be implemented using test packets that contain no user information 🙌 Even if packets did contain user information, the derived metrics don't release data sent by the user.

7.3. Integrity

results could be perturbed by attempting to corrupt or disrupt the underlying stream, for example by adding extra packets that look just like test packets 🥺 To make sure test packets are valid and haven't been altered in transit, packet authentication and integrity checks, such as a signed cryptographic hash, MAY be used 🔏

8. IANA Considerations ✨

okay so this one is short and sweet 🫶 this document doesn't define a specific protocol, and it doesn't define any well-known values either, so there are no IANA considerations for it. nothing to register, nothing to reserve, we're chillin 🌸

9. Acknowledgements 🎀

shoutout to Matt Zekauskas, who gave super insightful feedback and wrote the text for the Security Considerations section 🫶 and Merike Kao, who helped revise the Security Considerations and the Abstract so they match RFC guidelines 💅 thank you both, you're literally the best 💖

thanks also to Guy Almes for encouraging the work ✨, to Vern Paxson for the comments during the IETF meetings 🦋, and to Steve Glass for giving the presentation at the Oslo meeting 🎤 the whole squad showed up 😭

10. Normative References 📚

  • [1] Almes, G., Kalindindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.

11. Informative References 🌈

these are the extra reads if you wanna go deeper, bestie 🤓📖

  • [4] J.-C. Bolot and A. vega Garcia, "The case for FEC-based error control for Packet Audio in the Internet", ACM Multimedia Systems, 1997.
  • [5] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, "Internet Packet Loss: Measurement and Implications for End-to-End QoS," Proceedings, International Conference on Parallel Processing, August 1998.
  • [6] M. Handley, "An examination of MBONE performance", Technical Report, USC/ISI, ISI/RR-97-450, July 1997
  • [7] R. Koodli, "Scheduling Support for Multi-tier Quality of Service in Continuous Media Applications", PhD dissertation, Electrical and Computer Engineering Department, University of Massachusetts, Amherst, MA 01003, September 1997.
  • [8] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP throughput: a simple model and its empirical validation", in Proceedings of SIGCOMM'98, 1998.
  • [9] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly rate adjustment protocol for continuous media flows over best-effort networks", short paper presentation in ACM SIGMETRICS'99. Available as Umass Computer Science tech report from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz
  • [10] K. Sriram and W. Whitt, "Characterizing superposition arrival processes in packet multiplexers for voice and data", IEEE Journal on Selected Areas of Communication, pages 833-846, September 1986,
  • [11] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation in the MBONE multicast network", Proceedings of IEEE Global Internet, London, UK, November 1996.

Authors' Addresses 💌

Rajeev Koodli 🌷 Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA

Phone: +1-650 625-2359 Fax: +1 650 625-2502 EMail: rajeev.koodli@nokia.com

Rayadurgam Ravikanth 🦋 Axiowave Networks Inc. 200 Nickerson Road Marlborough, MA 01752 USA

EMail: rravikanth@axiowave.com

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

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

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

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

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from