idnits 2.17.1 draft-ietf-sip-congestsafe-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 359 has weird spacing: '... where prox...' -- 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 (Aug 01, 2002) is 7936 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 83 == Unused Reference: '1' is defined on line 408, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 411, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 414, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2223 (ref. '3') (Obsoleted by RFC 7322) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP -- Session Initiation Protocol D. Willis 3 Working Group B. Campbell 4 Internet-Draft dynamicsoft Inc. 5 Expires: January 30, 2003 Aug 01, 2002 7 Session Initiation Protocol Extension to Assure Congestion Safety 8 draft-ietf-sip-congestsafe-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 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 http:// 26 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 This Internet-Draft will expire on January 30, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 The Session Initiation Protocol allows the use of UDP for transport 40 of SIP messages. The use of UDP inherently risks network congestion 41 problems, as UDP itself does not define congestion prevention, 42 avoidance, detection, or correction mechanisms. This problem is 43 aggravated by large SIP messages which fragment at the UDP level. 44 Transport protocols in SIP are also negotiated on a per-hop basis, at 45 the SIP level, so SIP proxies may convert from TCP to UDP and so 46 forth. This document defines what it means for SIP nodes to be 47 congestion safe and specifies an extension by which a SIP User Agent 48 may require that its requests are treated in a congestion safe 49 manner. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Definition of Congestion Safety for SIP . . . . . . . . . . . 3 59 4. Assuring Transitive Congestion Safety with Proxy-Require . . . 4 61 5. Responsible use of SIP over UDP . . . . . . . . . . . . . . . 4 62 5.1 Requirements For Use of SIP Over UDP . . . . . . . . . . . . . 6 63 5.2 Pacing SIP Requests Over UDP . . . . . . . . . . . . . . . . . 6 64 5.3 Proxy Rejects Requests That Would Require UDP Fragmentation . 7 66 6. Syntax of Extensions and Changes to SIP Specifications . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 72 Normative References . . . . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 76 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 78 1. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. Background 86 The Session Initiation Protocol RFC 3261 [4] provides application 87 support over multiple transport protocols, including UDP and TCP. 88 Transport negotiation is not "end to end" with SIP. Instead, each 89 SIP hop individually determines which transport to use. For example, 90 a User Agent (UA) may use TCP to talk to a proxy, that proxy my use 91 UDP to talk to another proxy, and that second proxy may use SCTP to 92 talk to a destination UA. 94 UDP has inherent issues with congestion management. The protocol has 95 not explicit mechanisms for avoiding, detecting, or adapting to 96 network congestion. SIP attempts to deal with this in two ways: 97 1. Retransmission timers with exponential back offs. 98 2. Attempting to limit the size of transmissions over UDP to reduce 99 the effects of fragmentation. 101 This would appear to be an incomplete solution. One solution might 102 be to deprecate UDP entirely for SIP. However, there is a large 103 installed base using UDP, and there are legitimately places where UDP 104 appears to be quite useful such as tiny mobile phones and in 105 extremely high-volume proxies connecting over dedicated networks. 107 As an alternative, this draft: 108 1. Defines what it means for a SIP node to be "congestion-safe". 109 2. Defines a mechanism whereby a congestion-safe UA may require that 110 any proxy processing its requests be congestion safe. 111 3. Defines a mechanism whereby a proxy may reject a request that it 112 would be forced to fragment, and in so doing inform the 113 originating UA of relevant sizing parameters. 115 3. Definition of Congestion Safety for SIP 117 A SIP node can be considered "congestion safe" if it never emits a 118 request in a manner not known to be congestion safe. Requests may be 119 considered congestion-safe if any one of the following criteria is 120 met: 121 1. The transport toward the next SIP hop is TCP, SCTP, or other 122 transport providing congestion control and the next hop is known 123 to be either a UA or a congestion-safe proxy. 124 2. The transport toward the next hop is UDP, the next hop is known 125 to be a UA or congestion-safe proxy, and the network between the 126 two is known to support congestion management at a lower layer. 127 Note that this is an uncomoon case in typical Internet 128 applications. 129 3. If the only available transport toward the next hop is UDP and 130 the next hop is known to be a UA or congestion-safe proxy, the 131 request MAY be transmitted over UDP or rejected by local policy. 132 If the request is transmitted over UDP, the procedures described 133 under the heading "Responsible use of SIP over UDP" in this 134 document MUST be followed. 136 The preceding uses the phrase "the next hop is known to be either a 137 UA or a congestion-safe proxy." Such knowledge may be derived either 138 through administrative configuration or through use of the Proxy- 139 Require mechanism defined herein under the heading "Assuring 140 Transitive Congestion Safety with Proxy-Require". 142 4. Assuring Transitive Congestion Safety with Proxy-Require 144 SIP provides a mechanism whereby a user agent making a request can be 145 assured that any proxy servicing that request support a specific 146 extension or set of behavior. To do so, the user agent includes a 147 "Proxy-Require" header field with a value indicating a tag for the 148 specific extension or behavior required. There is an IANA 149 registration process for these tags. Proxies not recognizing a 150 specific tag or unwilling to support the associated behavior MUST 151 reject a request referincing that tag with a 420 response, which has 152 the semantic "Unsupported". 154 We herein define a tag value of "congestion-safe". A proxy 155 forwarding a request containing a Proxy-Require with this tag value 156 MUST manifest the property of congestion-safety as defined by this 157 document. 159 5. Responsible use of SIP over UDP 161 The fundamental problem with UDP is that it provides no feedback 162 mechanism to allow a sender to pace its transmissions against the 163 real performance of the network. While this tends to have no 164 significant effect on extremely low-volume sender-receiver pairs, the 165 impact of high-volume relationships on the network can be severe. 166 Consider the following scenario, wherein the traffic between multiple 167 UAs is funnelled through a single proxy-proxy relationship. 169 Example of large-fan out/fan-in likely to encounter congestion: 171 UA1----\ /----UA10 172 UA2-----\ /-----UA11 173 UA3------\ /------UA12 174 UA4-------\ /-------UA13 175 UA5--------P1------P2--------UA14 176 UA6-------/ \-------UA15 177 UA7------/ \------UA16 178 UA8-----/ \-----UA17 179 UA9----/ \----UA18 181 In this scenario, any requests from UA(1..9) to UA(10..18) traverse 182 the proxy-proxy link P1<-->P2. Assuming current SIP practices, if 183 this link is UDP and every UA emits a request simultaneously, each 184 proxy will insert nine (one for each UA) requests, resulting in 185 eighteen simultaneous requests on the P1<-->P2 link. Each request 186 may require retransmissions, and large requests may require 187 fragmentation to fit the link MTU -- at the worst case, producing 188 more than one hundred packets per request, or approximately 2,000 189 simultaneously expressed packets in this scenario. If the capacity 190 of link P1<-->P2 is inadequate to deliver these messages within the 191 SIP retransmission window, the originating UAs (or the proxies, if 192 acting in transaction-stateful mode) generate retransmissions, 193 further compounding the problem into a "retransmission storm". Real- 194 world scenarios may scale far more seriously. It is not unreasonable 195 to assume that there may be tens of thousands of UAs on each side of 196 the network. 198 Clearly the best thing to do is to use a more sophisticated transport 199 protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and 200 its associated proxy. If this is not feasible, it may be necessary 201 to fall back to UDP. This is especially common in the case of low- 202 capacity UAs such as those proposed for 3G wireless systems. 204 It should be noted that the fundamental problem not just between UAs 205 and proxies, but whenever there is a high fan-out or fan-in ration. 206 If in the above example, each UA were behind a "residential proxy", 207 the problem would occur in similar fashion. 209 One might propose that SIP ALWAYS use a congestion-controlled 210 transport to talk to proxies, and only fall back to UDP when the next 211 hop is a UA. The primary problem with this approach is that in 212 general, a SIP node does not and cannot know whether the next node is 213 a UA or a proxy -- it is this ability to "insert" proxies into a 214 sequence that provides much of the flexibility of SIP. A secondary 215 problem is that even if the next hop is a UA, some UAs are 216 sufficienty high volume, and some links sufficiently narrow, that 217 congestion might still result from the incautious use of UDP. 219 5.1 Requirements For Use of SIP Over UDP 221 The previously described problems with the general use of SIP over 222 UDP lead to the following two requirements for the use of UDP as a 223 transport protocol for SIP: 224 1. Large messages MUST NOT be transmitted over UDP. The SIP 225 specification provides basic guidance for UAs. Congestion-safe 226 proxies MUST follow the procedures described below under the 227 heading "Proxy Rejects Request That Would Require UDP 228 Fragmentation." UAs MAY also make use of the MTU feedback 229 techniques in that section. 230 2. Nodes sending requests over UDP MUST pace those requests as 231 described under the heading "Pacing SIP requests over UDP." 233 Response messages SHOULD be constrained to be smaller than the MTUs 234 established for requests by the preceding mechanisms, and systems 235 implementors should remain aware that SIP provides limited support 236 for managing response sizes. Further experience may indicate a need 237 for further control over response handling. 239 5.2 Pacing SIP Requests Over UDP 241 One simple way to describe the congestion problem is that UDP lets us 242 send packets without knowing whether those packets are arriving. The 243 simplest approach to dealing with this at the application level is to 244 send a request, then wait for some sort of response indicating that 245 the request was received before sending anything else. This produces 246 an effect described by some as "ping-ponging" -- traffic bounces back 247 and forth between two nodes like a ping-pong ball or tennis ball in a 248 match. Since there's only one ball in play between any two players 249 at any given time, most of the potential for congestion cascades is 250 eliminated. 252 This pacing or serialization approach has the side-effect of 253 significantly reducing the maximum throughput, as transmission occurs 254 in only one direction at a time and there is at least a 2xRTT delay 255 between transmissions. More sophisticated algorithms such as those 256 in TCP and SCTP have been developed to address this, and it would be 257 inappropriate to duplicate that work here. Consequently, if greater 258 efficiency is required than that provided by this simple approach, 259 implementors should use TCP, SCTP, or another such protocol. But if 260 one absolutely must use UDP, this approach works, and is reasonably 261 efficient in the most likely application of "edge proxy" to UA and 262 other proxies with large fan-outs to individual low-volume nodes. 264 SIP has two sorts of request transactions: "invite" and "non-invite" 265 tranactions. Invite transaction use a three way sequence of 266 "request, response, acknowledgement" and may include a "provisional 267 response" between the request and response steps. Non-invite 268 transactions use a two-way "request, response" sequence, and may also 269 have a provisional response although that behavior has been 270 deprecated. 272 Congestion-safe use of SIP over UDP requires waiting for some sort of 273 response to a request (or a timeout, which has backoff properties) 274 before sending another request to that same destination. A 275 congestion-safe SIP node (UA or proxy) MUST NOT send a request to a 276 given next-hop if there is an existing request to that destination 277 which has not received some sort of response. The existing 278 transaction MUST either receive a response (final or provisional) or 279 time-out before a new request can be made to that next-hop. 281 This effectively requires congestion-safe proxies to act in a 282 transaction-stateful manner on a per-next-hop destination basis, at 283 least to the extent of tracking whether some sort of request is 284 pending to each next-hop and correlating provisional and final 285 responses to that request. 287 Some may argue that this puts an excessive burden onto the SIP node, 288 and that implementations that are "congestion-safe" per this 289 specification will have reduced performance when used with UDP over a 290 shared or public network. We counter that congestion-safe transport 291 protocols are readily available, and that network users which insist 292 on using unsafe transports (such as UDP) MUST be responsible for 293 assuring that they do not impede the function of other users of the 294 network, even at the expense of reducing their own efficiency. It is 295 simply irresponsible to "blast away" at the network without regard 296 for congestion or its impact on other users of the network. 298 5.3 Proxy Rejects Requests That Would Require UDP Fragmentation 300 A proxy may be faced with a request to deliver a large message using 301 UDP as a transport. Fragmentation of such messages is problematic in 302 several ways. Loss of any fragment requires time-out and 303 retransmission of the message. The fragments are commonly 304 transmitted out the interface at local interface (usually LAN) rates, 305 without awareness of intervening network conditions. For these 306 reason, we believe it in general a bad practice to send large 307 requests over UDP. 309 While the actual MTU of a link may not be known, common practice 310 seems to indicate that the local interface MTU is likely to be a 311 reasonable approximation. Where the actual path MTU is known, that 312 value should be used instead. 314 When a congestion-safe SIP proxy processing a request determines that 315 the next hop is reached via UDP, and that the request is larger than 316 the effective MTU toward that hop and would consequently be 317 fragmented, the proxy MUST reject that request with a 513 response. 319 The base SIP specification provides minimal guidance on dealing with 320 oversized requests. There is an error response code, 513, with the 321 semantic "request too large" that seems applicable. However, SIP 322 provides no guidance on how to indicate what size might be allowed. 323 We define here two extension header fields that may be used in a 513 324 response to indicate by the rejecting proxy the size of message 325 allowed by that proxy. The extension header field "Proxy-Max-Size" 326 may be used to indicate the largest allowable request to the 327 originating UA. The extension header field "Proxy-Seen-Size" may be 328 used to indicate the size of the rejected request as calculated by 329 the rejecting proxy. In both cases, the size value used indicates 330 the SIP message size, which does not include IP or transport protocol 331 overhead. 333 A congestion-safe SIP proxy which rejects a request based on size 334 SHOULD include a "Proxy-Max-Size" header field with a value 335 indicating the largest size message allowed by this proxy on this 336 link. If a Proxy-Max-Size header field is sent, the proxy MUST also 337 include a "Proxy-Seen-Size" header indicating the size of the request 338 as seen at this proxy. 340 A UA receiving a 513 response has the options of giving up, trying a 341 smaller request, or trying a different set of proxies. Should it 342 choose to try a smaller request, it may estimate the size of the 343 largest message that can be sent by taking the original request size, 344 subtracting it from the value of the Proxy-Seen-Size header field, 345 and subtracting that result from the value of the Proxy-max-Size 346 header field. 348 6. Syntax of Extensions and Changes to SIP Specifications 350 The syntax for the Proxy-Max-Size header field is: 352 Proxy-Max-Size = "Proxy-Max-Size" HCOLON 1*DIGIT 354 The syntax for the Proxy-Seen-Size header field is: 356 Proxy-Seen-Size = "Proxy-Seen-Size" HCOLON 1*DIGIT 357 Additions to SIP Table 3: 359 Header field where proxy ACK BYE CAN INV OPT REG PRA 360 _______________________________________________________________ 361 Proxy-Max-Size 513 a - - - - - - 362 Proxy-Seen-Size 513 a - - - - - - - 364 7. IANA Considerations 366 This document defines the SIP extension header fields "Proxy-Max- 367 Size" and "Proxy-Seen-Size" ", which IANA will add to the registry of 368 SIP header fields defined in RFC 3261 [4]. 370 This document also defines the SIP option tag "congestion-safe" which 371 IANA will add to the registry of SIP option tags defined in RFC 3261 372 [4]. 374 The following is the registration for the Proxy-Max-Size header 375 field: 377 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 378 this specification.] 380 Header Field Name: Proxy-Max-Size 382 Compact Form: none 384 The following is the registration for the Proxy-Seen-Size header 385 field: 387 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 388 this specification.] 390 Header Field Name: Proxy-Seen-Size 392 Compact Form: none 394 The following is the registration for the congestion-safe option tag: 396 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 397 this specification.] 399 Option Tag: congestion-safe 401 8. Acknowledgements 403 Robert Sparks and Jonathan Rosenberg argued with us vociferously over 404 this topic and contributed substantial insight. 406 Normative References 408 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 409 9, RFC 2026, October 1996. 411 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 412 Levels", BCP 14, RFC 2119, March 1997. 414 [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 415 2223, October 1997. 417 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 418 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 419 Session Initiation Protocol", RFC 3261, June 2002. 421 Authors' Addresses 423 Dean Willis 424 dynamicsoft Inc. 425 5100 Tennyson Parkway 426 Suite 1200 427 Plano, TX 75028 428 US 430 Phone: +1 972 473 5455 431 EMail: dean.willis@softarmor.com 432 URI: http://www.dynamicsoft.com/ 434 Ben Campbell 435 dynamicsoft Inc. 436 5100 Tennyson Parkway 437 Suite 1200 438 Plano, TX 75028 439 US 441 Phone: +1 972 473 5452 442 EMail: bcampbell@dynamicsoft.com 443 URI: http://www.dynamicsoft.com/ 445 Full Copyright Statement 447 Copyright (C) The Internet Society (2002). All Rights Reserved. 449 This document and translations of it may be copied and furnished to 450 others, and derivative works that comment on or otherwise explain it 451 or assist in its implementation may be prepared, copied, published 452 and distributed, in whole or in part, without restriction of any 453 kind, provided that the above copyright notice and this paragraph are 454 included on all such copies and derivative works. However, this 455 document itself may not be modified in any way, such as by removing 456 the copyright notice or references to the Internet Society or other 457 Internet organizations, except as needed for the purpose of 458 developing Internet standards in which case the procedures for 459 copyrights defined in the Internet Standards process must be 460 followed, or as required to translate it into languages other than 461 English. 463 The limited permissions granted above are perpetual and will not be 464 revoked by the Internet Society or its successors or assigns. 466 This document and the information contained herein is provided on an 467 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 468 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 469 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 470 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 471 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 473 Acknowledgement 475 Funding for the RFC Editor function is currently provided by the 476 Internet Society.