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