--- 1/draft-ietf-ippm-bw-capacity-00.txt 2006-02-04 17:19:05.000000000 +0100 +++ 2/draft-ietf-ippm-bw-capacity-01.txt 2006-02-04 17:19:05.000000000 +0100 @@ -1,19 +1,19 @@ IP Performance Metrics Working P. Chimento Group JHU Applied Physics Lab Internet-Draft J. Ishac -Expires: December 23, 2005 NASA Glenn Research Center - June 21, 2005 +Expires: May 13, 2006 NASA Glenn Research Center + November 9, 2005 Defining Network Capacity - draft-ietf-ippm-bw-capacity-00 + draft-ietf-ippm-bw-capacity-01 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 @@ -24,21 +24,21 @@ 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 23, 2005. + This Internet-Draft will expire on May 13, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, @@ -48,37 +48,40 @@ destination in an IP network. By doing so, we hope to build a common language that can be used when discussing and analyzing a diverse set of current and future estimation techniques. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1 Common Literature Terminology . . . . . . . . . . . . . . 7 - 3.2 Type P Packets . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1 Standard or Correctly Formed Packets . . . . . . . . . . . 8 + 3.2 Other Potential Factors . . . . . . . . . . . . . . . . . 8 + 3.3 Common Literature Terminology . . . . . . . . . . . . . . 9 + 3.4 Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 9 + 3.5 Type P Packets . . . . . . . . . . . . . . . . . . . . . . 10 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 7.1 Normative References . . . . . . . . . . . . . . . . . . . 12 - 7.2 Informative References . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 14 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . 16 1. Introduction Measuring the capacity of a link or network path is a task that sounds simple, but in reality can be quite complex. Any physical medium requires that information be encoded and, depending on the medium, there are various schemes to convert information into a sequence of signals that are transmitted physically from one location to another. @@ -142,60 +145,68 @@ There are many factors that can reduce the information carrying capacity of the link, some of which have already been discussed earlier in the introduction. However, the goal of this document is not to become an exhaustive list of of such factors. Rather, we outline some of the major examples in the following section, thus providing food for thought to those implementing the algorithms or tools that attempt to accurately quantify these values. The remaining definitions are all given in terms of "IP layer bits" in order to distinguish these definitions from the nominal physical - capacity of the link. Also, given a time T and a time interval I, we - define a path P of length n as a series of links (L1, L2, ..., Ln) - connecting a sequence of nodes (N1, N2, ..., Nn+1). A source S and - destination D reside at N1 and Nn+1 respectively. Furthermore, we - define a link L as a special case where the path size is one. + capacity of the link. IP layer bits: Eight (8) times the number of octets in all IP packets received, from the first octet of the IP header to the last octet of the IP packet payload, inclusive. - The definitions are also defined as an average, not as an - instantaneous value. Thus, the time parameters, T and I, must - accompany any report or estimate of the following values in order for - them to remain meaningful. + We then define a path P of length n as a series of links (L1, L2, + ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A + source, S, and destination, D, reside at N1 and Nn+1 respectively. + Furthermore, we define a link L as a special case where the path size + is one. 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 averages, the two time parameters, T and I, must accompany any + report or estimate of the following values in order for them to + remain meaningful. It is not required that the interval boundary + points fall between packet arrivals at D. However, boundaries that + fall within a packet will invalidate the packets on which they fall. + Specifically, the data from the partial packet that is contained + within the interval will not be counted. This may artificially bias + some of the values, depending on the length of the interval and the + amount of data received during that interval. We elaborate on what + constitutes correctly received data in the next section. IP Layer Link Capacity: 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 S and - correctly received by D over the link L during the interval T to - T+I, divided by I. + correctly received by D over the link L during the interval [T, + T+I], divided by I. Using this, we can then extend this notion to an entire path, such that the IP layer path capacity simply becomes that of the link with the smallest capacity along that path. IP Layer Path Capacity: C(P,T,I) = min {1..n} {C(Ln,T,I)} The previous definitions specify a link's capacity, namely the IP information bits that can be transmitted across a link or path should the resource be free of any contention. Determining how much capacity is available for use on a congested link is potentially much more useful. However, in order to define the available capacity we must first specify how much is being used. IP Layer Link Usage: The average usage of a link L, Used(L,T,I), is the actual number of IP layer bits correctly transmitted from any source over link L - from time T to time T+I, divided by I. + during the interval [T, T+I], divided by I. An important distinction between usage and capacity is that Used(L,T,I) is not the maximum amount, but rather, the actual amount of IP bits that are sent. The information transmitted across the link can be generated by any source, including those who may not be directly attached to either side of the link. In addition, each information flow from these sources may share any number (from one to n) of links in the overall path between S and D. Next, we express usage as a fraction of the overall IP layer link capacity. @@ -218,32 +229,55 @@ Since measurements of available capacity are more volatile that that of capacity, it is important that both the time and interval be specified as their values have a great deal of influence on the results. In addition, a range of measurements may be beneficial in offsetting the volatility when attempting to characterize available capacity. 3. Discussion - The base definitions specify that the IP layer packets must be - received correctly. This is deliberate, because of the possible - presence of lossy multiple-access media. On optical media, at a - nominal bit error rate of 10**-15, a stream transmitted at 10 Gbps - will experience an error about every 1 2/3 weeks on the average. On - wireless media, the error rate is considerably larger than that, - reducing the effective capacity accordingly. Note that the reception - of a partial packet cannot be checked for correctness, and - consequently the definitions count as capacity only bits received as - part of whole IP packets. +3.1 Standard or Correctly Formed Packets - The base definitions also make no mention of hardware duplication of + The definitions in this document specify that IP packets must be + received correctly. The IPPM framework recommends a set of criteria + for such standard-formed packet in section 15 of [RFC2330]. However, + it is inadequate for use with this document. Thus, we outline our + own criteria below while pointing out any variations or similarities + to [RFC2330]. + + First, data that is in error at layers below IP and cannot be + properly passed to the IP layer should not be counted. For example, + wireless media often has a considerably large error rate, resulting + in a reduction in IP Link Capacity. In accordance with the + framework, packets that fail validation of the IP header should be + discarded. Specifically, the requirements in [RFC1812] section 5.2.2 + on IP header validation should be checked, which includes a valid + length, checksum, and version field. + + The framework makes further restrictions, requiring that any + transport header be checked for correctness and that any packets with + IP options be ignored. However, the definitions in this document are + 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 + they are simply regarded as part of the IP packet. The same holds + true for IP options. Valid IP fragments should also be counted as + they expend the resources of a link even though assembly of the full + packet may not be possible. The framework differs in this area, + discarding IP fragments. + + In summary, any IP packet that can be properly processed should be + included in these calculations. + +3.2 Other Potential Factors + + The base definitions make no mention of hardware duplication of packets. While hardware duplication has no impact on the nominal capacity, it can impact the IP link layer capacity. For example, consider a link which can normally carry a capacity of 2X on average. However, the link has developed a syndrome where it duplicates every incoming packet. The link would still technically carry a capacity of 2X, however the link has a effective capacity of X or lower, depending on framing overhead to send the duplicates, etc. Thus, a value for C(L,T,I) and AvailCap(L,T,I) will reflect the duplication with the lower value. @@ -251,42 +285,70 @@ payload bits should be counted regardless of content. However, different sized IP packets can lead to a variation in the amount of overhead needed at the lower layers to transmit the data, thus altering the overall IP link layer capacity. Should the link happen to employ a compression scheme such as ROHC [RFC3095] or V.44 [V44], some of the original bits are not transmitted across the link. However, the inflated (not compressed) number of IP-layer bits should be counted. -3.1 Common Literature Terminology +3.3 Common Literature Terminology Certain terms are often used to characterize specific aspects of the presented definitions. The link with the smallest capacity is commonly referred to as the "narrow link" of a path. Also, the value of n that satisfies AvailCap(P,T,I), is often referred to as the "tight link" within a path. So, while Ln may have a very large capacity, the overall congestion level on the link makes it the likely bottleneck of a connection. Conversely, a link that has the smallest capacity may not be a bottleneck should it be lightly congested in relation to the rest of the path. Also, common literature often overloads the term "bandwidth" to refer to what we have described as capacity in this document. For example, when inquiring about the bandwidth of a 802.11b link, a network engineer will likely answer with 11 Mbps. However, an electrical 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 not quite as overloaded and is an appropriate term that better reflects what is actually being measured. -3.2 Type P Packets +3.4 Comparison to Bulk Transfer Capacity (BTC) + + Bulk Transfer Capacity (BTC) [RFC3148] provides a distinct + perspective on path capacity that differs from the definitions in + this document in several fundamental ways. First, BTC operates at + the transport layer, gauging the amount of capacity available to an + application that wishes to send data. Only unique data is measured, + meaning header and retransmitted data are not included in the + calculation. In contrast, IP layer link capacity includes the IP + header and is indifferent to the uniqueness of the data contained + within the packet payload (Hardware duplication of packets is an + anomaly addressed in the previous section). Second, BTC utilizes a + single congestion aware transport connection, such as TCP, to obtain + measurements. As a result, BTC implementations react strongly to + different path characteristics, topologies, and distances. Since + these differences can affect the control loop (propagation delays, + segment reordering, etc), the reaction is further dependent on the + algorithms being employed for the measurements. For example, + 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 + the lost packets would reduce the IP layer link capacity. However, + the same event and subsequent losses would trigger loss recovery for + a BTC measurement resulting in the retransmission of data and a + potentially reduced sending rate. Thus, a measurement of BTC does + not correspond to any of the definitions in this document. Both + techniques are useful in exploring the characteristics of a network + path, but from different perspectives. + +3.5 Type P Packets Note that these definitions do not make mention of "Type P" packets, while other IPPM definitions do. We could add the packet type as an extra parameter. This would have the effect of defining a large number of quantities, relative to the QoS policies that a given network or concatenation of networks may have in effect in the path. It would produce metrics such as "estimated EF IP Link/Path Capacity". Such metrics may indeed be useful. For example, this would yield @@ -309,43 +371,59 @@ 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 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 the networking protocol suite. -6. Acknowledgements +6. Acknowledgments + + The authors would like to acknowledge Mark Allman, Matt Mathis, Al + Morton, and Stas Shalunov for their suggestions, comments, and + reviews. We also thank members of the IETF IPPM Mailing List for + their discussions and feedback on this document. 7. References 7.1 Normative References 7.2 Informative References [PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet Dispersion Techniques and a Capacity Estimation Methodology", IEEE/ACM Transactions on Networking 12(6): 963-977, December 2004. + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", + RFC 1812, June 1995. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, + "Framework for IP Performance Metrics", RFC 2330, + May 1998. + [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. + [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining + Empirical Bulk Transfer Capacity Metrics", RFC 3148, + July 2001. + [V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44, "Data Compression Procedures", November 2000. Authors' Addresses Phil Chimento JHU Applied Physics Lab 11100 Johns Hopkins Road Laurel, Maryland 20723-6099