draft-ietf-ippm-bw-capacity-05.txt   rfc5136.txt 
IP Performance Metrics Working P. Chimento Network Working Group P. Chimento
Group JHU Applied Physics Lab Request for Comments: 5136 JHU Applied Physics Lab
Internet-Draft J. Ishac Category: Informational J. Ishac
Intended status: Informational NASA Glenn Research Center NASA Glenn Research Center
Expires: December 1, 2007 May 30, 2007 February 2008
Defining Network Capacity Defining Network Capacity
draft-ietf-ippm-bw-capacity-05
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 1, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007). This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
Measuring capacity is a task that sounds simple, but in reality can Measuring capacity is a task that sounds simple, but in reality can
be quite complex. In addition, the lack of a unified nomenclature on be quite complex. In addition, the lack of a unified nomenclature on
this subject makes it increasingly difficult to properly build, test, this subject makes it increasingly difficult to properly build, test,
and use techniques and tools built around these constructs. This and use techniques and tools built around these constructs. This
document provides definitions for the terms 'Capacity' and 'Available document provides definitions for the terms 'Capacity' and 'Available
Capacity' related to IP traffic traveling between a source and Capacity' related to IP traffic traveling between a source and
destination in an IP network. By doing so, we hope to provide a destination in an IP network. By doing so, we hope to provide a
common framework for the discussion and analysis of a diverse set of common framework for the discussion and analysis of a diverse set of
current and future estimation techniques. current and future estimation techniques.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Links and Paths . . . . . . . . . . . . . . . . . . . . . 4
2.1. Links and Paths . . . . . . . . . . . . . . . . . . . . . 6 2.2. Definition: Nominal Physical Link Capacity . . . . . . . . 4
2.2. Definition: Nominal Physical Link Capacity . . . . . . . . 6 2.3. Capacity at the IP Layer . . . . . . . . . . . . . . . . . 5
2.3. Capacity at the IP Layer . . . . . . . . . . . . . . . . . 6 2.3.1. Definition: IP-layer Bits . . . . . . . . . . . . . . 5
2.3.1. Definition: IP Layer Bits . . . . . . . . . . . . . . 7 2.3.1.1. Standard or Correctly Formed Packets . . . . . . . 5
2.3.1.1. Standard or Correctly Formed Packets . . . . . . . 7 2.3.1.2. Type P Packets . . . . . . . . . . . . . . . . . . 6
2.3.1.2. Type P Packets . . . . . . . . . . . . . . . . . . 8 2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 7
2.3.2. Definition: IP-type-P Link Capacity . . . . . . . . . 8 2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 7
2.3.3. Definition: IP-type-P Path Capacity . . . . . . . . . 9 2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 7
2.3.4. Definition: IP-type-P Link Usage . . . . . . . . . . . 9 2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 8
2.3.5. Definition: IP-type-P Link Utilization . . . . . . . . 9 2.3.6. Definition: IP-type-P Available Link Capacity . . . . 8
2.3.6. Definition: IP-type-P Available Link Capacity . . . . 9 2.3.7. Definition: IP-type-P Available Path Capacity . . . . 8
2.3.7. Definition: IP-type-P Available Path Capacity . . . . 10 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Time and Sampling . . . . . . . . . . . . . . . . . . . . 9
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Hardware Duplicates . . . . . . . . . . . . . . . . . . . 9
3.1. Time and Sampling . . . . . . . . . . . . . . . . . . . . 11 3.3. Other Potential Factors . . . . . . . . . . . . . . . . . 9
3.2. Hardware Duplicates . . . . . . . . . . . . . . . . . . . 11 3.4. Common Terminology in Literature . . . . . . . . . . . . . 10
3.3. Other Potential Factors . . . . . . . . . . . . . . . . . 11 3.5. Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 10
3.4. Common Literature Terminology . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
3.5. Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 12 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
Measuring the capacity of a link or network path is a task that Measuring the capacity of a link or network path is a task that
sounds simple, but in reality can be quite complex. Any physical sounds simple, but in reality can be quite complex. Any physical
medium requires that information be encoded and, depending on the medium requires that information be encoded and, depending on the
medium, there are various schemes to convert information into a medium, there are various schemes to convert information into a
sequence of signals that are transmitted physically from one location sequence of signals that are transmitted physically from one location
to another. to another.
skipping to change at page 4, line 28 skipping to change at page 3, line 28
frequency of a few gigahertz, but an information-carrying capacity of frequency of a few gigahertz, but an information-carrying capacity of
only a few hundred kilobits per second. Often similar or identical only a few hundred kilobits per second. Often similar or identical
terms are used to refer to these different applications of capacity, terms are used to refer to these different applications of capacity,
adding to the ambiguity and confusion, and the lack of a unified adding to the ambiguity and confusion, and the lack of a unified
nomenclature makes it difficult to properly build, test, and use nomenclature makes it difficult to properly build, test, and use
various techniques and tools. various techniques and tools.
We are interested in information-carrying capacity, but even this is We are interested in information-carrying capacity, but even this is
not straightforward. Each of the layers, depending on the medium, not straightforward. Each of the layers, depending on the medium,
adds overhead to the task of carrying information. The wired adds overhead to the task of carrying information. The wired
Ethernet uses Manchester coding or 4/5 coding which cuts down Ethernet uses Manchester coding or 4/5 coding, which cuts down
considerably on the "theoretical" capacity. Similarly RF (radio considerably on the "theoretical" capacity. Similarly, RF (radio
frequency) communications will often add redundancy to the coding frequency) communications will often add redundancy to the coding
scheme to implement forward error correction because the physical scheme to implement forward error correction because the physical
medium (air) is lossy. This can further decrease the information medium (air) is lossy. This can further decrease the information
capacity. capacity.
In addition to coding schemes, usually the physical layer and the In addition to coding schemes, usually the physical layer and the
link layer add framing bits for multiplexing and control purposes. link layer add framing bits for multiplexing and control purposes.
For example, on SONET there is physical layer framing and typically For example, on SONET there is physical-layer framing and typically
also some layer 2 framing such as HDLC, PPP or ATM. also some layer-2 framing such as High-Level Data Link Control
(HDLC), PPP, or ATM.
Aside from questions of coding efficiency, there are issues of how Aside from questions of coding efficiency, there are issues of how
access to the channel is controlled which also may affect the access to the channel is controlled, which also may affect the
capacity. For example, a multiple-access medium with collision capacity. For example, a multiple-access medium with collision
detection, avoidance and recovery mechanisms has a varying capacity detection, avoidance, and recovery mechanisms has a varying capacity
from the point of view of the users. This varying capacity depends from the point of view of the users. This varying capacity depends
upon the total number of users contending for the medium, how busy upon the total number of users contending for the medium, how busy
the users are, and bounds resulting from the mechanisms themselves. the users are, and bounds resulting from the mechanisms themselves.
RF channels are also varying capacity, depending on range, RF channels may also vary in capacity, depending on range,
environmental conditions, mobility and shadowing, etc. environmental conditions, mobility, shadowing, etc.
The important points to derive from this discussion are these: First, The important points to derive from this discussion are these: First,
capacity is only meaningful when defined relative to a given protocol capacity is only meaningful when defined relative to a given protocol
layer in the network. It is meaningless to speak of "link" capacity layer in the network. It is meaningless to speak of "link" capacity
without qualifying exactly what is meant. Second, capacity is not without qualifying exactly what is meant. Second, capacity is not
necessarily fixed, and consequently, a single measure of capacity at necessarily fixed, and consequently, a single measure of capacity at
whatever layer may in fact provide a skewed picture (either any layer may in fact provide a skewed picture (either optimistic or
optimistic or pessimistic) of what is actually available. pessimistic) of what is actually available.
2. Definitions 2. Definitions
In this section, we specify definitions for capacity. We begin by In this section, we specify definitions for capacity. We begin by
first defining "link" and "path" clearly and then we define a first defining "link" and "path" clearly, and then we define a
baseline capacity that is simply tied to the physical properties of baseline capacity that is simply tied to the physical properties of
the link. the link.
2.1. Links and Paths 2.1. Links and Paths
To define capacity, we need to broaden the notions of link and path To define capacity, we need to broaden the notions of link and path
found in the IPPM framework document [RFC2330] to include network found in the IP Performance Metrics (IPPM) framework document
devices that can impact IP capacity without being IP aware. For [RFC2330] to include network devices that can impact IP capacity
example, consider an Ethernet switch that can operate ports at without being IP aware. For example, consider an Ethernet switch
different speeds. that can operate ports at different speeds.
We define nodes as hosts, routers, Ethernet switches, or any other We define nodes as hosts, routers, Ethernet switches, or any other
device where the input and output links can have different device where the input and output links can have different
characteristics. A link is a connection between two of these network 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 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, ..., 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 Nn+1). A source S and destination D reside at N1 and Nn+1,
respectively. Furthermore, we define a link L as a special case respectively. Furthermore, we define a link L as a special case
where the path length is one. where the path length is one.
2.2. Definition: Nominal Physical Link Capacity 2.2. Definition: Nominal Physical Link Capacity
Nominal Physical Link Capacity, NomCap(L), is the theoretical maximum Nominal Physical Link Capacity, NomCap(L), is the theoretical maximum
amount of data that the link L can support. For example, an OC-3 amount of data that the link L can support. For example, an OC-3
link would be capable of 155.520 Mbps. We stress that this is a link would be capable of 155.520 Mbit/s. We stress that this is a
measurement at the physical layer and not the network IP layer, which measurement at the physical layer and not the network IP layer, which
we will define separately. While NomCap(L) is typically constant we will define separately. While NomCap(L) is typically constant
over time, there are links whose characteristics may allow otherwise, over time, there are links whose characteristics may allow otherwise,
such as the dynamic activation of additional transponders for a such as the dynamic activation of additional transponders for a
satellite link. satellite link.
The nominal physical link capacity is provided as a means to help The nominal physical link capacity is provided as a means to help
distinguish between the commonly used link layer capacities and the distinguish between the commonly used link-layer capacities and the
remaining definitions for IP layer capacity. As a result, the value remaining definitions for IP-layer capacity. As a result, the value
of NomCap(L) does not influence the other definitions presented in of NomCap(L) does not influence the other definitions presented in
this document. Instead, it provides an upper bound on those values. this document. Instead, it provides an upper bound on those values.
2.3. Capacity at the IP Layer 2.3. Capacity at the IP Layer
There are many factors that can reduce the IP information carrying There are many factors that can reduce the IP information carrying
capacity of the link, some of which have already been discussed in capacity of the link, some of which have already been discussed in
the introduction. However, the goal of this document is not to the introduction. However, the goal of this document is not to
become an exhaustive list of such factors. Rather, we outline some become an exhaustive list of such factors. Rather, we outline some
of the major examples in the following section, thus providing food of the major examples in the following section, thus providing food
for thought to those implementing the algorithms or tools that for thought to those implementing the algorithms or tools that
attempt to measure capacity accurately. attempt to measure capacity accurately.
The remaining definitions are all given in terms of "IP layer bits" The remaining definitions are all given in terms of "IP-layer bits"
in order to distinguish these definitions from the nominal physical in order to distinguish these definitions from the nominal physical
capacity of the link. capacity of the link.
2.3.1. Definition: IP Layer Bits 2.3.1. Definition: IP-layer Bits
IP layer bits are defined as eight (8) times the number of octets in IP-layer bits are defined as eight (8) times the number of octets in
all IP packets received, from the first octet of the IP header to the all IP packets received, from the first octet of the IP header to the
last octet of the IP packet payload, inclusive. last octet of the IP packet payload, inclusive.
IP layer bits are recorded at the destination, D, beginning at time T IP-layer bits are recorded at the destination D beginning at time T
and ending at a time T+I. Since the definitions are based on and ending at a time T+I. Since the definitions are based on
averages, the two time parameters, T and I, must accompany any report averages, the two time parameters, T and I, must accompany any report
or estimate of the following values in order for them to remain or estimate of the following values in order for them to remain
meaningful. It is not required that the interval boundary points meaningful. It is not required that the interval boundary points
fall between packet arrivals at D. However, boundaries that fall fall between packet arrivals at D. However, boundaries that fall
within a packet will invalidate the packets on which they fall. within a packet will invalidate the packets on which they fall.
Specifically, the data from the partial packet that is contained Specifically, the data from the partial packet that is contained
within the interval will not be counted. This may artificially bias within the interval will not be counted. This may artificially bias
some of the values, depending on the length of the interval and the some of the values, depending on the length of the interval and the
amount of data received during that interval. We elaborate on what amount of data received during that interval. We elaborate on what
constitutes correctly received data in the next section. constitutes correctly received data in the next section.
2.3.1.1. Standard or Correctly Formed Packets 2.3.1.1. Standard or Correctly Formed Packets
The definitions in this document specify that IP packets must be The definitions in this document specify that IP packets must be
received correctly. The IPPM framework recommends a set of criteria received correctly. The IPPM framework recommends a set of criteria
for such standard-formed packet in section 15 of [RFC2330]. However, for such standard-formed packets in Section 15 of [RFC2330].
it is inadequate for use with this document. Thus, we outline our However, it is inadequate for use with this document. Thus, we
own criteria below while pointing out any variations or similarities outline our own criteria below while pointing out any variations or
to [RFC2330]. similarities to [RFC2330].
First, data that is in error at layers below IP and cannot be First, data that is in error at layers below IP and cannot be
properly passed to the IP layer must not be counted. For example, properly passed to the IP layer must not be counted. For example,
wireless media often has a considerably larger error rate than wired wireless media often have a considerably larger error rate than wired
media, resulting in a reduction in IP Link Capacity. In accordance media, resulting in a reduction in IP link capacity. In accordance
with the IPPM framework, packets that fail validation of the IP with the IPPM framework, packets that fail validation of the IP
header must be discarded. Specifically, the requirements in header must be discarded. Specifically, the requirements in
[RFC1812] section 5.2.2 on IP header validation must be checked, [RFC1812], Section 5.2.2, on IP header validation must be checked,
which includes a valid length, checksum, and version field. which includes a valid length, checksum, and version field.
The IPPM framework specifies further restrictions, requiring that any The IPPM framework specifies further restrictions, requiring that any
transport header be checked for correctness and that any packets with transport header be checked for correctness and that any packets with
IP options be ignored. However, the definitions in this document are IP options be ignored. However, the definitions in this document are
concerned with the traversal of IP layer bits. As a result, data concerned with the traversal of IP-layer bits. As a result, data
from the higher layers is not required to be valid or understood as from the higher layers is not required to be valid or understood as
they are simply regarded as part of the IP packet. The same holds that data is simply regarded as part of the IP packet. The same
true for IP options. Valid IP fragments must also be counted as they holds true for IP options. Valid IP fragments must also be counted
expend the resources of a link even though assembly of the full as they expend the resources of a link even though assembly of the
packet may not be possible. The IPPM framework differs in this area, full packet may not be possible. The IPPM framework differs in this
discarding IP fragments. area, discarding IP fragments.
For a discussion of duplicates, please see Section 3.2. For a discussion of duplicates, please see Section 3.2.
In summary, any IP packet that can be properly processed must be In summary, any IP packet that can be properly processed must be
included in these calculations. included in these calculations.
2.3.1.2. Type P Packets 2.3.1.2. Type P Packets
The definitions in this document refer to "Type P" packets to The definitions in this document refer to "Type P" packets to
designate a particular type of flow or sets of flows. As defined in designate a particular type of flow or sets of flows. As defined in
RFC 2330, Section 13, "Type P" is a placeholder for what may be an RFC 2330, Section 13, "Type P" is a placeholder for what may be an
explicit specification of the packet flows referenced by the metric, explicit specification of the packet flows referenced by the metric,
or it may be a very loose specification encompassing aggregates. We or it may be a very loose specification encompassing aggregates. We
use the "Type P" designation in these definitions in order to use the "Type P" designation in these definitions in order to
emphasize two things: First, that the value of the capacity emphasize two things: First, that the value of the capacity
measurement depends on the types of flows referenced in the measurement depends on the types of flows referenced in the
definition. This is because networks may treat packets differently definition. This is because networks may treat packets differently
(in terms of queuing and scheduling) based on their markings and (in terms of queuing and scheduling) based on their markings and
classification. Networks may also arbitrarily decide to flow balance classification. Networks may also arbitrarily decide to flow-balance
based on the packet type or flow type and thereby affect capacity based on the packet type or flow type and thereby affect capacity
measurements. Second, the measurement of capacity depends not only measurements. Second, the measurement of capacity depends not only
on the type of the reference packets, but also on the types of the on the type of the reference packets, but also on the types of the
packets in the "population" with which the flows of interest share packets in the "population" with which the flows of interest share
the links in the path. the links in the path.
All of this indicates two different approaches to measuring: One is All of this indicates two different approaches to measuring: One is
to measure capacity using a broad spectrum of packet types, to measure capacity using a broad spectrum of packet types,
suggesting that "Type P" should be set as generic as possible. The suggesting that "Type P" should be set as generic as possible. The
second is to focus narrowly on the types of flows of particular second is to focus narrowly on the types of flows of particular
interest, which suggests that "Type P" should be very specific and interest, which suggests that "Type P" should be very specific and
narrowly defined. The first approach is likely to be of interest to narrowly defined. The first approach is likely to be of interest to
providers, the second to application users. providers, the second to application users.
As a practical matter, it should be noted that some providers may
treat packets with certain characteristics differently than other
packets. For example, access control lists, routing policies, and
other mechanisms may be used to filter ICMP packets or forward
packets with certain IP options through different routes. If a
capacity-measurement tool uses these special packets and they are
included in the "Type P" designation, the tool may not be measuring
the path that it was intended to measure. Tool authors, as well as
users, may wish to check this point with their service providers.
2.3.2. Definition: IP-type-P Link Capacity 2.3.2. Definition: IP-type-P Link Capacity
We define the IP layer link capacity, C(L,T,I), to be the maximum We define the IP-layer link capacity, C(L,T,I), to be the maximum
number of IP layer bits that can be transmitted from the source S and 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 correctly received by the destination D over the link L during the
interval [T, T+I], divided by I. interval [T, T+I], divided by I.
As mentioned earlier, this definition is affected by many factors
that may change over time. For example, a device's ability to
process and forward IP packets for a particular link may have varying
effect on capacity, depending on the amount or type of traffic being
processed.
2.3.3. Definition: IP-type-P Path Capacity 2.3.3. Definition: IP-type-P Path Capacity
Using our definition for link capacity, we can then extend this Using our definition for IP-layer link capacity, we can then extend
notion to an entire path, such that the IP layer path capacity simply this notion to an entire path, such that the IP-layer path capacity
becomes that of the link with the smallest capacity along that path. simply becomes that of the link with the smallest capacity along that
path.
C(P,T,I) = min {1..n} {C(Ln,T,I)} C(P,T,I) = min {1..n} {C(Ln,T,I)}
The previous definitions specify the number of IP layer bits that can The previous definitions specify the number of IP-layer bits that can
be transmitted across a link or path should the resource be free of be transmitted across a link or path should the resource be free of
any congestion. It represents the full capacity available for any congestion. It represents the full capacity available for
traffic between the source and destination. Determining how much traffic between the source and destination. Determining how much
capacity is available for use on a congested link is potentially much capacity is available for use on a congested link is potentially much
more useful. However, in order to define the available capacity we more useful. However, in order to define the available capacity, we
must first specify how much is being used. must first specify how much is being used.
2.3.4. Definition: IP-type-P Link Usage 2.3.4. Definition: IP-type-P Link Usage
The average usage of a link L, Used(L,T,I), is the actual number of The average usage of a link L, Used(L,T,I), is the actual number of
IP layer bits from any source, correctly received over link L during IP-layer bits from any source, correctly received over link L during
the interval [T, T+I], divided by I. the interval [T, T+I], divided by I.
An important distinction between usage and capacity is that An important distinction between usage and capacity is that
Used(L,T,I) is not the maximum number, but rather, the actual number Used(L,T,I) is not the maximum number, but rather, the actual number
of IP bits sent that are correctly received. The information of IP bits sent that are correctly received. The information
transmitted across the link can be generated by any source, including transmitted across the link can be generated by any source, including
those who may not be directly attached to either side of the link. those sources that may not be directly attached to either side of the
In addition, each information flow from these sources may share any link. In addition, each information flow from these sources may
number (from one to n) of links in the overall path between S and D. share any number (from one to n) of links in the overall path between
S and D.
2.3.5. Definition: IP-type-P Link Utilization 2.3.5. Definition: IP-type-P Link Utilization
We express usage as a fraction of the overall IP layer link capacity. 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) ) Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) )
Thus, the utilization now represents the fraction of the capacity Thus, the utilization now represents the fraction of the capacity
that is being used and is a value between zero, meaning nothing is that is being used and is a value between zero (meaning nothing is
used, and one, meaning the link is fully saturated. Multiplying the used) and one (meaning the link is fully saturated). Multiplying the
utilization by 100 yields the percent utilization of the link. By utilization by 100 yields the percent utilization of the link. By
using the above, we can now define the capacity available over the using the above, we can now define the capacity available over the
link as well as the path between S and D. Note that this is link as well as the path between S and D. Note that this is
essentially the definition in [PDM]. essentially the definition in [PDM].
2.3.6. Definition: IP-type-P Available Link Capacity 2.3.6. Definition: IP-type-P Available Link Capacity
We can now determine the amount of available capacity on a congested We can now determine the amount of available capacity on a congested
link by multiplying the IP layer link capacity with the complement of link by multiplying the IP-layer link capacity with the complement of
the IP layer link utilization. Thus, the IP layer available link the IP-layer link utilization. Thus, the IP-layer available link
capacity becomes: capacity becomes:
AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) ) AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) )
2.3.7. Definition: IP-type-P Available Path Capacity 2.3.7. Definition: IP-type-P Available Path Capacity
Using our definition for IP layer available link capacity, we can Using our definition for IP-layer available link capacity, we can
then extend this notion to an entire path, such that the IP layer then extend this notion to an entire path, such that the IP-layer
available path capacity simply becomes that of the link with the available path capacity simply becomes that of the link with the
smallest available capacity along that path. smallest available capacity along that path.
AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)} AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)}
Since measurements of available capacity are more volatile than that Since measurements of available capacity are more volatile than that
of capacity, we stress the importance that both the time and interval of link capacity, we stress the importance that both the time and
be specified as their values have a great deal of influence on the interval be specified as their values have a great deal of influence
results. In addition, a sequence of measurements may be beneficial on the results. In addition, a sequence of measurements may be
in offsetting the volatility when attempting to characterize beneficial in offsetting the volatility when attempting to
available capacity. characterize available capacity.
3. Discussion 3. Discussion
3.1. Time and Sampling 3.1. Time and Sampling
We must emphasize the importance of time in the basic definitions of We must emphasize the importance of time in the basic definitions of
these quantities. We know that traffic on the Internet is highly these quantities. We know that traffic on the Internet is highly
variable across all time scales. This argues that the time and variable across all time scales. This argues that the time and
length of measurements are critical variables in reporting available length of measurements are critical variables in reporting available
capacity measurements and must be reported when using these capacity measurements and must be reported when using these
skipping to change at page 11, line 26 skipping to change at page 9, line 26
The closer to "instantaneous" a metric is, the more important it is The closer to "instantaneous" a metric is, the more important it is
to have a plan for sampling the metric over a time period that is to have a plan for sampling the metric over a time period that is
sufficiently large. By doing so, we allow valid statistical sufficiently large. By doing so, we allow valid statistical
inferences to be made from the measurements. An obvious pitfall here inferences to be made from the measurements. An obvious pitfall here
is sampling in a way that causes bias. For example, a situation is sampling in a way that causes bias. For example, a situation
where the sampling frequency is a multiple of the frequency of an where the sampling frequency is a multiple of the frequency of an
underlying condition. underlying condition.
3.2. Hardware Duplicates 3.2. Hardware Duplicates
We briefly consider the impacts of paths where hardware duplication We briefly consider the effects of paths where hardware duplication
of packets may occur. In such an environment, a node in the network of packets may occur. In such an environment, a node in the network
path may duplicate packets and the destination may receive multiple, path may duplicate packets, and the destination may receive multiple,
identical copies of these packets. Both the original packet and the identical copies of these packets. Both the original packet and the
duplicates can be properly received and appear to be originating from duplicates can be properly received and appear to be originating from
the sender. Thus, in the most generic form, duplicate IP packets are the sender. Thus, in the most generic form, duplicate IP packets are
counted in these definitions. However, hardware duplication can counted in these definitions. However, hardware duplication can
impact these definitions depending on the use of "Type P" to add affect these definitions depending on the use of "Type P" to add
additional restrictions on packet reception. For instance, a additional restrictions on packet reception. For instance, a
restriction to only count uniquely sent packets may be more useful to restriction only to count uniquely-sent packets may be more useful to
users concerned with capacity for meaningful data. In contrast, the users concerned with capacity for meaningful data. In contrast, the
more general, unrestricted metric may be suitable for a user who is more general, unrestricted metric may be suitable for a user who is
concerned with raw capacity. Thus, it is up to the user to properly concerned with raw capacity. Thus, it is up to the user to properly
scope and interpret results in situations where hardware duplicates scope and interpret results in situations where hardware duplicates
may be prevalent. may be prevalent.
3.3. Other Potential Factors 3.3. Other Potential Factors
IP encapsulation does not impact the definitions as all IP header and IP encapsulation does not affect the definitions as all IP header and
payload bits must be counted regardless of content. However, payload bits must be counted regardless of content. However, IP
different sized IP packets can lead to a variation in the amount of packets of different sizes can lead to a variation in the amount of
overhead needed at the lower layers to transmit the data, thus overhead needed at the lower layers to transmit the data, thus
altering the overall IP link layer capacity. altering the overall IP link-layer capacity.
Should the link happen to employ a compression scheme such as ROHC Should the link happen to employ a compression scheme such as RObust
[RFC3095] or V.44 [V44], some of the original bits are not Header Compression (ROHC) [RFC3095] or V.44 [V44], some of the
transmitted across the link. However, the inflated (not compressed) original bits are not transmitted across the link. However, the
number of IP-layer bits should be counted. inflated (not compressed) number of IP-layer bits should be counted.
3.4. Common Literature Terminology 3.4. Common Terminology in Literature
Certain terms are often used to characterize specific aspects of the Certain terms are often used to characterize specific aspects of the
presented definitions. The link with the smallest capacity is presented definitions. The link with the smallest capacity is
commonly referred to as the "narrow link" of a path. Also, the link commonly referred to as the "narrow link" of a path. Also, the link
with the smallest available capacity is often referred to as the with the smallest available capacity is often referred to as the
"tight link" within a path. So, while Ln may have a very large "tight link" within a path. So, while a given link may have a very
capacity, the overall congestion level on the link makes it the large capacity, the overall congestion level on the link makes it the
likely bottleneck of a connection. Conversely, a link that has the likely bottleneck of a connection. Conversely, a link that has the
smallest capacity may not be a bottleneck should it be lightly loaded smallest capacity may not be the bottleneck should it be lightly
in relation to the rest of the path. loaded in relation to the rest of the path.
Also, common literature often overloads the term "bandwidth" to refer Also, literature often overloads the term "bandwidth" to refer to
to what we have described as capacity in this document. For example, what we have described as capacity in this document. For example,
when inquiring about the bandwidth of a 802.11b link, a network when inquiring about the bandwidth of a 802.11b link, a network
engineer will likely answer with 11 Mbps. However, an electrical engineer will likely answer with 11 Mbit/s. However, an electrical
engineer may answer with 25 MHz, and an end user may tell you that engineer may answer with 25 MHz, and an end user may tell you that
his observed bandwidth is 8 Mbps. In contrast, the term capacity is his observed bandwidth is 8 Mbit/s. In contrast, the term "capacity"
not quite as overloaded and is an appropriate term that better is not quite as overloaded and is an appropriate term that better
reflects what is actually being measured. reflects what is actually being measured.
3.5. Comparison to Bulk Transfer Capacity (BTC) 3.5. Comparison to Bulk Transfer Capacity (BTC)
Bulk Transfer Capacity (BTC) [RFC3184] provides a distinct Bulk Transfer Capacity (BTC) [RFC3148] provides a distinct
perspective on path capacity that differs from the definitions in perspective on path capacity that differs from the definitions in
this document in several fundamental ways. First, BTC operates at this document in several fundamental ways. First, BTC operates at
the transport layer, gauging the amount of capacity available to an the transport layer, gauging the amount of capacity available to an
application that wishes to send data. Only unique data is measured, application that wishes to send data. Only unique data is measured,
meaning header and retransmitted data are not included in the meaning header and retransmitted data are not included in the
calculation. In contrast, IP layer link capacity includes the IP calculation. In contrast, IP-layer link capacity includes the IP
header and is indifferent to the uniqueness of the data contained header and is indifferent to the uniqueness of the data contained
within the packet payload (Hardware duplication of packets is an within the packet payload. (Hardware duplication of packets is an
anomaly addressed in the previous section). Second, BTC utilizes a anomaly addressed in a previous section.) Second, BTC utilizes a
single congestion aware transport connection, such as TCP, to obtain single congestion-aware transport connection, such as TCP, to obtain
measurements. As a result, BTC implementations react strongly to measurements. As a result, BTC implementations react strongly to
different path characteristics, topologies, and distances. Since different path characteristics, topologies, and distances. Since
these differences can affect the control loop (propagation delays, these differences can affect the control loop (propagation delays,
segment reordering, etc), the reaction is further dependent on the segment reordering, etc.), the reaction is further dependent on the
algorithms being employed for the measurements. For example, algorithms being employed for the measurements. For example,
consider a single event where a link suffers a large duration of bit consider a single event where a link suffers a large duration of bit
errors. The event could cause IP layer packets to be discarded, and errors. The event could cause IP-layer packets to be discarded, and
the lost packets would reduce the IP layer link capacity. However, the lost packets would reduce the IP-layer link capacity. However,
the same event and subsequent losses would trigger loss recovery for the same event and subsequent losses would trigger loss recovery for
a BTC measurement resulting in the retransmission of data and a a BTC measurement resulting in the retransmission of data and a
potentially reduced sending rate. Thus, a measurement of BTC does potentially reduced sending rate. Thus, a measurement of BTC does
not correspond to any of the definitions in this document. Both not correspond to any of the definitions in this document. Both
techniques are useful in exploring the characteristics of a network techniques are useful in exploring the characteristics of a network
path, but from different perspectives. path, but from different perspectives.
4. IANA Considerations 4. Security Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
This document specifies definitions regarding IP traffic traveling This document specifies definitions regarding IP traffic traveling
between a source and destination in an IP network. These definitions between a source and destination in an IP network. These definitions
do not raise any security issues and do not have a direct impact on do not raise any security issues and do not have a direct impact on
the networking protocol suite. the networking protocol suite.
Tools that attempt to implement these definitions may introduce Tools that attempt to implement these definitions may introduce
security issues specific to each implementation. Both active and security issues specific to each implementation. Both active and
passive measurement techniques can be abused, impacting the security, passive measurement techniques can be abused, impacting the security,
privacy, and performance of the network. Any measurement techniques privacy, and performance of the network. Any measurement techniques
based upon these definitions must include a discussion of the based upon these definitions must include a discussion of the
techniques needed to protect the network on which the measurements techniques needed to protect the network on which the measurements
are being performed. are being performed.
6. Conclusion 5. Conclusion
In this document, we have defined a set of quantities related to the In this document, we have defined a set of quantities related to the
capacity of links and paths in an IP network. In these definitions, capacity of links and paths in an IP network. In these definitions,
we have tried to be as clear as possible and take into account we have tried to be as clear as possible and take into account
various characteristics that links and paths can have. The goal of various characteristics that links and paths can have. The goal of
these definitions is to enable researchers who propose capacity these definitions is to enable researchers who propose capacity
metrics to relate those metrics to these definitions and to evaluate metrics to relate those metrics to these definitions and to evaluate
those metrics with respect to how well they approximate these those metrics with respect to how well they approximate these
quantities. quantities.
In addition, we have pointed out some key auxiliary parameters and In addition, we have pointed out some key auxiliary parameters and
opened a discussion of issues related to valid inferences from opened a discussion of issues related to valid inferences from
available capacity metrics. available capacity metrics.
7. Acknowledgments 6. Acknowledgments
The authors would like to acknowledge Mark Allman, Patrik Arlos, Matt The authors would like to acknowledge Mark Allman, Patrik Arlos, Matt
Mathis, Al Morton, Stanislav Shalunov, and Matt Zekauskas for their Mathis, Al Morton, Stanislav Shalunov, and Matt Zekauskas for their
suggestions, comments, and reviews. We also thank members of the suggestions, comments, and reviews. We also thank members of the
IETF IPPM Mailing List for their discussions and feedback on this IETF IPPM Mailing List for their discussions and feedback on this
document. document.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
May 1998. May 1998.
8.2. Informative References 7.2. Informative References
[PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet [PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet
Dispersion Techniques and a Capacity Estimation Dispersion Techniques and a Capacity Estimation
Methodology", IEEE/ACM Transactions on Networking 12(6): Methodology", IEEE/ACM Transactions on Networking 12(6):
963-977, December 2004. 963-977, December 2004.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
[RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
RFC 3184, October 2001. Empirical Bulk Transfer Capacity Metrics", RFC 3148,
July 2001.
[V44] ITU Telecommunication Standardization Sector (ITU-T) [V44] ITU Telecommunication Standardization Sector (ITU-T)
Recommendation V.44, "Data Compression Procedures", Recommendation V.44, "Data Compression Procedures",
November 2000. November 2000.
Authors' Addresses Authors' Addresses
Phil Chimento Phil Chimento
JHU Applied Physics Lab JHU Applied Physics Lab
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, Maryland 20723-6099 Laurel, Maryland 20723-6099
USA USA
Phone: +1-240-228-1743 Phone: +1-240-228-1743
Fax: +1-240-228-0789 Fax: +1-240-228-0789
Email: Philip.Chimento@jhuapl.edu EMail: Philip.Chimento@jhuapl.edu
Joseph Ishac Joseph Ishac
NASA Glenn Research Center NASA Glenn Research Center
21000 Brookpark Road 21000 Brookpark Road, MS 54-5
Cleveland, Ohio 44135 Cleveland, Ohio 44135
USA USA
Phone: +1-216-433-6587 Phone: +1-216-433-6587
Fax: +1-216-433-8705 Fax: +1-216-433-8705
Email: jishac@grc.nasa.gov EMail: jishac@nasa.gov
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 20, line 44 skipping to change at line 571
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 69 change blocks. 
179 lines changed or deleted 157 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/