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/