RFC 5136

Defining Network Capacity

📅 published February 2008, from ietf

RFC 5136: Defining Network Capacity 💖

Okay bestie, this one is RFC 5136, and it's titled Defining Network Capacity 🦋. It was written by P. Chimento of the JHU Applied Physics Lab and J. Ishac of NASA Glenn Research Center, and it came out in February 2008 from the Network Working Group. It's an Informational doc, which means it gives info to the Internet community and does not set any standard. Its header doesn't list any RFCs it obsoletes or updates, so it's totally a solo mission 💅.

Table of Contents 🌸

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Links and Paths  . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Definition: Nominal Physical Link Capacity . . . . . . . .  4
     2.3.  Capacity at the IP Layer . . . . . . . . . . . . . . . . .  5
       2.3.1.  Definition: IP-layer Bits  . . . . . . . . . . . . . .  5
         2.3.1.1.  Standard or Correctly Formed Packets . . . . . . .  5
         2.3.1.2.  Type P Packets . . . . . . . . . . . . . . . . . .  6
       2.3.2.  Definition: IP-type-P Link Capacity  . . . . . . . . .  7
       2.3.3.  Definition: IP-type-P Path Capacity  . . . . . . . . .  7
       2.3.4.  Definition: IP-type-P Link Usage . . . . . . . . . . .  7
       2.3.5.  Definition: IP-type-P Link Utilization . . . . . . . .  8
       2.3.6.  Definition: IP-type-P Available Link Capacity  . . . .  8
       2.3.7.  Definition: IP-type-P Available Path Capacity  . . . .  8
   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Time and Sampling  . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Hardware Duplicates  . . . . . . . . . . . . . . . . . . .  9
     3.3.  Other Potential Factors  . . . . . . . . . . . . . . . . .  9
     3.4.  Common Terminology in Literature . . . . . . . . . . . . . 10
     3.5.  Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12

Status of This Memo ✨

This memo gives info to the Internet community, and it does not specify an Internet standard of any kind 🎀. Distribution of this memo is unlimited, so share it with your whole group chat 🫶.

Abstract 💜

Okay so measuring capacity sounds simple, but it is lowkey a mess 😭. There isn't a unified nomenclature for this stuff, which makes it really hard to build, test, and use the techniques and tools that depend on these concepts. This doc defines the terms 'Capacity' and 'Available Capacity' for IP traffic moving between a source and a destination in an IP network 🌈. The goal is a common framework for talking about and analysing a whole bunch of current and future estimation techniques, and honestly that's iconic 👑.

1. Introduction 🧚

Okay so measuring the capacity of a link or network path sounds simple, but it's giving complicated 💀. Every physical medium needs information to be encoded, and depending on the medium there are different schemes for turning information into a sequence of signals that get sent physically from one place to another 🔥.

On some media, the maximum frequency of those signals can be thought of as "capacity." On other media, though, the signal transmission frequency and the information capacity of the medium (the channel) can be totally different 🙈. For example, a satellite channel might have a carrier frequency of a few gigahertz, but an information-carrying capacity of only a few hundred kilobits per second 🛰️. People often use similar or identical terms for these different things, which adds to the confusion, and the lack of unified nomenclature makes it harder to build, test, and use the various techniques and tools 😤.

We care about information-carrying capacity, but even that isn't straightforward 💅. Depending on the medium, each layer adds overhead to the job of carrying information. Wired Ethernet uses Manchester coding or 4/5 coding, which cuts down a lot on the "theoretical" capacity 📉. RF (radio frequency) communications often add redundancy to the coding scheme to do forward error correction, because air is a lossy medium. That can drop the information capacity even further 🌸.

On top of coding schemes, the physical layer and the link layer usually add framing bits for multiplexing and control. For example, SONET has physical-layer framing and typically also some layer-2 framing such as High-Level Data Link Control (HDLC), PPP, or ATM 🍓.

Coding efficiency isn't the only thing, either. How access to the channel is controlled can affect capacity too 🦋. For example, a multiple-access medium with collision detection, avoidance, and recovery mechanisms has a varying capacity from the users' point of view. That varying capacity depends on the total number of users contending for the medium, how busy those users are, and the bounds that come from the mechanisms themselves 😩. RF channels can vary in capacity too, depending on range, environmental conditions, mobility, shadowing, etc. ⭐

So the big takeaways are these. First, capacity only means something when it's defined relative to a given protocol layer in the network. Saying "link" capacity without specifying exactly what you mean is meaningless 🙅‍♀️. Second, capacity isn't necessarily fixed, so a single measure of capacity at any layer might paint a skewed picture, either optimistic or pessimistic, of what's actually available 💖.

2. Definitions 🎀

In this section we specify definitions for capacity. We start by defining "link" and "path" clearly, and then we define a baseline capacity that's tied directly to the physical properties of the link ✨.

To define capacity, we need to broaden the notions of link and path from the IP Performance Metrics (IPPM) framework document [RFC2330] so they include network devices that can affect IP capacity without being IP aware 🧠. For example, picture an Ethernet switch that can run its ports at different speeds 🔌.

We define nodes as hosts, routers, Ethernet switches, or any other device where the input and output links can have different characteristics 🌟. A link is a connection between two of these network devices or nodes. We then define a path P of length n as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and destination D reside at N1 and Nn+1, respectively. Furthermore, we define a link L as the special case where the path length is one 💜.

Nominal Physical Link Capacity, NomCap(L), is the theoretical maximum amount of data that the link L can support 💅. For example, an OC-3 link would be capable of 155.520 Mbit/s. We really want to stress that this is a measurement at the physical layer and not the network IP layer, which we'll define separately 🙈. NomCap(L) is typically constant over time, but some links can behave otherwise, like a satellite link that dynamically activates additional transponders 🛰️.

The nominal physical link capacity is there to help you tell apart the commonly used link-layer capacities from the rest of the IP-layer capacity definitions 🍓. So the value of NomCap(L) doesn't influence the other definitions in this document. Instead, it gives an upper bound on those values 👑.

2.3. Capacity at the IP Layer 💖

There are lots of factors that can reduce the IP information-carrying capacity of a link, and some of them we already covered in the introduction 😭. But the goal of this doc is not to become an exhaustive list of those factors. We just outline some of the major examples in the following section, which gives food for thought to anyone implementing algorithms or tools that try to measure capacity accurately 🧚.

The remaining definitions are all given in terms of "IP-layer bits," so they're clearly separate from the nominal physical capacity of the link 🦋.

2.3.1. Definition: IP-layer Bits 🌸

IP-layer bits are defined as eight (8) times the number of octets in all IP packets received, counting from the first octet of the IP header to the last octet of the IP packet payload, inclusive 🎀.

IP-layer bits are recorded at the destination D, beginning at time T and ending at time T+I. Since these definitions are based on averages, the two time parameters, T and I, must accompany any report or estimate of the following values, or they stop being meaningful 😤. It's not required that the interval boundary points fall between packet arrivals at D. However, boundaries that fall within a packet will invalidate the packets they fall on. Specifically, the data from the partial packet inside the interval won't be counted. That can artificially bias some values, depending on the interval length and how much data arrives during it 🙈. We explain what counts as correctly received data in the next section 💅.

2.3.1.1. Standard or Correctly Formed Packets ✨

Okay so the definitions in this doc say that IP packets must be received correctly 💯. The IPPM framework recommends a set of criteria for these standard-formed packets in Section 15 of [RFC2330]. But honestly, it's inadequate for this doc, so we outline our own criteria below and point out any variations from or similarities to [RFC2330] 🫶.

First, data that's in error at layers below IP, and can't be properly passed up to the IP layer, must not be counted. For example, wireless media often have a much bigger error rate than wired media, which lowers IP link capacity 📡. In line with the IPPM framework, packets that fail validation of the IP header must be discarded. Specifically, the requirements in [RFC1812], Section 5.2.2, on IP header validation must be checked, and that includes a valid length, checksum, and version field 🔍.

The IPPM framework goes further, requiring that any transport header be checked for correctness and that any packets with IP options be ignored 🧐. But the definitions in this document are concerned with the traversal of IP-layer bits. So data from the higher layers isn't required to be valid or understood, since it's just treated as part of the IP packet 🌈. The same goes for IP options 🎀. Valid IP fragments must also be counted, because they use up a link's resources even if the full packet can't be assembled 🔥. The IPPM framework is different here, since it discards IP fragments 🙅‍♀️.

For a discussion of duplicates, see Section 3.2 👑.

So in summary, any IP packet that can be properly processed must be included in these calculations 💖.

2.3.1.2. Type P Packets ✨

okay so "Type P" is basically a placeholder 🎀 It stands in for whatever packet flows the metric is talking about. It can be a super explicit spec, or a really loose one that covers a whole pile of aggregates. RFC 2330, Section 13 is where that idea comes from, and we use the "Type P" label here for two big reasons 💅

First, the capacity number depends on which kinds of flows we're talking about. Networks can treat packets differently for queuing and scheduling based on their markings and classification, and some networks even flow-balance by packet type or flow type. That can totally change what you measure 🙈

Second, the measurement depends on more than just the type of the reference packets. It also depends on the types of packets in the "population" that shares the links on the path with the flows you care about. It's giving "who you're sharing the bus with" energy 🚌

So there are two different ways to measure. One is to use a broad mix of packet types, which means "Type P" should be as generic as possible. The other is to zoom in on the specific flows you're actually interested in, which means "Type P" should be very specific and narrowly defined. The first approach is probably more interesting to providers, and the second is more the vibe for application users 🦋

Real talk: some providers may treat certain packets differently from others. For example, access control lists, routing policies, and other mechanisms may be used to filter ICMP packets, or to forward packets with certain IP options through different routes. If a capacity-measurement tool uses these special packets and they're included in the "Type P" designation, the tool may not be measuring the path it was meant to measure. Tool authors and users may want to double-check this with their service providers 🫶

We define the IP-layer link capacity, C(L,T,I), as the maximum number of IP-layer bits that can be transmitted from the source S and correctly received by the destination D over the link L during the interval [T, T+I], divided by I.

As we mentioned earlier, this definition is affected by lots of factors that can change over time 🌸 For example, how well a device can process and forward IP packets for a particular link can have different effects on capacity, depending on how much traffic or what kind of traffic is being handled. It's all very mood-dependent 🙈

2.3.3. Definition: IP-type-P Path Capacity 🧚

Using our definition for IP-layer link capacity, we can extend the idea to a whole path. The IP-layer path capacity is just the capacity of the link with the smallest capacity along that path. Main character energy for the narrowest link 👑

C(P,T,I) = min {1..n} {C(Ln,T,I)}

The definitions we've looked at so far tell you how many IP-layer bits can cross a link or path when the resource is free of any congestion. That's the full capacity available to traffic between the source and destination ✨ But figuring out how much capacity is available on a congested link is honestly way more useful. To get there, though, we first need to figure out how much is being used 💅

The average usage of a link L, Used(L,T,I), is the actual number of IP-layer bits from any source that are correctly received over link L during the interval [T, T+I], divided by I.

The big difference between usage and capacity is that Used(L,T,I) isn't the maximum number. It's the actual number of IP bits sent that get correctly received 😭 The information crossing the link can come from any source, including sources that aren't directly attached to either side of the link. On top of that, each flow from these sources can share any number of links, from one to n, along the overall path between S and D 🌈

We express usage as a fraction of the overall IP-layer link capacity.

Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) )

So utilization is the fraction of the capacity that's being used, and it lands somewhere between zero (nothing is used) and one (the link is fully saturated) 🔥 Multiply the utilization by 100 and you get the percent utilization of the link. With all that in place, we can finally define the capacity available over the link, and over the path between S and D. Note that this is essentially the definition in [PDM] 💜

To figure out the available capacity on a congested link, we multiply the IP-layer link capacity by the complement of the IP-layer link utilization. So the IP-layer available link capacity becomes:

AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )

2.3.7. Definition: IP-type-P Available Path Capacity 💅

Using our definition for IP-layer available link capacity, we can extend the idea to a whole path. The IP-layer available path capacity is just the available capacity of the link with the smallest available capacity along that path 👑

AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)}

Measurements of available capacity are way more volatile than link capacity measurements, so we really stress that both the time and the interval need to be specified 😭 Their values have a huge influence on the results. A sequence of measurements can also help smooth out that volatility when you're trying to characterize available capacity 🌸

3. Discussion 🫶

3.1. Time and Sampling ⭐

We have to emphasize how important time is in the basic definitions of these quantities. Traffic on the Internet is highly variable across all time scales, so the time and length of measurements are critical when you report available capacity. They must be reported whenever you use these definitions 💖

The closer a metric gets to "instantaneous," the more important it is to have a plan for sampling it over a time period that's large enough. Doing that lets us make valid statistical inferences from the measurements 🧚 An obvious pitfall here is sampling in a way that causes bias, like when your sampling frequency is a multiple of the frequency of some underlying condition. Sneaky, right? 🙈

3.2. Hardware Duplicates 🔥

Let's look at what happens on paths where hardware duplication of packets may occur. In that kind of environment, a node on the network path may duplicate packets, so the destination can receive multiple identical copies. Both the original packet and the duplicates can be properly received and seem to come from the sender 🦋 So in the most generic form, duplicate IP packets get counted in these definitions.

Hardware duplication can change things, though, depending on how you use "Type P" to add extra restrictions on packet reception. For instance, only counting uniquely-sent packets might be more useful for users who care about capacity for meaningful data 🎀 The more general, unrestricted metric might suit someone who cares about raw capacity. So it's up to the user to properly scope and interpret results in situations where hardware duplicates are likely to show up 💅

3.3. Other Potential Factors 🌈

IP encapsulation doesn't affect the definitions, because all IP header and payload bits must be counted regardless of content ✨ IP packets of different sizes can change how much overhead the lower layers need to transmit the data, which alters the overall IP link-layer capacity. Slay math, but make it networking 🍓

If the link happens to use a compression scheme like RObust Header Compression (ROHC) [RFC3095] or V.44 [V44], some of the original bits never get transmitted across the link. Even so, the inflated (not compressed) number of IP-layer bits should be counted 💜

3.4. Common Terminology in Literature 🧚

There are some terms people use all the time to describe specific parts of these definitions. The link with the smallest capacity is commonly called the "narrow link" of a path. The link with the smallest available capacity is often called the "tight link" within a path 💖 So even if a given link has a huge capacity, its overall congestion level can make it the likely bottleneck of a connection. The reverse is also true: a link with the smallest capacity might not be the bottleneck if it's lightly loaded compared to the rest of the path 🫶

Literature also tends to overload the term "bandwidth" to mean what we've been calling capacity in this document 😭 For example, if you ask a network engineer about the bandwidth of a 802.11b link, they'll probably say 11 Mbit/s. An electrical engineer might say 25 MHz, and an end user might tell you their observed bandwidth is 8 Mbit/s 💀 The term "capacity" isn't quite as overloaded, so it's a much better fit for what's actually being measured 👑

3.5. Comparison to Bulk Transfer Capacity (BTC) 🌸

Bulk Transfer Capacity (BTC) [RFC3148] gives a different perspective on path capacity, and it differs from the definitions in this document in several fundamental ways 🦋 First, BTC operates at the transport layer. It gauges the amount of capacity available to an application that wants to send data, and only unique data is measured. That means header and retransmitted data are not included in the calculation. By contrast, IP-layer link capacity includes the IP header and doesn't care whether the data in the packet payload is unique 🎀 (Hardware duplication of packets is an anomaly we already covered in a previous section 🙈)

Second, BTC uses a single congestion-aware transport connection, such as TCP, to get its measurements. Because of that, BTC implementations react strongly to different path characteristics, topologies, and distances. Those differences can affect the control loop (propagation delays, segment reordering, and so on), so the reaction also depends on the algorithms used for the measurements 🧚 For example, imagine a single event where a link suffers a long stretch of bit errors. That event could cause IP-layer packets to be discarded, and the lost packets would reduce the IP-layer link capacity. But the same event and the losses that follow would trigger loss recovery for a BTC measurement, which means data gets retransmitted and the sending rate might drop 😭 So a BTC measurement doesn't correspond to any of the definitions in this document. Both techniques are useful for exploring the characteristics of a network path, just from different perspectives 💖

4. Security Considerations ✨

okay so security, let's gooo 🔒 this doc defines capacity stuff for IP traffic moving between a source and a destination in an IP network. the definitions themselves are totally harmless, no security issues, and they don't directly mess with the networking protocol suite 💖

BUT tools that try to implement these definitions can bring their own security issues, specific to each implementation 🙈 and both active and passive measurement techniques can be abused, which can hurt the security, privacy, and performance of the network 💀

so if you're building a measurement technique based on these definitions, it must include a discussion of how you'll protect the network you're measuring. not optional, bestie 🫶

5. Conclusion 🎀

so to wrap it up, this doc defined a bunch of quantities related to the capacity of links and paths in an IP network 🌸 we tried to be super clear and account for all the different characteristics links and paths can have ✨

the whole point is to help researchers who propose capacity metrics relate those metrics back to these definitions, and then check how well those metrics approximate these quantities. main character research energy 👑

we also called out some key auxiliary parameters and opened up a discussion about valid inferences you can make from available capacity metrics 🧚

6. Acknowledgments 💜

the authors want to give a huge shoutout to Mark Allman, Patrik Arlos, Matt Mathis, Al Morton, Stanislav Shalunov, and Matt Zekauskas for their suggestions, comments, and reviews 🫶 we also thank the members of the IETF IPPM Mailing List for their discussions and feedback on this doc. the real MVPs 👑

7. References 🦋

7.1. Normative References ✨

[RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
           RFC 1812, June 1995.

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

7.2. Informative References 🌈

[PDM]      Dovrolis, C., Ramanathan, P., and D. Moore, "Packet
           Dispersion Techniques and a Capacity Estimation
           Methodology", IEEE/ACM Transactions on Networking 12(6):
           963-977, December 2004.

[RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
           Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
           K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
           Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
           Compression (ROHC): Framework and four profiles: RTP, UDP,
           ESP, and uncompressed", RFC 3095, July 2001.

[RFC3148]  Mathis, M. and M. Allman, "A Framework for Defining
           Empirical Bulk Transfer Capacity Metrics", RFC 3148,
           July 2001.

[V44]      ITU Telecommunication Standardization Sector (ITU-T)
           Recommendation V.44, "Data Compression Procedures",
           November 2000.

Authors' Addresses 📮

the two authors, in case you want to reach out 💌

Phil Chimento
JHU Applied Physics Lab
11100 Johns Hopkins Road
Laurel, Maryland  20723-6099
USA

Phone: +1-240-228-1743
Fax:   +1-240-228-0789
EMail: Philip.Chimento@jhuapl.edu


Joseph Ishac
NASA Glenn Research Center
21000 Brookpark Road, MS 54-5
Cleveland, Ohio  44135
USA

Phone: +1-216-433-6587
Fax:   +1-216-433-8705
EMail: jishac@nasa.gov

the legal bits, kept word for word so nothing gets lost in translation 🙏

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 💅

the IETF doesn't take a position on whether any IP rights claimed for this tech are valid or in scope, or whether licenses are available. it also doesn't say it looked for any such rights. the procedures for rights in RFC docs live in BCP 78 and BCP 79 🌷

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
ietf-ipr@ietf.org.
📦 where this page comes from