idnits 2.17.1 draft-ietf-ippm-bw-capacity-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 468. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 2005) is 6715 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 402, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Performance Metrics Working P. Chimento 3 Group JHU Applied Physics Lab 4 Internet-Draft J. Ishac 5 Expires: May 13, 2006 NASA Glenn Research Center 6 November 9, 2005 8 Defining Network Capacity 9 draft-ietf-ippm-bw-capacity-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 13, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Measuring capacity is a task that sounds simple, but in reality can 43 be quite complex. In addition, the lack of a unified nomenclature on 44 this subject makes it increasingly difficult to properly build, test, 45 and use techniques and tools built around these constructs. This 46 document provides definitions for the terms 'Capacity' and 'Available 47 Capacity' related to IP traffic traveling between a source and 48 destination in an IP network. By doing so, we hope to build a common 49 language that can be used when discussing and analyzing a diverse set 50 of current and future estimation techniques. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.1 Standard or Correctly Formed Packets . . . . . . . . . . . 8 60 3.2 Other Potential Factors . . . . . . . . . . . . . . . . . 8 61 3.3 Common Literature Terminology . . . . . . . . . . . . . . 9 62 3.4 Comparison to Bulk Transfer Capacity (BTC) . . . . . . . . 9 63 3.5 Type P Packets . . . . . . . . . . . . . . . . . . . . . . 10 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7.1 Normative References . . . . . . . . . . . . . . . . . . . 14 73 7.2 Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 77 Intellectual Property and Copyright Statements . . . . . . . . 16 79 1. Introduction 81 Measuring the capacity of a link or network path is a task that 82 sounds simple, but in reality can be quite complex. Any physical 83 medium requires that information be encoded and, depending on the 84 medium, there are various schemes to convert information into a 85 sequence of signals that are transmitted physically from one location 86 to another. 88 While on some media, the maximum frequency of these signals can be 89 thought of as "capacity", on other media, the signal transmission 90 frequency and the information capacity of the medium (channel) may be 91 quite different. For example, a satellite channel may have a carrier 92 frequency of a few gigahertz, but an information-carrying capacity of 93 only a few hundred kilobits per second. Often similar or identical 94 terms are used to refer to these different applications adding to the 95 ambiguity and confusion, and the lack of a unified nomenclature makes 96 it difficult to properly build, test, and use various techniques and 97 tools. 99 We are interested in information-carrying capacity, but even this is 100 not straightforward. Each of the layers, depending on the medium, 101 adds overhead to the task of carrying information. The wired 102 Ethernet uses Manchester coding or 4/5 coding which cuts down 103 considerably on the "theoretical" capacity. Similarly RF (radio 104 frequency) communications will often add redundancy to the coding 105 scheme to implement forward error correction because the physical 106 medium (air) is lossy. This can further decrease the information 107 efficiency. 109 In addition to coding schemes, usually the physical layer and the 110 link layer add framing bits for multiplexing and control purposes. 111 For example, on SONET there is physical layer framing and typically 112 also some layer 2 framing such as HDLC, PPP or even ATM. 114 Aside from questions of coding efficiency, there are issues of how 115 access to the channel is controlled which may affect the capacity 116 also. For example, a multiple-access medium with collision 117 detection, avoidance and recovery mechanisms has a varying capacity 118 from the point of view of the users. This varying capacity depends 119 upon the total number of users contending for the medium, how busy 120 the users are, and bounds resulting from the mechanisms themselves. 121 RF channels are also varying capacity, depending on range, 122 environmental conditions, mobility and shadowing, etc. 124 The important points to derive from this discussion are these: First, 125 capacity is only meaningful when defined relative to a given protocol 126 layer in the network. It is meaningless to speak of "link" capacity 127 without qualifying exactly what is meant. Second, capacity is not 128 necessarily fixed, and consequently, a single measure of capacity at 129 whatever layer may in fact provide a skewed picture (either 130 optimistic or pessimistic) of what is actually available. 132 2. Definitions 134 In this section, we specify definitions for capacity. We begin by 135 first defining a baseline capacity that is simply tied to the 136 physical properties of the link. 138 Nominal Physical Link Capacity: 139 Or NomCap(L) is the theoretical maximum amount of data that the 140 link can support. For example, an OC-3 link would be capable of 141 roughly 155 Mbps and does not vary with time. We stress that this 142 is a measurement at the physical layer and not the network IP 143 layer, which we will define separately. 145 There are many factors that can reduce the information carrying 146 capacity of the link, some of which have already been discussed 147 earlier in the introduction. However, the goal of this document is 148 not to become an exhaustive list of of such factors. Rather, we 149 outline some of the major examples in the following section, thus 150 providing food for thought to those implementing the algorithms or 151 tools that attempt to accurately quantify these values. 153 The remaining definitions are all given in terms of "IP layer bits" 154 in order to distinguish these definitions from the nominal physical 155 capacity of the link. 157 IP layer bits: 158 Eight (8) times the number of octets in all IP packets received, 159 from the first octet of the IP header to the last octet of the IP 160 packet payload, inclusive. 162 We then define a path P of length n as a series of links (L1, L2, 163 ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A 164 source, S, and destination, D, reside at N1 and Nn+1 respectively. 165 Furthermore, we define a link L as a special case where the path size 166 is one. IP layer bits are recorded at the destination, D, beginning 167 at time T and ending at a time T+I. Since the definitions are based 168 on averages, the two time parameters, T and I, must accompany any 169 report or estimate of the following values in order for them to 170 remain meaningful. It is not required that the interval boundary 171 points fall between packet arrivals at D. However, boundaries that 172 fall within a packet will invalidate the packets on which they fall. 173 Specifically, the data from the partial packet that is contained 174 within the interval will not be counted. This may artificially bias 175 some of the values, depending on the length of the interval and the 176 amount of data received during that interval. We elaborate on what 177 constitutes correctly received data in the next section. 179 IP Layer Link Capacity: 180 We define the IP Layer link capacity, C(L,T,I), to be the maximum 181 number of IP layer bits that can be transmitted from S and 182 correctly received by D over the link L during the interval [T, 183 T+I], divided by I. 185 Using this, we can then extend this notion to an entire path, such 186 that the IP layer path capacity simply becomes that of the link with 187 the smallest capacity along that path. 189 IP Layer Path Capacity: 190 C(P,T,I) = min {1..n} {C(Ln,T,I)} 192 The previous definitions specify a link's capacity, namely the IP 193 information bits that can be transmitted across a link or path should 194 the resource be free of any contention. Determining how much 195 capacity is available for use on a congested link is potentially much 196 more useful. However, in order to define the available capacity we 197 must first specify how much is being used. 199 IP Layer Link Usage: 200 The average usage of a link L, Used(L,T,I), is the actual number 201 of IP layer bits correctly transmitted from any source over link L 202 during the interval [T, T+I], divided by I. 204 An important distinction between usage and capacity is that 205 Used(L,T,I) is not the maximum amount, but rather, the actual amount 206 of IP bits that are sent. The information transmitted across the 207 link can be generated by any source, including those who may not be 208 directly attached to either side of the link. In addition, each 209 information flow from these sources may share any number (from one to 210 n) of links in the overall path between S and D. Next, we express 211 usage as a fraction of the overall IP layer link capacity. 213 Average IP Layer Link Utilization: 214 Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ) 216 Thus, the utilization now represents the fraction of the capacity 217 that is being used and is a value between zero, meaning nothing is 218 used, and one, meaning the link is fully saturated. Multiplying the 219 utilization by 100 yields the percent utilization of the link. By 220 using the above, we can now define the capacity available over the 221 link as well as the path between S and D. Note that this is 222 essentially the definition in [PDM]. 224 IP Layer Available Link Capacity 225 AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) ) 227 IP Layer Available Path Capacity 228 AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)} 230 Since measurements of available capacity are more volatile that that 231 of capacity, it is important that both the time and interval be 232 specified as their values have a great deal of influence on the 233 results. In addition, a range of measurements may be beneficial in 234 offsetting the volatility when attempting to characterize available 235 capacity. 237 3. Discussion 239 3.1 Standard or Correctly Formed Packets 241 The definitions in this document specify that IP packets must be 242 received correctly. The IPPM framework recommends a set of criteria 243 for such standard-formed packet in section 15 of [RFC2330]. However, 244 it is inadequate for use with this document. Thus, we outline our 245 own criteria below while pointing out any variations or similarities 246 to [RFC2330]. 248 First, data that is in error at layers below IP and cannot be 249 properly passed to the IP layer should not be counted. For example, 250 wireless media often has a considerably large error rate, resulting 251 in a reduction in IP Link Capacity. In accordance with the 252 framework, packets that fail validation of the IP header should be 253 discarded. Specifically, the requirements in [RFC1812] section 5.2.2 254 on IP header validation should be checked, which includes a valid 255 length, checksum, and version field. 257 The framework makes further restrictions, requiring that any 258 transport header be checked for correctness and that any packets with 259 IP options be ignored. However, the definitions in this document are 260 concerned with the traversal of IP layer bits. As a result, data 261 from the higher layers is not required to be valid or understood as 262 they are simply regarded as part of the IP packet. The same holds 263 true for IP options. Valid IP fragments should also be counted as 264 they expend the resources of a link even though assembly of the full 265 packet may not be possible. The framework differs in this area, 266 discarding IP fragments. 268 In summary, any IP packet that can be properly processed should be 269 included in these calculations. 271 3.2 Other Potential Factors 273 The base definitions make no mention of hardware duplication of 274 packets. While hardware duplication has no impact on the nominal 275 capacity, it can impact the IP link layer capacity. For example, 276 consider a link which can normally carry a capacity of 2X on average. 277 However, the link has developed a syndrome where it duplicates every 278 incoming packet. The link would still technically carry a capacity 279 of 2X, however the link has a effective capacity of X or lower, 280 depending on framing overhead to send the duplicates, etc. Thus, a 281 value for C(L,T,I) and AvailCap(L,T,I) will reflect the duplication 282 with the lower value. 284 IP encapsulation does not impact the definitions as all IP header and 285 payload bits should be counted regardless of content. However, 286 different sized IP packets can lead to a variation in the amount of 287 overhead needed at the lower layers to transmit the data, thus 288 altering the overall IP link layer capacity. 290 Should the link happen to employ a compression scheme such as ROHC 291 [RFC3095] or V.44 [V44], some of the original bits are not 292 transmitted across the link. However, the inflated (not compressed) 293 number of IP-layer bits should be counted. 295 3.3 Common Literature Terminology 297 Certain terms are often used to characterize specific aspects of the 298 presented definitions. The link with the smallest capacity is 299 commonly referred to as the "narrow link" of a path. Also, the value 300 of n that satisfies AvailCap(P,T,I), is often referred to as the 301 "tight link" within a path. So, while Ln may have a very large 302 capacity, the overall congestion level on the link makes it the 303 likely bottleneck of a connection. Conversely, a link that has the 304 smallest capacity may not be a bottleneck should it be lightly 305 congested in relation to the rest of the path. 307 Also, common literature often overloads the term "bandwidth" to refer 308 to what we have described as capacity in this document. For example, 309 when inquiring about the bandwidth of a 802.11b link, a network 310 engineer will likely answer with 11 Mbps. However, an electrical 311 engineer may answer with 25 MHz, and an end user may tell you that 312 his observed bandwidth is 8 Mbps. In contrast, the term capacity is 313 not quite as overloaded and is an appropriate term that better 314 reflects what is actually being measured. 316 3.4 Comparison to Bulk Transfer Capacity (BTC) 318 Bulk Transfer Capacity (BTC) [RFC3148] provides a distinct 319 perspective on path capacity that differs from the definitions in 320 this document in several fundamental ways. First, BTC operates at 321 the transport layer, gauging the amount of capacity available to an 322 application that wishes to send data. Only unique data is measured, 323 meaning header and retransmitted data are not included in the 324 calculation. In contrast, IP layer link capacity includes the IP 325 header and is indifferent to the uniqueness of the data contained 326 within the packet payload (Hardware duplication of packets is an 327 anomaly addressed in the previous section). Second, BTC utilizes a 328 single congestion aware transport connection, such as TCP, to obtain 329 measurements. As a result, BTC implementations react strongly to 330 different path characteristics, topologies, and distances. Since 331 these differences can affect the control loop (propagation delays, 332 segment reordering, etc), the reaction is further dependent on the 333 algorithms being employed for the measurements. For example, 334 consider a single event where a link suffers a large duration of bit 335 errors. The event could cause IP layer packets to be discarded, and 336 the lost packets would reduce the IP layer link capacity. However, 337 the same event and subsequent losses would trigger loss recovery for 338 a BTC measurement resulting in the retransmission of data and a 339 potentially reduced sending rate. Thus, a measurement of BTC does 340 not correspond to any of the definitions in this document. Both 341 techniques are useful in exploring the characteristics of a network 342 path, but from different perspectives. 344 3.5 Type P Packets 346 Note that these definitions do not make mention of "Type P" packets, 347 while other IPPM definitions do. We could add the packet type as an 348 extra parameter. This would have the effect of defining a large 349 number of quantities, relative to the QoS policies that a given 350 network or concatenation of networks may have in effect in the path. 351 It would produce metrics such as "estimated EF IP Link/Path 352 Capacity". 354 Such metrics may indeed be useful. For example, this would yield 355 something like the sum of the capacities of all the QoS classes 356 defined along the path as the link or path capacity. The breakdown 357 then gives the user an analysis of how the link or path capacity (or 358 at least the "tight link" capacity) is allocated among classes. 360 These QoS-based capacities become difficult to measure on a path if 361 there are different capacities defined per QoS class on different 362 links in the path. Possibly the best way to approach this would be 363 to measure each link in a path individually, and then combine the 364 information from individual links. However, such an approach is 365 extremely difficult in practice. 367 4. IANA Considerations 369 This document makes no request of IANA. 371 Note to RFC Editor: this section may be removed on publication as an 372 RFC. 374 5. Security Considerations 376 This document specifies definitions regarding IP traffic traveling 377 between a source and destination in an IP network. These definitions 378 do not raise any security issues and do not have a direct impact on 379 the networking protocol suite. 381 6. Acknowledgments 383 The authors would like to acknowledge Mark Allman, Matt Mathis, Al 384 Morton, and Stas Shalunov for their suggestions, comments, and 385 reviews. We also thank members of the IETF IPPM Mailing List for 386 their discussions and feedback on this document. 388 7. References 390 7.1 Normative References 392 7.2 Informative References 394 [PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet 395 Dispersion Techniques and a Capacity Estimation 396 Methodology", IEEE/ACM Transactions on Networking 12(6): 397 963-977, December 2004. 399 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 400 RFC 1812, June 1995. 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 406 "Framework for IP Performance Metrics", RFC 2330, 407 May 1998. 409 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 410 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 411 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 412 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 413 Compression (ROHC): Framework and four profiles: RTP, UDP, 414 ESP, and uncompressed", RFC 3095, July 2001. 416 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 417 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 418 July 2001. 420 [V44] ITU Telecommunication Standardization Sector (ITU-T) 421 Recommendation V.44, "Data Compression Procedures", 422 November 2000. 424 Authors' Addresses 426 Phil Chimento 427 JHU Applied Physics Lab 428 11100 Johns Hopkins Road 429 Laurel, Maryland 20723-6099 430 USA 432 Phone: +1-240-228-1743 433 Fax: +1-240-228-0789 434 Email: Philip.Chimento@jhuapl.edu 436 Joseph Ishac 437 NASA Glenn Research Center 438 21000 Brookpark Road 439 Cleveland, Ohio 44135 440 USA 442 Phone: +1-216-433-6587 443 Fax: +1-216-433-8705 444 Email: jishac@grc.nasa.gov 446 Intellectual Property Statement 448 The IETF takes no position regarding the validity or scope of any 449 Intellectual Property Rights or other rights that might be claimed to 450 pertain to the implementation or use of the technology described in 451 this document or the extent to which any license under such rights 452 might or might not be available; nor does it represent that it has 453 made any independent effort to identify any such rights. Information 454 on the procedures with respect to rights in RFC documents can be 455 found in BCP 78 and BCP 79. 457 Copies of IPR disclosures made to the IETF Secretariat and any 458 assurances of licenses to be made available, or the result of an 459 attempt made to obtain a general license or permission for the use of 460 such proprietary rights by implementers or users of this 461 specification can be obtained from the IETF on-line IPR repository at 462 http://www.ietf.org/ipr. 464 The IETF invites any interested party to bring to its attention any 465 copyrights, patents or patent applications, or other proprietary 466 rights that may cover technology that may be required to implement 467 this standard. Please address the information to the IETF at 468 ietf-ipr@ietf.org. 470 Disclaimer of Validity 472 This document and the information contained herein are provided on an 473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 475 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 476 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 477 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Copyright Statement 482 Copyright (C) The Internet Society (2005). This document is subject 483 to the rights, licenses and restrictions contained in BCP 78, and 484 except as set forth therein, the authors retain all their rights. 486 Acknowledgment 488 Funding for the RFC Editor function is currently provided by the 489 Internet Society.