idnits 2.17.1 draft-ietf-avt-tfrc-profile-09.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 474. 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 IETF Trust 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 (8 July 2007) is 6137 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: 'RFC2434' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC3551' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC4342' is defined on line 423, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4336 -- No information found for draft-ietf-avt-profile-savpf-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SAVPF' -- No information found for draft-phelan-dccp-dtls-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ID.DTLS' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT WG 2 INTERNET-DRAFT Ladan Gharai 3 draft-ietf-avt-tfrc-profile-09.txt USC/ISI 4 8 July 2007 5 Expires: January 2008 7 RTP with TCP Friendly Rate Control 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The IETF Trust (2007). 35 Abstract 37 This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP 38 flows can be supported using the RTP/AVPF profile and the general RTP 39 header extension mechanism. AVPF feedback packets and RTP header 40 extensions are defined to support the exchange of control information 41 between RTP TFRC senders and receivers. TFRC is an equation-based 42 congestion control scheme for unicast flows operating in a best 43 effort Internet environment. 45 1. Introduction 47 [Note to RFC Editor: All references to RFC XXXX are to be replaced 48 with the RFC number of this memo, when published] 50 This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP 51 flows can be supported using the RTP/AVPF [RFC3550][RFC4585] profile 52 and RTP header extensions, by defining a new header extension and 53 AVPF feedback packet, and related parameters. 55 TFRC is an equation-based congestion control scheme for unicast flows 56 operating in a best effort Internet environment and competing with 57 TCP traffic. TFRC computes a TCP-friendly data rate based on current 58 network conditions, as represented by the latest round trip time and 59 packet loss calculations. The complete TFRC mechanism is described in 60 detail in [RFC3448.bis]. 62 To calculate a TCP-friendly data rate and keep track of round trip 63 times and packet losses, TFRC senders and receivers rely on 64 exchanging specific information between each other, i.e: the sender 65 provides the receiver with the latest updates to round trip time 66 calculations, while the receiver provides feedback needed to compute 67 round trip times and on packet losses. This memo defines how this 68 information can be exchanged between TFRC senders and receiver with 69 RTP header extensions and an AVPF feedback packet. 71 2. Terminology 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 [RFC2119]. 77 3. Relation to the Datagram Congestion Control Protocol 79 The TFRC congestion control mechanism is one of a set of congestion 80 control methods provided by the Datagram Congestion Control Protocol 81 (DCCP) [RFC4340] In this section we detail the pros and cons of using 82 TFRC with RTP versus DCCP. 84 DCCP is a minimal general purpose transport-layer protocol with 85 unreliable yet congestion controlled packet delivery semantics and 86 reliable connection setup and teardown [RFC4336]. DCCP currently 87 supports both TFRC [RFC4341] and TCP-like [RFC4341] congestion 88 control, and the protocol is structured to support new congestion 89 control mechanisms defined in the future. A DCCP mapping for RTP has 90 been standardised for media applications [RFCxRTP]. In addition DCCP 91 supports a host of other features, such as: use of Explicit 92 Congestion Notification (ECN) and the ECN Nonce, flexible options 93 processing, reliable option negotiation, DTLS [ID.DTLS], Path Maximum 94 Transfer Unit (PMTU) and Service Codes. Naturally an application 95 using RTP/DCCP as its transport protocol will benefit from the 96 protocol features supported by DCCP. 98 However there are a number of benefits to be gained by the 99 development and standardization of the use RTP with TFRC: 101 o Media applications lacking congestion control can incorporate 102 congestion controlled transport without delay by using RTP with 103 TFRC. Widespread deployment of the DCCP protocol is not currently 104 in place. 106 o Use of RTP with TFRC is not contingent on any OS level changes 107 and can be quickly deployed, because RTP is implemented at the 108 application layer. 110 o RTP/UDP flows face the same restrictions in firewall traversal 111 as do UDP flows and do not require NATs and firewall 112 modifications. DCCP flows, on the other hand, do require NAT 113 and firewall modifications, however once these modifications are 114 in place, they can result in easier NAT and firewall traversal 115 for RTP/DCCP flows in the future. 117 o Use of RTP with TFRC with various media applications will give 118 researchers, implementors and developers a better understanding 119 of the intricate relationship between media quality and 120 equation-based congestion control. Hopefully this experience 121 with congestion control and TFRC will ease the migration of media 122 applications to DCCP once DCCP is deployed. 124 Using the AVPF/RTP profile and header extension to support TFRC 125 provides an immediate means for congestion control in media streams, 126 in the time until DCCP is deployed. 128 Additionally, there are also a number of technical differences as to 129 how (and which) congestion control information is exchanged between 130 DCCP with CCID3 and RTP: 132 o Using header extensions the RTP TFRC sender transmits a 133 send timestamp to the RTP TFRC receiver with every data packet. 134 In addition to congestion control the send timestamp can be 135 used by the receiver for jitter calculations. 137 In contrast DCCP with CCID3 transmits a quad round trip 138 counter to the receiver. 140 o The RTP TFRC receiver only provides the RTP TFRC sender 141 with the loss event rate as computed by the receiver. 143 In contrast DCCP with CCID3, provides 2 other options for the 144 transport of loss event rate. A sender may choose to receive 145 loss intervals or an Ack Vector. These two options provide the 146 sender with the necessary information to compute the loss event 147 rate. 149 o Sequence number: DCCP supports a 48 bit and a 24 bit sequence 150 number, whereas RTP only supports a 16 bit sequence number. While 151 this makes RTP susceptible to data injection attacks, it can be 152 avoided by using the SRTP [RFC3711] profile. 154 4. The TFRC Information Exchange Loop 156 TFRC depends on the exchange of congestion control information 157 between a sender and receiver. In this section we reiterate which 158 items are exchanged between a TFRC sender and receiver as discussed 159 in [RFC3448.bis]. We note how RTP can accommodates these exchanges. 161 4.1. Data Packets 163 As stated in [RFC3448.bis] a TFRC sender transmits the following 164 information in each data packet to the receiver: 166 o A sequence number, incremented by one for each data packet 167 transmitted. 169 o A timestamp indicating the packet send time and the sender's 170 current estimate of the round-trip time, RTT. This information 171 is then used by the receiver to compute the TFRC loss intervals. 172 - or - 173 A course-grained timestamp incrementing every quarter of a 174 round trip time, which is then used to determine the TFRC loss 175 intervals. 177 The standard RTP sequence number suffices for the functionality 178 provided by TFRC. A RTP header extension [hdrtxt] is used to 179 transmit the send timestamp and RTT. This extension is defined in 180 Section 5. 182 4.2. Feedback Packets 184 As stated in [RFC3448.bis] a TFRC receiver provides the following 185 feedback to the sender at least once per RTT or per data packet 186 received (which ever time interval is larger): 188 o The send timestamp of the last data packet received, t_i. 190 o The amount of time elapsed between the receipt of the last 191 data packet at the receiver, and the generation of this feedback 192 report, t_delay. This is used by the sender for RTT computations. 194 o The rate at which the receiver estimates that data was received 195 since the last feedback report was sent, x_recv. 197 o The receiver's current estimate of the loss event rate, p, a real 198 value between 0 and 1.0. 200 To accommodate the feedback of these values a new AVPF transport 201 layer feedback message is defined, as detailed in Section 6. 203 5. The Header Extension 205 The form of the extension block is depicted in Figure 1. The length 206 field for the extension takes the value 6 to indicate that the 207 payload is 7 bytes. Two header extension fields are defined and used 208 as follows: 210 Send timestamp (t_i): 32 bits 211 The timestamp indicating when the packet is sent. This timestamp 212 is measured in microseconds and is used for round trip time 213 calculations. 215 Round trip time (RTT): 24 bits 216 The round trip time as measured by the RTP TFRC sender in 217 microseconds. 219 0 1 2 3 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | 0xBE | 0xDE | length=2 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | ID | len=6 | RTT | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | send timestamp (t_i) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 1: RTP Sender Header Extension Block 230 6. TFRC-FB: A New AVPF Transport Layer Feedback Message 232 A new transport layer AVPF feedback message is defined to support 233 feedback from the receivers: TFRC-FB. This message is depicted in 234 Figure 2. It is defined according to [RFC4585] and includes the 235 following four fields: 237 Send timestamp (t_i): 32 bits 238 The send timestamp of the last data packet received by the 239 RTP TFRC receiver, t_i, in microseconds. 241 Delay (t_delay): 32 bits 242 The amount of time elapsed between the receipt of the last data 243 packet at the RTP TFRC receiver, and the generation of this 244 feedback report in microseconds. This is used by the RTP TFRC 245 sender for RTT computations. 247 Data rate (x_recv): 32 bits 248 The rate at which the receiver estimates that data was received 249 since the last feedback report was sent in bytes per second. 251 Loss event rate (p): 32 bits 252 The receiver's current estimate of the loss event rate, p, 253 expressed as a fixed point number with the binary point at the 254 left edge of the field. (That is equivalent to taking the integer 255 part after multiplying the loss event rate by 2^32.) 257 0 1 2 3 258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |V=2|P| FMT=2 | PT=RTPFB | length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | SSRC of packet sender | 263 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 264 | SSRC (SSRC of first source) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | send timestamp (t_i) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | delay (t_delay) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | data rate at the receiver (x_recv) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | loss event rate (p) | 273 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 274 Figure 2: The AVPF TFRC-FB RTCP Transport Layer Feedback Message 276 7. RTCP Transmission Intervals and Bandwidth Requirements 278 When using TFRC rate controlled RTP, the RTCP transmission intervals 279 must be set according to the requirements of the TFRC algorithm. TFRC 280 requires a receiver to generate a feedback ack packet at least once 281 per RTT or per packet received (based on the larger time interval). 282 These requirements are to ensure timely reaction to congestion. 284 The TFRC requirements of receiving feedback once per RTT can at times 285 conflict with the AVP RTCP bandwidth constraints, particularly at 286 small RTTs of 20 ms or less. Assuming only one TFRC-FB report per 287 RTCP compound packet, Table 1 lists the RTCP bandwidths at RTTs of 2, 288 5, 10 and 20 ms and the minimum corresponding RTP data rates, where 289 RTCP(X) <= (0.05)*RTP(X) is true. For example, according to Table 290 1, a TFRC RTP flow of less than 3.2 Mbps and a RTT of 5 ms, can not 291 comply with the 5% RTCP bandwidth constraints (Table 1 assumes each 292 RTCP packet is 100 bytes). RTP flows facing such circumstances 293 should take into account the additional RTCP bandwidth needed when 294 signaling their bandwidth information in SDP [RFC2327]. 296 Based on initial assumptions on round trip time if more than the 297 recommended 5% is needed for RTCP bandwidth, the applications SHOULD 298 use the SDP bandwidth modifiers RS and RR [RFC3556] to signal the 299 amount of RTCP bandwidth needed. If the round trip time assumptions 300 change after the RTP flows start running, the application MAY 301 recalculate the amount of RTCP bandwidth needed and resignal this new 302 value using its signaling protocol of choice. 304 RTT RTCP(X) RTP(X) 305 +------------------------------+ 306 | 20 ms | 40 kbps | 0.8 Mbps | 307 | 10 ms | 80 kbps | 1.6 Mbps | 308 | 5 ms | 160 kbps | 3.2 Mbps | 309 | 2 ms | 400 kbps | 8.0 Mbps | 310 +------------------------------+ 311 Table 1: RTCP bandwidth for TFRC flows with corresponding 312 RTTs of 20, 10, 5 and 2 ms. Assuming, 100 byte RTCP packets 313 and one RTCP packet per RTT. 315 Additionally, to support the transmission of a feedback packet once per 316 RTT, the AVPF T_rr_interval variable MUST NOT be set to a value larger 317 than the current round trip time, RTT, as this would prevent generating 318 feedback packets at least once per RTT (see RFC 4585, Section 3.4,m). 320 8. SDP Example 322 RTP flows using TFRC congestion control MUST signal their use of the 323 AVPF profile and RTCP feedback packets, the round trip time (RTT) and 324 send timestamp extension, and MAY also signal an initial RTCP 325 bandwidth usage: 327 v=0 328 o=alice 2890844526 2890844526 IN IP4 host.example.com 329 s=congestion control with TFRC 330 c=IN IP4 host.example.com 331 m=video 5400 RTP/AVPF 112 332 a=rtpmap:112 H261/90000 333 a=extmap:4 urn:ietf:params:rtp-hdtext:rtt-sendts 334 a=rtcp-fb * tfrc 335 b=AS:400 336 b=RS:800 337 b=RR:4000 339 9. IANA Considerations 341 In this section we detail IANA registry values that need to be 342 registered. 344 The new RTP/AVPF feedback packet, TFRC-FB, must be registered. For 345 the RTPFB range of packets, the following format (FMT) values are 346 needed: 348 Value name: TFRC-FB 349 Long name: TFRC feedback 350 Value: 5 351 Reference: RFC XXXX 353 Also for the AVPF profile, the rtcp-fd-id tfrc must be registered. 355 For the new header extension, the name rtt-sendts must be registered 356 into the rtp-hdrext section of the urn:ietf: namespace, referring to 357 RFC XXXX. 359 10. Security Considerations 361 This memo defines how to use the RTP AVPF profile and the general RTP 362 header extensions to support TFRC congestion control. Therefore RTP 363 packets using these mechanisms are subject to the security 364 considerations discussed in the RTP specification [RFC3550], the 365 RTP/AVPF profile specification [RFC4585] and the general header 366 extensions mechanism [hdrtxt]. Combining these mechanisms does not 367 pose any additional security implications. Applications requiring 368 authentication and integrity protection can use the SAVPF [SAVPF] 369 profile. 371 11. Acknowledgments 373 This memo is based upon work supported by the U.S. National Science 374 Foundation (NSF) under Grant No. 0334182. Any opinions, findings and 375 conclusions or recommendations expressed in this material are those 376 of the authors and do not necessarily reflect the views of NSF. 378 12. Author's Address 380 Ladan Gharai 382 Normative References 384 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 385 Requirement Levels", Internet Engineering Task Force, 386 RFC 2119, March 1997. 388 [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description 389 Protocol", RFC 2327, April 1998. 391 [RFC2434] T. Narten and H. Alvestrand, "Guidelines for Writing an 392 IANA Considerations Section in RFCs", Internet Engineering 393 Task Force, RFC 2434, October 1998. 395 [RFC3550] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, 396 "RTP: A Transport Protocol for Real-Time Applications", 397 Internet Engineering Task Force, RFC 3550 (STD0064), July 398 2003. 400 [RFC3551] H. Schulzrinne and S. Casner, "RTP Profile for Audio and 401 Video Conferences with Minimal Control," RFC 3551 402 (STD0065), July 2003. 404 [RFC3556] S. Casner, "Session Description Protocol (SDP) Bandwidth 405 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 406 3556, July 2003. 408 [RFC3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 409 "The Secure Real-time Transport Protocol", RFC 3711, March 410 2004. 412 [RFC4336] Floyd, S., Handley, M., and E. Kohler, "Problem Statement 413 for the Datagram Congestion Control Protocol (DCCP)", RFC 414 4336, March 2006. 416 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 417 Control Protocol (DCCP)", RFC 4340, March 2006. 419 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 420 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 421 Congestion Control", RFC 4341, March 2006. 423 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram 424 Congestion Control Protocol (DCCP) Congestion Control ID 3: 425 TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. 427 [RFC4585] J. Ott, S. Wenger, A. Sato, C. Burmeister and J. Ray, 428 "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", 429 RFC 4585, July 2006. 431 [RFC3448.bis] M. Handley, S. Floyed, J. Padhye and J. widmer, 432 "TCP Friendly Rate Control (TRFC): Protocol Specification", 433 draft-ietf-dccp-rfc3448bis-01.txt, March 2007. 435 [hdrext] D. Singer, "A general mechanism for RTP Header Extensions", 436 IETF Work in Progress, draft-ietf-avt-rtp-hdrext-xx.txt. 438 [SAVPF] J. Ott, E. Carrara, "Extended Secure RTP Profile for 439 RTCP-based Feedback (RTP/SAVPF)," IETF Work in Progress, 440 draft-ietf-avt-profile-savpf-xx.txt. 442 [RFCxRTP] C. Perkins, "RTP and the Datagram Congestion Control 443 Protocol (DCCP)", IETF Work in Progress, draft-ietf-dccp- 444 rtp-07.txt. 446 [ID.DTLS] T.Phelan, "Datagram Transport Layer Security (DTLS) 447 over the Datagram Congestion Control Protocol (DCCP)", IETF 448 Work in Progress, draft-phelan-dccp-dtls-xx.txt. 450 Informative References 452 13. IPR Notice 454 The IETF takes no position regarding the validity or scope of any 455 Intellectual Property Rights or other rights that might be claimed to 456 pertain to the implementation or use of the technology described in 457 this document or the extent to which any license under such rights 458 might or might not be available; nor does it represent that it has 459 made any independent effort to identify any such rights. Information 460 on the procedures with respect to rights in RFC documents can be 461 found in BCP 78 and BCP 79. 463 Copies of IPR disclosures made to the IETF Secretariat and any 464 assurances of licenses to be made available, or the result of an 465 attempt made to obtain a general license or permission for the use of 466 such proprietary rights by implementers or users of this 467 specification can be obtained from the IETF on-line IPR repository at 468 http://www.ietf.org/ipr. 470 The IETF invites any interested party to bring to its attention any 471 copyrights, patents or patent applications, or other proprietary 472 rights that may cover technology that may be required to implement 473 this standard. Please address the information to the IETF at ietf- 474 ipr@ietf.org. 476 14. Full Copyright Statement 478 Copyright (C) The IETF Trust (2007). 480 This document is subject to the rights, licenses and restrictions 481 contained in BCP 78, and except as set forth therein, the authors 482 retain all their rights. 484 This document and the information contained herein are provided on an 485 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 486 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 487 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 488 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 489 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 490 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.