idnits 2.17.1 draft-floyd-transport-metrics-00.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 520. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 488), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (27 May 2005) is 6909 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: 'MS90' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC 2434' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC 2581' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'YL00' is defined on line 468, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sally Floyd 2 INTERNET-DRAFT Editor 3 draft-floyd-transport-metrics-00.txt 27 May 2005 4 Expires: November 2005 6 Metrics for the Evaluation of Congestion Control Mechanisms 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she becomes aware will be disclosed, in accordance with 15 Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This document discusses the metrics to be considered in an 42 evaluation of new or modified congestion control mechanisms for the 43 Internet. This document is intended to be the first in a series of 44 documents aimed at improving the models that we use in the 45 evaluation of transport protocols. 47 Table of Contents 49 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Throughput, Delay, and Drop Rates. . . . . . . . . . . . 5 53 3.1.1. Throughput. . . . . . . . . . . . . . . . . . . . . 5 54 3.1.2. Delay . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1.3. Packet Drop Rates . . . . . . . . . . . . . . . . . 5 56 3.2. Response Times and Minimizing Oscillations . . . . . . . 6 57 3.2.1. Response to Changes . . . . . . . . . . . . . . . . 6 58 3.2.2. Minimizing Oscillations . . . . . . . . . . . . . . 7 59 3.3. Fairness and Convergence . . . . . . . . . . . . . . . . 7 60 3.4. Metrics for Specific Environments. . . . . . . . . . . . 9 61 3.5. Metrics for Specific Types of Transport. . . . . . . . . 9 62 4. Comments on Methodology . . . . . . . . . . . . . . . . . . . 9 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 10 66 Informative References . . . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12 69 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 13 71 1. Conventions 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC 2119]. 77 2. Introduction 79 As a step towards improving our methodologies for evaluating 80 congestion control mechanisms, in this document we discuss some of 81 the metrics to be considered. We also consider the relationship 82 between metrics, e.g., the well-known tradeoff between throughput 83 and delay. 85 Subsequent documents will discuss the models that are used in 86 analysis, simulations, or experiments for the evaluation of 87 transport protocols in general, and of congestion control mechanisms 88 in particular. We are in the process of creating a new IRTF 89 (Internet Research Task Force) research group to aid collaboration 90 in developing these documents. 92 3. Metrics 94 The metrics that we discuss are the following: 96 o Throughput; 98 o Delay; 100 o Packet drop rates; 102 o Response to sudden changes or to transient events; 104 o Minimizing oscillations in throughput or in delay; 106 o Fairness and convergence times; 108 o Metrics for specific environments; 110 o Metrics for specific types of transport. 112 We consider each of these below. Many of the metrics have both 113 network-based and user-based interpretations. For some of the 114 metrics, such as fairness between flows, there is not a clear 115 agreement in the network community about the desired goals. 117 3.1. Throughput, Delay, and Drop Rates 119 Because of the clear tradeoffs between throughput, delay, and drop 120 rates, it can be useful to consider the three metrics together. 122 An alternative would be to consider a separate metric such as power, 123 defined in this context as throughput over delay, that combines 124 throughput and delay. However, we do not propose in this document a 125 clear target in terms of the tradeoffs between throughput and delay; 126 we are simply proposing that the evaluation of transport protocols 127 include an exploration of the competing metrics. 129 3.1.1. Throughput 131 Throughput can be measured both as a router-based metric of 132 aggregate link throughput, and as a user metric of per-connection 133 transfer times. It is a clear goal of most congestion control 134 mechanisms to maximize throughput, subject to application demand and 135 to the constraints of the other metrics. We note that maximizing 136 throughput is of concern in a wide range of environments, from 137 highly-congested networks to under-utilized ones. 139 Some researchers evaluate transport protocols in terms of maximizing 140 the aggregate user utility, where a user's utility is generally 141 defined as a function of the user's throughput [KMT98]. 143 3.1.2. Delay 145 Like throughput, delay can be measured as a router-based metric of 146 queueing delay over time, or in terms of per-packet transfer times. 147 For reliable transfer, the per-packet transfer time includes the 148 possible delay of retransmitting a dropped packet. 150 Users of bulk data transfer applications might care about per-packet 151 transfer times only in so far as they affect the per-connection 152 transfer time. On the other end of the spectrum, for users of 153 streaming media, per-packet delay can be a significant concern. 154 Note that in some cases the average delay might not capture the 155 metric of interest to the users; some users might also care about 156 the tail of the delay distribution. 158 3.1.3. Packet Drop Rates 160 Packet drop rates can be measured as a network-based or as a user- 161 based metric. 163 Some users might care about packet drop rates only in so far as they 164 affect per-connection transfer times, while other users might care 165 about packet drop rates directly. One network-related reason to 166 avoid high steady-state packet drop rates is to avoid congestion 167 collapse in environments containing by paths with multiple congested 168 links. High packet drop rates in such environments could result in 169 congested links wasting scarce bandwidth by carrying packets that 170 will only be dropped downstream, before being delivered to the 171 receiver. 173 3.2. Response Times and Minimizing Oscillations 175 In this section we consider response times and oscillations 176 together, as there are well-known tradeoffs between improving 177 response times and minimizing oscillations. In addition, the 178 scenarios that illustrate the dangers of poor response times are 179 often quite different from the scenarios that illustrate the dangers 180 of unnecessary oscillations. 182 3.2.1. Response to Changes 184 One of the key concerns in the design of congestion control 185 mechanisms has been the response times to sudden congestion in the 186 network. On the one hand, congestion control mechanisms should 187 respond reasonably promptly to sudden congestion from routing or 188 bandwidth changes, or from a burst of competing traffic. At the 189 same time, congestion control mechanisms should not respond too 190 severely to transient changes, e.g., to a sudden increase in delay 191 that will dissipate in less than the connection's round-trip time. 193 Evaluating the response to sudden or transient changes can be of 194 particular concern for slowly-responding congestion control 195 mechanisms such as equation-based congestion control [RFC 3448], and 196 for AIMD (Additive Increase Multiplicative Decrease) or related 197 mechanisms using parameters that make them more slowly-responding 198 that TCP [BB01, BBFS01]. 200 In addition to the responsiveness and smoothness of aggregate 201 traffic, one can consider the tradeoffs between responsiveness, 202 smoothness, and aggressiveness for an individual connection [FHP00]. 203 In this case smoothness can be defined by the largest reduction in 204 the sending rate in one round-trip time, in a deterministic 205 environment with a packet drop exactly every 1/p packets. The 206 responsiveness is defined as the number of round-trip times of 207 sustained congested required for the sender to halve the sending 208 rate, and the aggressiveness is defined as the maximum increase in 209 the sending rate in one round-trip time, in packets per second, in 210 the absence of congestion. 212 3.2.2. Minimizing Oscillations 214 One goal is that of stability, in terms of minimizing oscillations 215 of queueing delay or of throughput. Scenarios illustrating 216 oscillations are often dominated by long-lived connections, perhaps 217 with a small number of changes in the level of congestion. 219 An orthogonal goal for some congestion control mechanisms, e.g., for 220 equation-based congestion control, is to minimize the oscillations 221 in the sending rate for an individual connection, given an 222 environment with a fixed, steady-state packet drop rate. (As is 223 well known, TCP congestion control is characterized by a pronounced 224 oscillation in the sending rate, with the sender halving the sending 225 rate in response to congestion.) One metric for the level of 226 oscillations is the smoothness metric given above. 228 3.3. Fairness and Convergence 230 Another set of metrics are those of fairness and of convergence 231 times. Fairness can be considered between flows of the same 232 protocol, and between flows using different protocols (e.g., 233 fairness between TCP and a new transport protocol). 235 There are a number of different fairness measures. These include 236 max-min fairness [HG86], proportional fairness [KMT98, K01], the 237 fairness index proposed in [JCH84], and the product measure, a 238 variant of network power [BJ81]. 240 Max-min fairness: In order to satisfy the max-min fairness criteria, 241 the smallest throughput rate must be as large as possible. Given 242 this condition, the next-smallest throughput rate must be as large 243 as possible, and so on. Thus, the max-min fairness gives absolute 244 priority to the smallest flows. 246 Epsilon-fairness: A metric related to max-min fairness is epsilon- 247 fairness, where a rate allocation is defined as epsilon-fairness if 249 min_i x_i / max_i x_i >= 1 - epsilon. 251 where x_i is the resource allocation to the i-th user. Epsilon- 252 fairness measures the worst-case ratio between any two throughput 253 rates [ZKL04]. 255 Proportional fairness: In contrast, an allocation x is defined as 256 proportionally fair if for any other feasible allocation x*, the 257 aggregate of proportional changes is zero or negative: 259 sum_i (x*_i - x_i)/x_i <= 0. 261 "This criterion favours smaller flows, but less emphatically than 262 max-min fairness" [K01]. 264 Jain's fairness index: The fairness index in [JCH84] is 266 (( sum_i x_i )^2) / (n * sum_i (x_i)^2 ) , 268 where there are n users. This fairness index ranges from 0 to 1, 269 and is maximum when all users receive the same allocation. This 270 index is k/n when k users equally share the resource, and the other 271 n-k users receive zero allocation. 273 The product measure: The product measure 275 product_i x_i , 277 the product of the throughput of the individual connections, is also 278 used as a measure of fairness. For our purposes, let x_i be the 279 throughput for the i-th connection. (In other contexts x_i is taken 280 as the power of the i-th connection, and the product measure is 281 referred to as network power.) The product measure is particularly 282 sensitive to segregation; the product measure is zero if any 283 connection receives zero throughput. In [MS90](p. 15) it is shown 284 that for a network with many connections and one shared gateway, the 285 product measure is maximized when all connections receive the same 286 throughput. 288 Fairness and the number of congested links: Some of these fairness 289 metrics are discussed in more detail in [F91]. We note that there 290 is not a clear consensus for the fairness goals, in particular for 291 fairness between flows that traverse different numbers of congested 292 links [F91]. 294 Fairness and round-trip times: One goal cited in a number of new 295 transport protocols has been that of fairness between flows with 296 different round-trip times [KHR02, XHR04]. We note that there is not 297 a consensus in the networking community about the desirability of 298 this goal, or about the implications and interactions between this 299 goal and other metrics [FJ92] (Section 3.3). 301 Convergence times: Convergence times concern the time for 302 convergence to fairness between an existing flow and a newly- 303 starting one, and are a special concern for environments with high- 304 bandwidth flows. As with fairness, convergence times can matter 305 both between flows of the same protocol, and between flows using 306 different protocols [SLFK03]. 308 One metric used for convergence times is the delta-fair convergence 309 time, defined in [BBFS01] as the time taken for two flows with the 310 same round-trip time to go from shares of 100/101-th and 1/101-th of 311 the link bandwidth, to having close to fair sharing with shares of 312 (1+delta)/2 and (1-delta)/2 of the link bandwidth. 314 A somewhat similar metric for convergence times defined in [ZKL04] 315 measures the convergence time as the number of round-trip times for 316 two flows to reach epsilon-fairness, when starting from a maximally- 317 unfair state. 319 3.4. Metrics for Specific Environments 321 While congestion control mechanisms are generally evaluated first 322 over environments with static routing in a network of two-way point- 323 to-point links, some environments bring up not only more challenging 324 scenarios (e.g., corrupted links, variable bandwidth, mobility) but 325 also new metrics to be considered, as follows. 327 Energy consumption: For example, in mobile environments the energy 328 consumption for the mobile end-node can be a key metric that is 329 affected by the transport protocol [TM02]. 331 Goodput: For wireless networks, goodput can be a key metric, where 332 goodput is defined as the fraction of useful data from all of the 333 data delivered. High goodput indicates an efficient use of the 334 radio spectrum and lower interference to other users [GF04]. 336 3.5. Metrics for Specific Types of Transport 338 In some cases modified metrics are needed for evaluting transport 339 protocols intended for QoS-enabled environments or for below-best- 340 effort traffic [VKD02, KK03]. For example, different fairness 341 metrics are needed for evaluating transport protocols for below- 342 best-effort traffic. 344 4. Comments on Methodology 346 The types of scenarios that are used to test specific metrics, and 347 the range of parameters that it is useful to consider, will be 348 discussed in separate documents, e.g., along with specific scenarios 349 for use in evaluating congestion control mechanisms. 351 However, we note that it can be important to evaluate metrics over a 352 wide range of environments, with a range of link bandwidths, 353 congestion levels, and levels of statistical multiplexing. It is 354 also important to evaluate congestion control mechanisms in a range 355 of scenarios, including typical ranges of connection sizes and 356 round-trip times [FK02]. It is also useful to compare metrics for 357 new or modified transport protocols with those of the current 358 standards for TCP. 360 More general references on methodology include [J91]. 362 5. Security Considerations 364 There are no security considerations in this document. 366 6. IANA Considerations 368 There are no IANA considerations in this document. 370 7. Acknowledgements 372 Thanks to Doug Leith for feedback. 374 Informative References 376 [BB01] D. Bansal and H. Balakrishnan, Binomial Congestion Control 377 Algorithms, IEEE Infocom, April 2001. 379 [BBFS01] D. Bansal, H. Balakrishnan, S. Floyd, and S. Shenker, 380 Dynamic Behavior of Slowly-Responsive Congestion Control 381 Algorithms, SIGCOMM 2001. 383 [BJ81] K. Bharath-Kumar and J. Jeffrey, A New Approach to 384 Performance-Oriented Flow Control, IEEE Transactions on 385 Communications, Vol.COM-29 N.4, April 1981. 387 [F91] S. Floyd, Connections with Multiple Congested Gateways in 388 Packet-Switched Networks Part 1: One-way Traffic, Computer 389 Communication Review, Vol.21, No.5, October 1991, p. 30-47. 391 [FHP00] S. Floyd, M. Handley, and J. Padhye, A Comparison of 392 Equation-Based and AIMD Congestion Control, May 2000. URL 393 "http://www.icir.org/tfrc/". 395 [FJ92] S. Floyd and V. Jacobson, On Traffic Phase Effects in Packet- 396 Switched Gateways, Internetworking: Research and Experience, V.3 397 N.3, September 1992, p.115-156. 399 [FK02] S. Floyd and E. Kohler, Internet Research Needs Better 400 Models, Hotnets-I. October 2002. 402 [GF04] A. Gurtov and S. Floyd, Modeling Wireless Links for Transport 403 Protocols, ACM CCR, 34(2):85-96, April 2004. 405 [HG86] E. Hahne and R. Gallager, Round Robin Scheduling for Fair 406 Flow Control in Data Communications Networks, IEEE International 407 Conference on Communications, June 1986. 409 [J91] R. Jain, The Art of Computer Systems Performance Analysis: 410 Techniques for Experimental Design, Measurement, Simulation, and 411 Modeling, John Wiley & Sons, 1991. 413 [JCH84] R. Jain, D.M. Chiu, and W. Hawe, A Quantitative Measure of 414 Fairness and Discrimination for Resource Allocation in Shared 415 Systems, DEC TR-301, Littleton, MA: Digital Equipment 416 Corporation, 1984. 418 [K01] F. Kelly, Mathematical Modelling of the Internet, "Mathematics 419 Unlimited - 2001 and Beyond" (Editors B. Engquist and W. 420 Schmid), Springer-Verlag, Berlin, pp. 685-702, 2001. 422 [KHR02] D. Katabi, M. Handley, and C. Rohrs, Congestion Control for 423 High Bandwidth-Delay Product Networks, ACM Sigcomm, 2002. 425 [KK03] A. Kuzmanovic and E. W. Knightly, TCP-LP: A Distributed 426 Algorithm for Low Priority Data Transfer, IEEE INFOCOM 2003, 427 April 2003. 429 [KMT98] F. Kelly, A. Maulloo and D. Tan, Rate Control in 430 Communication Networks: Shadow Prices, Proportional Fairness and 431 Stability. Journal of the Operational Research Society 49, pp. 432 237-252, 1998. 434 [MS90] D. Mitra and J. Seery, Dynamic Adaptive Windows for High 435 Speed Data Networks: Theory and Simulations, ATT Bell 436 Laboratories report, April 1990. 438 [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate 439 Requirement Levels. RFC 2119. 441 [RFC 2434] T. Narten and H. Alvestrand. Guidelines for Writing an 442 IANA Considerations Section in RFCs. RFC 2434. 444 [RFC 2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion 445 Control. RFC 2581. 447 [RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP 448 Friendly Rate Control (TFRC): Protocol Specification, RFC 3448, 449 Proposed Standard, January 2003. 451 [SLFK03] R.N. Shorten, D.J. Leith, J. Foy, and R. Kilduff, Analysis 452 and Design of Congestion Control in Synchronised Communication 453 Networks. Proc. 12th Yale Workshop on Adaptive & Learning 454 Systems, May 2003. 456 [TM02] V. Tsaoussidis and I. Matta, Open Issues of TCP for Mobile 457 Computing, Journal of Wireless Communications and Mobile 458 Computing: Special Issue on Reliable Transport Protocols for 459 Mobile Computing, February 2002. 461 [VKD02] A. Venkataramani, R. Kokku, and M. Dahlin, TCP Nice: A 462 Mechanism for Background Transfers, Fifth USENIX Symposium on 463 Operating System Design and Implementation (OSDI), 2002. 465 [XHR04] L. Xu, K. Harfoush, and I. Rhee, Binary Increase Congestion 466 Control for Fast, Long Distance Networks, Infocom 2004. 468 [YL00] Y. R. Yang and S. S. Lam, General AIMD Congestion Control, 469 Technical Report TR-00-09, Department of Computer Sciences, UT 470 Austin, May 2000. 472 [ZKL04] Y. Zhang, S.-R. Kang, and D. Loguinov, Delayed Stability and 473 Performance of Distributed Congestion Control, ACM SIGCOMM, 474 August 2004. 476 Authors' Addresses 478 Sally Floyd 479 ICSI Center for Internet Research 480 1947 Center Street, Suite 600 481 Berkeley, CA 94704 482 USA 484 Full Copyright Statement 486 Copyright (C) The Internet Society 2005. This document is subject 487 to the rights, licenses and restrictions contained in BCP 78, and 488 except as set forth therein, the authors retain all their rights. 490 This document and the information contained herein are provided on 491 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 492 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 493 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 494 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 495 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Intellectual Property 500 The IETF takes no position regarding the validity or scope of any 501 Intellectual Property Rights or other rights that might be claimed 502 to pertain to the implementation or use of the technology described 503 in this document or the extent to which any license under such 504 rights might or might not be available; nor does it represent that 505 it has made any independent effort to identify any such rights. 506 Information on the procedures with respect to rights in RFC 507 documents can be found in BCP 78 and BCP 79. 509 Copies of IPR disclosures made to the IETF Secretariat and any 510 assurances of licenses to be made available, or the result of an 511 attempt made to obtain a general license or permission for the use 512 of such proprietary rights by implementers or users of this 513 specification can be obtained from the IETF on-line IPR repository 514 at http://www.ietf.org/ipr. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary 518 rights that may cover technology that may be required to implement 519 this standard. Please address the information to the IETF at ietf- 520 ipr@ietf.org.