idnits 2.17.1 draft-ietf-ippm-bw-capacity-02.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 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 516. ** 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 (May 17, 2006) is 6554 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 450, 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: November 18, 2006 NASA Glenn Research Center 6 May 17, 2006 8 Defining Network Capacity 9 draft-ietf-ippm-bw-capacity-02 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 November 18, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 provide a 49 common framework for the discussion and analysis of a diverse set of 50 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 64 3.6 Time and Sampling . . . . . . . . . . . . . . . . . . . . 10 66 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8.1 Normative References . . . . . . . . . . . . . . . . . . . 15 76 8.2 Informative References . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 80 Intellectual Property and Copyright Statements . . . . . . . . 17 82 1. Introduction 84 Measuring the capacity of a link or network path is a task that 85 sounds simple, but in reality can be quite complex. Any physical 86 medium requires that information be encoded and, depending on the 87 medium, there are various schemes to convert information into a 88 sequence of signals that are transmitted physically from one location 89 to another. 91 While on some media, the maximum frequency of these signals can be 92 thought of as "capacity", on other media, the signal transmission 93 frequency and the information capacity of the medium (channel) may be 94 quite different. For example, a satellite channel may have a carrier 95 frequency of a few gigahertz, but an information-carrying capacity of 96 only a few hundred kilobits per second. Often similar or identical 97 terms are used to refer to these different applications of capacity, 98 adding to the ambiguity and confusion, and the lack of a unified 99 nomenclature makes it difficult to properly build, test, and use 100 various techniques and tools. 102 We are interested in information-carrying capacity, but even this is 103 not straightforward. Each of the layers, depending on the medium, 104 adds overhead to the task of carrying information. The wired 105 Ethernet uses Manchester coding or 4/5 coding which cuts down 106 considerably on the "theoretical" capacity. Similarly RF (radio 107 frequency) communications will often add redundancy to the coding 108 scheme to implement forward error correction because the physical 109 medium (air) is lossy. This can further decrease the information 110 efficiency. 112 In addition to coding schemes, usually the physical layer and the 113 link layer add framing bits for multiplexing and control purposes. 114 For example, on SONET there is physical layer framing and typically 115 also some layer 2 framing such as HDLC, PPP or even ATM. 117 Aside from questions of coding efficiency, there are issues of how 118 access to the channel is controlled which may affect the capacity 119 also. For example, a multiple-access medium with collision 120 detection, avoidance and recovery mechanisms has a varying capacity 121 from the point of view of the users. This varying capacity depends 122 upon the total number of users contending for the medium, how busy 123 the users are, and bounds resulting from the mechanisms themselves. 124 RF channels are also varying capacity, depending on range, 125 environmental conditions, mobility and shadowing, etc. 127 The important points to derive from this discussion are these: First, 128 capacity is only meaningful when defined relative to a given protocol 129 layer in the network. It is meaningless to speak of "link" capacity 130 without qualifying exactly what is meant. Second, capacity is not 131 necessarily fixed, and consequently, a single measure of capacity at 132 whatever layer may in fact provide a skewed picture (either 133 optimistic or pessimistic) of what is actually available. 135 2. Definitions 137 In this section, we specify definitions for capacity. We begin by 138 first defining a baseline capacity that is simply tied to the 139 physical properties of the link. 141 Nominal Physical Link Capacity: 142 Or NomCap(L) is the theoretical maximum amount of data that the 143 link can support. For example, an OC-3 link would be capable of 144 roughly 155 Mbps. We stress that this is a measurement at the 145 physical layer and not the network IP layer, which we will define 146 separately. While NomCap(L) is typically constant over time, 147 there are links whose characteristics may allow otherwise, such as 148 the dynamic activation of additional transponders for a satellite 149 link. 151 The nominal physical link capacity is provided as a means to help 152 distinguish between the commonly used link layer capacities and the 153 remaining definitions for IP layer capacity. As a result, the value 154 of NomCap(L) does not influence the other definitions presented in 155 this document. 157 There are many factors that can reduce the IP information carrying 158 capacity of the link, some of which have already been discussed in 159 the introduction. However, the goal of this document is not to 160 become an exhaustive list of of such factors. Rather, we outline 161 some of the major examples in the following section, thus providing 162 food for thought to those implementing the algorithms or tools that 163 attempt to measure capacity accurately. 165 The remaining definitions are all given in terms of "IP layer bits" 166 in order to distinguish these definitions from the nominal physical 167 capacity of the link. 169 IP layer bits: 170 Eight (8) times the number of octets in all IP packets received, 171 from the first octet of the IP header to the last octet of the IP 172 packet payload, inclusive. 174 We then define a path P of length n as a series of links (L1, L2, 175 ..., Ln) connecting a sequence of nodes (N1, N2, ..., Nn+1). A 176 source, S, and destination, D, reside at N1 and Nn+1 respectively. 177 Furthermore, we define a link L as a special case where the path size 178 is one. The concept of links are consistent with [RFC2330] in that 179 they represent a link-level connection between two nodes, and each 180 node is not necessarily a router. However, the concept of a path 181 differs slightly as intermediate nodes N2...Nn do not need to be 182 routers. They may, for example, be Ethernet switches or other kinds 183 of layer 2 or layer 1 devices. 185 IP layer bits are recorded at the destination, D, beginning at time T 186 and ending at a time T+I. Since the definitions are based on 187 averages, the two time parameters, T and I, must accompany any report 188 or estimate of the following values in order for them to remain 189 meaningful. It is not required that the interval boundary points 190 fall between packet arrivals at D. However, boundaries that fall 191 within a packet will invalidate the packets on which they fall. 192 Specifically, the data from the partial packet that is contained 193 within the interval will not be counted. This may artificially bias 194 some of the values, depending on the length of the interval and the 195 amount of data received during that interval. We elaborate on what 196 constitutes correctly received data in the next section. 198 IP Layer Link Capacity: 199 We define the IP Layer link capacity, C(L,T,I), to be the maximum 200 number of IP layer bits that can be transmitted from the source S 201 and correctly received by the destination D over the link L during 202 the interval [T, T+I], divided by I. 204 Using this, we can then extend this notion to an entire path, such 205 that the IP layer path capacity simply becomes that of the link with 206 the smallest capacity along that path. 208 IP Layer Path Capacity: 209 C(P,T,I) = min {1..n} {C(Ln,T,I)} 211 The previous definitions specify a link's capacity, namely the IP 212 information bits that can be transmitted across a link or path should 213 the resource be free of any congestion. Determining how much 214 capacity is available for use on a congested link is potentially much 215 more useful. However, in order to define the available capacity we 216 must first specify how much is being used. 218 IP Layer Link Usage: 219 The average usage of a link L, Used(L,T,I), is the actual number 220 of IP layer bits correctly transmitted from any source over link L 221 during the interval [T, T+I], divided by I. 223 An important distinction between usage and capacity is that 224 Used(L,T,I) is not the maximum amount, but rather, the actual amount 225 of IP bits that are sent. The information transmitted across the 226 link can be generated by any source, including those who may not be 227 directly attached to either side of the link. In addition, each 228 information flow from these sources may share any number (from one to 229 n) of links in the overall path between S and D. Next, we express 230 usage as a fraction of the overall IP layer link capacity. 232 Average IP Layer Link Utilization: 233 Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ) 235 Thus, the utilization now represents the fraction of the capacity 236 that is being used and is a value between zero, meaning nothing is 237 used, and one, meaning the link is fully saturated. Multiplying the 238 utilization by 100 yields the percent utilization of the link. By 239 using the above, we can now define the capacity available over the 240 link as well as the path between S and D. Note that this is 241 essentially the definition in [PDM]. 243 IP Layer Available Link Capacity 244 AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) ) 246 IP Layer Available Path Capacity 247 AvailCap(P,T,I) = min {1..n} {AvailCap(Ln,T,I)} 249 Since measurements of available capacity are more volatile that that 250 of capacity, it is important that both the time and interval be 251 specified as their values have a great deal of influence on the 252 results. In addition, a sequence of measurements may be beneficial 253 in offsetting the volatility when attempting to characterize 254 available capacity. 256 3. Discussion 258 3.1 Standard or Correctly Formed Packets 260 The definitions in this document specify that IP packets must be 261 received correctly. The IPPM framework recommends a set of criteria 262 for such standard-formed packet in section 15 of [RFC2330]. However, 263 it is inadequate for use with this document. Thus, we outline our 264 own criteria below while pointing out any variations or similarities 265 to [RFC2330]. 267 First, data that is in error at layers below IP and cannot be 268 properly passed to the IP layer should not be counted. For example, 269 wireless media often has a considerably larger error rate than wired 270 media, resulting in a reduction in IP Link Capacity. In accordance 271 with the framework, packets that fail validation of the IP header 272 should be discarded. Specifically, the requirements in [RFC1812] 273 section 5.2.2 on IP header validation should be checked, which 274 includes a valid length, checksum, and version field. 276 The framework specifies further restrictions, requiring that any 277 transport header be checked for correctness and that any packets with 278 IP options be ignored. However, the definitions in this document are 279 concerned with the traversal of IP layer bits. As a result, data 280 from the higher layers is not required to be valid or understood as 281 they are simply regarded as part of the IP packet. The same holds 282 true for IP options. Valid IP fragments should also be counted as 283 they expend the resources of a link even though assembly of the full 284 packet may not be possible. The framework differs in this area, 285 discarding IP fragments. 287 In summary, any IP packet that can be properly processed should be 288 included in these calculations. 290 3.2 Other Potential Factors 292 The base definitions make no mention of hardware duplication of 293 packets. While hardware duplication has no impact on the nominal 294 capacity, it can impact the IP link layer capacity. For example, 295 consider a link which can normally carry a capacity of 2X on average. 296 However, the link has developed a syndrome where it duplicates every 297 incoming packet. The link would still technically carry a capacity 298 of 2X, however the link has a effective capacity of X or lower, 299 depending on framing overhead to send the duplicates, etc. Thus, a 300 value for C(L,T,I) and AvailCap(L,T,I) will reflect the duplication 301 with the lower value. 303 IP encapsulation does not impact the definitions as all IP header and 304 payload bits should be counted regardless of content. However, 305 different sized IP packets can lead to a variation in the amount of 306 overhead needed at the lower layers to transmit the data, thus 307 altering the overall IP link layer capacity. 309 Should the link happen to employ a compression scheme such as ROHC 310 [RFC3095] or V.44 [V44], some of the original bits are not 311 transmitted across the link. However, the inflated (not compressed) 312 number of IP-layer bits should be counted. 314 3.3 Common Literature Terminology 316 Certain terms are often used to characterize specific aspects of the 317 presented definitions. The link with the smallest capacity is 318 commonly referred to as the "narrow link" of a path. Also, the value 319 of n that satisfies AvailCap(P,T,I), is often referred to as the 320 "tight link" within a path. So, while Ln may have a very large 321 capacity, the overall congestion level on the link makes it the 322 likely bottleneck of a connection. Conversely, a link that has the 323 smallest capacity may not be a bottleneck should it be lightly loaded 324 in relation to the rest of the path. 326 Also, common literature often overloads the term "bandwidth" to refer 327 to what we have described as capacity in this document. For example, 328 when inquiring about the bandwidth of a 802.11b link, a network 329 engineer will likely answer with 11 Mbps. However, an electrical 330 engineer may answer with 25 MHz, and an end user may tell you that 331 his observed bandwidth is 8 Mbps. In contrast, the term capacity is 332 not quite as overloaded and is an appropriate term that better 333 reflects what is actually being measured. 335 3.4 Comparison to Bulk Transfer Capacity (BTC) 337 Bulk Transfer Capacity (BTC) [RFC3148] provides a distinct 338 perspective on path capacity that differs from the definitions in 339 this document in several fundamental ways. First, BTC operates at 340 the transport layer, gauging the amount of capacity available to an 341 application that wishes to send data. Only unique data is measured, 342 meaning header and retransmitted data are not included in the 343 calculation. In contrast, IP layer link capacity includes the IP 344 header and is indifferent to the uniqueness of the data contained 345 within the packet payload (Hardware duplication of packets is an 346 anomaly addressed in the previous section). Second, BTC utilizes a 347 single congestion aware transport connection, such as TCP, to obtain 348 measurements. As a result, BTC implementations react strongly to 349 different path characteristics, topologies, and distances. Since 350 these differences can affect the control loop (propagation delays, 351 segment reordering, etc), the reaction is further dependent on the 352 algorithms being employed for the measurements. For example, 353 consider a single event where a link suffers a large duration of bit 354 errors. The event could cause IP layer packets to be discarded, and 355 the lost packets would reduce the IP layer link capacity. However, 356 the same event and subsequent losses would trigger loss recovery for 357 a BTC measurement resulting in the retransmission of data and a 358 potentially reduced sending rate. Thus, a measurement of BTC does 359 not correspond to any of the definitions in this document. Both 360 techniques are useful in exploring the characteristics of a network 361 path, but from different perspectives. 363 3.5 Type P Packets 365 Note that these definitions do not make mention of "Type P" packets, 366 while other IPPM definitions do. We could add the packet type as an 367 extra parameter. This would have the effect of defining a large 368 number of quantities, relative to the QoS policies that a given 369 network or concatenation of networks may have in effect in the path. 370 It would produce metrics such as "estimated EF IP Link/Path Capacity" 371 or "estimated EF IP Link Utilization". 373 Such metrics may indeed be useful. For example, this would yield 374 something like the sum of the capacities of all the QoS classes 375 defined along the path as the link or path capacity. The breakdown 376 then gives the user an analysis of how the link or path capacity (or 377 at least the "tight link" capacity) is allocated among classes. 379 These QoS-based capacities become difficult to measure on a path if 380 there are different capacities defined per QoS class on different 381 links in the path. Possibly the best way to approach this would be 382 to measure each link in a path individually, and then combine the 383 information from individual links. 385 3.6 Time and Sampling 387 We must emphasize the importance of time in the basic definitions of 388 these quantities. We know that traffic on the Internet is highly 389 variable across all time scales. This argues that the time and 390 length of measurements are critical variables in reporting available 391 capacity measurements. 393 The closer to "instantaneous" a metric is, the more important it is 394 to have a plan for sampling the metric over a time period that is 395 sufficiently large. By doing so, we allow valid statistical 396 inferences to be made from the measurements. An obvious pitfall here 397 is sampling in a way that causes bias. For example, a situation 398 where the sampling frequency is a multiple of the frequency of an 399 underlying condition. 401 4. Conclusion 403 In this document, we have defined a set of quantities related to the 404 capacity of links in an IP network. In these definitions, we have 405 tried to be as clear as possible and take into account various 406 characteristics that links can have. The goal of these definitions 407 is to enable researchers who propose capacity metrics to relate those 408 metrics to these definitions and to evaluate those metrics with 409 respect to how well they approximate these quantities. 411 In addition, we have pointed out some key auxiliary parameters and 412 opened a discussion of issues related to valid inferences from 413 available capacity metrics. 415 5. IANA Considerations 417 This document makes no request of IANA. 419 Note to RFC Editor: this section may be removed on publication as an 420 RFC. 422 6. Security Considerations 424 This document specifies definitions regarding IP traffic traveling 425 between a source and destination in an IP network. These definitions 426 do not raise any security issues and do not have a direct impact on 427 the networking protocol suite. 429 7. Acknowledgments 431 The authors would like to acknowledge Mark Allman, Patrik Arlos, Matt 432 Mathis, Al Morton, and Stanislav Shalunov for their suggestions, 433 comments, and reviews. We also thank members of the IETF IPPM 434 Mailing List for their discussions and feedback on this document. 436 8. References 438 8.1 Normative References 440 8.2 Informative References 442 [PDM] Dovrolis, C., Ramanathan, P., and D. Moore, "Packet 443 Dispersion Techniques and a Capacity Estimation 444 Methodology", IEEE/ACM Transactions on Networking 12(6): 445 963-977, December 2004. 447 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 448 RFC 1812, June 1995. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 454 "Framework for IP Performance Metrics", RFC 2330, 455 May 1998. 457 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 458 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 459 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 460 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 461 Compression (ROHC): Framework and four profiles: RTP, UDP, 462 ESP, and uncompressed", RFC 3095, July 2001. 464 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 465 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 466 July 2001. 468 [V44] ITU Telecommunication Standardization Sector (ITU-T) 469 Recommendation V.44, "Data Compression Procedures", 470 November 2000. 472 Authors' Addresses 474 Phil Chimento 475 JHU Applied Physics Lab 476 11100 Johns Hopkins Road 477 Laurel, Maryland 20723-6099 478 USA 480 Phone: +1-240-228-1743 481 Fax: +1-240-228-0789 482 Email: Philip.Chimento@jhuapl.edu 484 Joseph Ishac 485 NASA Glenn Research Center 486 21000 Brookpark Road 487 Cleveland, Ohio 44135 488 USA 490 Phone: +1-216-433-6587 491 Fax: +1-216-433-8705 492 Email: jishac@grc.nasa.gov 494 Intellectual Property Statement 496 The IETF takes no position regarding the validity or scope of any 497 Intellectual Property Rights or other rights that might be claimed to 498 pertain to the implementation or use of the technology described in 499 this document or the extent to which any license under such rights 500 might or might not be available; nor does it represent that it has 501 made any independent effort to identify any such rights. Information 502 on the procedures with respect to rights in RFC documents can be 503 found in BCP 78 and BCP 79. 505 Copies of IPR disclosures made to the IETF Secretariat and any 506 assurances of licenses to be made available, or the result of an 507 attempt made to obtain a general license or permission for the use of 508 such proprietary rights by implementers or users of this 509 specification can be obtained from the IETF on-line IPR repository at 510 http://www.ietf.org/ipr. 512 The IETF invites any interested party to bring to its attention any 513 copyrights, patents or patent applications, or other proprietary 514 rights that may cover technology that may be required to implement 515 this standard. Please address the information to the IETF at 516 ietf-ipr@ietf.org. 518 Disclaimer of Validity 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 523 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 524 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 525 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 Copyright Statement 530 Copyright (C) The Internet Society (2006). This document is subject 531 to the rights, licenses and restrictions contained in BCP 78, and 532 except as set forth therein, the authors retain all their rights. 534 Acknowledgment 536 Funding for the RFC Editor function is currently provided by the 537 Internet Society.