idnits 2.17.1 draft-ietf-sip-congestsafe-02.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 -- 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 (October 13, 2003) is 7500 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 90 == Unused Reference: '1' is defined on line 420, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 423, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 426, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 433, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2223 (ref. '3') (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 3427 (ref. '5') (Obsoleted by RFC 5727) Summary: 4 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: April 12, 2004 October 13, 2003 7 Session Initiation Protocol Extension to Assure Congestion Safety 8 draft-ietf-sip-congestsafe-02 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 other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 12, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The Session Initiation Protocol allows the use of UDP for transport 39 of SIP messages. The use of UDP inherently risks network congestion 40 problems, as UDP itself does not define congestion prevention, 41 avoidance, detection, or correction mechanisms. This problem is 42 aggravated by large SIP messages which fragment at the UDP level. 43 Transport protocols in SIP are also negotiated on a per-hop basis, at 44 the SIP level, so SIP proxies may convert from TCP to UDP and so 45 forth. This document defines by which a SIP User Agent may require 46 that its requests are not sent over UDP or other transports having 47 congestion-related characteristics similar to those of UDP. 49 Table of Contents 51 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Assuring Transitive Congestion-Managed Transport with 58 Require and Proxy-Require . . . . . . . . . . . . . . . . . 5 60 5. New Behaviors at SIP Nodes . . . . . . . . . . . . . . . . . 5 61 5.1 Behavior at the UAC . . . . . . . . . . . . . . . . . . . . 5 62 5.1.1 Sending a Request . . . . . . . . . . . . . . . . . . . . . 5 63 5.1.2 Receiving a 514 Response to a Request . . . . . . . . . . . 6 64 5.1.3 Receiving a 515 Response to a Request . . . . . . . . . . . 6 65 5.1.4 Receiving a 516 Response to a Request . . . . . . . . . . . 6 66 5.2 Behavior at the Proxy . . . . . . . . . . . . . . . . . . . 6 67 5.2.1 Proxy Rejects Request Requiring Congestion Management 68 When Route with Congestion Management Not Available . . . . 7 69 5.2.2 Proxy Rejects Request Not Requiring Congestion 70 Management When Forwarding That Request Would Induce 71 Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2.3 Forwarding of Responses . . . . . . . . . . . . . . . . . . 7 73 5.3 Behavior at the UAS . . . . . . . . . . . . . . . . . . . . 8 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 Normative References . . . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 83 Intellectual Property and Copyright Statements . . . . . . . 11 85 1. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Background 93 The Session Initiation Protocol [4] provides application support over 94 multiple transport protocols, including UDP and TCP. Extensions to 95 support SCTP are under consideration, and other transport protocols 96 may be proposed for future use. Transport negotiation is not "end to 97 end" with SIP. Instead, each SIP hop individually determines which 98 transport to use towards the next hop. For example, a User Agent 99 Client (UAC) may use TCP to talk to a proxy, that proxy my use UDP to 100 talk to another proxy, and that second proxy may use SCTP to talk to 101 a destination User Agent Server (UAS). 103 UDP has inherent issues with congestion management or reliability. 104 The protocol has no explicit mechanisms for avoiding, detecting, or 105 adapting to network congestion. SIP attempts to deal with this in two 106 ways: 107 1. Retransmission timers with exponential back offs. 108 2. Attempting to limit the size of transmissions over UDP to reduce 109 the effects of fragmentation. 111 The fundamental problem with UDP is that it provides no feedback 112 mechanism to allow a sender to pace its transmissions against the 113 real performance of the network. While this tends to have no 114 significant effect on extremely low-volume sender-receiver pairs, the 115 impact of high-volume relationships on the network can be severe. 116 Consider the following scenario, wherein the traffic between multiple 117 UAs is funnelled through a single proxy-proxy relationship. 119 Example of large-fan out/fan-in likely to encounter congestion: 121 UA1----\ /----UA10 122 UA2-----\ /-----UA11 123 UA3------\ /------UA12 124 UA4-------\ /-------UA13 125 UA5--------P1------P2--------UA14 126 UA6-------/ \-------UA15 127 UA7------/ \------UA16 128 UA8-----/ \-----UA17 129 UA9----/ \----UA18 130 Figure 1 132 In this scenario, any requests from UA(1..9) to UA(10..18) traverse 133 the proxy-proxy link P1<-->P2. Assuming current SIP practices, if 134 this link is UDP and every UA emits a request simultaneously, each 135 proxy will insert nine (one for each UA) requests, resulting in 136 eighteen simultaneous requests on the P1<-->P2 link. Each request 137 may require retransmissions, and large requests may require 138 fragmentation to fit the link MTU -- at the worst case, producing 139 more than one hundred packets per request, or approximately 2,000 140 simultaneously expressed packets in this scenario. If the capacity of 141 link P1<-->P2 is inadequate to deliver these messages within the 142 SIP retransmission window, the originating UAs (or the proxies, if 143 acting in transaction-stateful mode) generate retransmissions, 144 further compounding the problem into a "retransmission storm". 145 Real-world scenarios may scale far more seriously. It is not 146 unreasonable to assume that there may be tens of thousands of UAs on 147 each side of the network. 149 It should be noted that the fundamental problem not just between UAs 150 and proxies, but whenever there is a high fan-out or fan-in ratio. If 151 in the above example, each UA were behind a "residential proxy", the 152 problem would occur in similar fashion. 154 3. Scope of Work 156 One solution might be to deprecate UDP entirely for SIP. However, 157 there is a large installed base using UDP, and there are legitimately 158 places where UDP appears to be quite useful such as tiny mobile 159 phones and in extremely high-volume proxies connecting over dedicated 160 networks. 162 As an alternative, this draft defines mechanisms whereby: 163 1. a UAC may require that any proxy processing its requests transmit 164 those requests over a transport protocol providing congestion 165 management. 166 2. a UAC may inform a UAS receiving its requests that those requests 167 were transmitted over a route supporting congestion management, 168 and require that that UAS respond in similar fashion. 169 3. A proxy may reject requests that require congestion-managed 170 transport when that proxy finds that the only route it has to the 171 next hop is over transport that does not support congestion 172 management. 173 4. A proxy may reject requests that would be fragmented, even for 174 requests that do not indicate a requirement for 175 congestion-managed transport. 176 5. A UAS may reject requests that would result in responses that 177 require congestion-managed transport if the originating request 178 did not require congestion-managed transport. 180 Note that SIP has no fundamental mechanism whereby a proxy may reject 181 a response. This precludes requiring congestion management for 182 responses being processed by a proxy except as provided by the 183 original request. If, due to an issue of network topology change or 184 similar event between the processing of the request and the 185 processing of the response by a proxy the only path available to the 186 proxy is not congestion managed, the proxy has no choice but to send 187 the response over that path. It's not perfect, but seems to be all we 188 can do at this time. 190 4. Assuring Transitive Congestion-Managed Transport with Require and 191 Proxy-Require 193 SIP provides mechanisms whereby a user agent making a request can be 194 assured that any proxy servicing or UAS responding to that request 195 support a specific extension or set of behavior. 197 To be assured that a proxy servicing the request meets the 198 requirements, the UAC includes a "Proxy-Require" header field with a 199 value indicating a tag for the specific extension or behavior 200 required. As per [4], proxies not recognizing a specific tag or 201 unwilling to support the associated behavior reject a request 202 referencing that tag with a 420 response, which has the semantic "Bad 203 Extension". 205 To be assured that a UAS responding to a request meets the 206 requirements, the UAC includes a "Require" header field with a value 207 indicating a tag for the specific extension or behavior required. As 208 per [4], UASs not recognizing a specific tag or unwilling to support 209 the associated behavior reject a request referencing that tag with a 210 420 response, which has the semantic "Bad Extension". 212 We herein define a an option-tag value of "congestion-managed". 213 There is an IANA registration process for these tags defined in [4], 214 and the "IANA Considerations" of this document fulfills the 215 requirements of the IANA registration process. 217 5. New Behaviors at SIP Nodes 219 5.1 Behavior at the UAC 221 5.1.1 Sending a Request 223 A UAC exercising this extension adds a Require header field and a 224 Proxy-Require header field value including the option tag 225 "congestion-managed" to each request. 227 For any request that exercises this extension (i.e., contains the 228 "congestion-managed" option tags), the UAC MUST transmit the request 229 using a protocol that supports congestion maangement. 231 Any UA supporting this extension SHOULD exercise this extension on 232 all initial requests. 234 5.1.2 Receiving a 514 Response to a Request 236 A 514 response (semantic "No available route with congestion 237 management) indicates that an intermediate proxy found that its only 238 vailable routes toward the required next hop did not support 239 congestion management. A UA receiving a 514 response has the options 240 of giving up, trying the request without the "Proxy-Require: 241 congestion-management" (which will likely return a 516) or trying a 242 different set of proxies, presumably through using a different 243 pre-loaded Route header field. 245 5.1.3 Receiving a 515 Response to a Request 247 A 515 response (semantic "Response requires congestion management") 248 indicates that the response generated by the UAS responding to the 249 request is larger than the UAS' understanding of path MTU and that 250 the UAS does not know that the route indicated by the VIA headers is 251 over congestion-managed transport. A UAC receiving a 515 to a 252 request may either retry the request in a congestion-managed manner 253 (adding the "congestion-managed" option tag to Require and 254 Proxy-Require)) or abandon the request. 256 5.1.4 Receiving a 516 Response to a Request 258 A 516 response (semantic "Proxying of request would induce 259 fragmentation") indicates that a proxy forwarding the request 260 detected that the request was larger than the next hop link MTU from 261 that proxy and that the transport protocol toward that next hop does 262 not support congestion management. A UAS receiving a 516 response may 263 retry the request with a "Proxy-Require: congestion-management" added 264 (which will probably return a 514), retry the request using an 265 alternate route, or abandon the request. 267 5.2 Behavior at the Proxy 269 A proxy forwarding a request containing a Proxy-Require with this tag 270 value MUST trasmit that request using a transport protocol (such as 271 TCP) supporting congestion-management. All proxies SHOULD attempt to 272 reduce fragmentation following the procedure described below. 274 5.2.1 Proxy Rejects Request Requiring Congestion Management When Route 275 with Congestion Management Not Available 277 When a SIP proxy processing a request marked with a Proxy-Require 278 header field containing the value "congestion-managed" determines 279 that the next hop is reachable only via a transport proocol not 280 supporting congestion management (such as UDP) the proxy MUST reject 281 that request with a 514 response. 283 5.2.2 Proxy Rejects Request Not Requiring Congestion Management When 284 Forwarding That Request Would Induce Fragmentation 286 When a SIP proxy supporting this extension and processing a request 287 not marked with a Proxy-Require header field containing the value 288 "congestion-managed" determines that the next hop is reachable only 289 via a transport protocol not supporting congestion management (such 290 as UDP) and the size of the request is larger than the MTU of the 291 interface towards that next hop, the proxy MUST reject that request 292 with a 516 response. 294 5.2.3 Forwarding of Responses 296 When any proxy supporting this extension forwards a request or 297 response and there is a choice of transport protocols toward the next 298 hop, the proxy SHOULD choose a transport protocol supporting 299 congestion management if one is available. 301 When a proxy supporting this extension forwards a response containing 302 a Proxy-Require header field with the option-tag "congestion-managed" 303 as a value and the relevant Via header field value allows for a 304 choice of transport protocols, the proxy MUST select a transport 305 supporting congestion management if such a transport is available. 307 SIP provides no mechanism whereby a proxy may reject a response. 308 Consequently, proxies may receive responses that require 309 fragmentation over a transport not supporting congestion management. 310 One example of a situation where this might be expected to occur is 311 as follows: A UAC not supporting this extension makes a request via 312 UDP. This request transits the proxy in question without inducing 313 fragmentation. The responding UAS generates a response that is larger 314 than the request. When the proxy prepares to send the request, it 315 finds that the increase in size now requires fragmentation. 316 Discarding the response would result in a timeout and retransmission 317 of the request and response, thereby doing more harm than good. There 318 seems to be nothing that the proxy can do to correct the situation, 319 so it MUST forward the response as specified in [4]. 321 5.3 Behavior at the UAS 323 A user agent server server (UAS) receiving a SIP request generates a 324 response to that request. Delivery of this response may raise issues 325 of congestion management. Because SIP requires that responses 326 traverse exactly the reverse of the route taken by the request 327 (recorded in the Via: header field values), the server has no options 328 about routing the response. If the request was delivered in a 329 congestion-managed manner, it is likely that the response will also 330 be returned in a congestion-managed manner, as it must traverse 331 exactly this recorded route. However, if the request was NOT received 332 in a congestion-managed manner, the server cannot negotiate a 333 congestion-managed path for the response, as the response must follow 334 the path of the request. 336 When a UAS supporting this extension responds to a request over a 337 route supporting congestion management (as indicated by the presence 338 of the congestion-managed option tag in the request), the UAS MUST 339 include the congestion-managed option tag in a "Proxy-Require" header 340 field in the response. Furthermore, it MUST transmit that response 341 using a protocol supporting congestion management. If it is unable to 342 transmit the response using a protocol supporting congestion 343 management, it MUST reject the request and return an error response 344 using response code 515, which has the semantic of "Response requires 345 congestion management." 347 When a UAS supporting this extension generates a response to a 348 request that is larger than the UAS' understanding of path MTU and 349 that request was not received over a congestion-managed route (as 350 indicated by the presence of a "Require: congestion-managed"), it 351 cannot be assumed that the response can be safely transmitted. As the 352 UAS cannot respond safely, it SHOULD reject the request and return an 353 error response using response code 515, which has the semantic of 354 "Response requires congestion management". Note that this does not 355 absolutely preclude fragmentation of the response, as the request may 356 be fragmented by intervening routers. However, this sort of 357 fragmentation is outside of the UAS' capacity to detect or control. 359 6. IANA Considerations 361 This document defines the SIP option tag "congestion-managed" which 362 IANA will add to the registry of SIP option tags defined in [4]. 364 This document defines the SIP response code 514, with the semantic 365 "No congestion-managed route available" which IANA will add to the 366 registry of SIP response codes defined in [4] in the section for 5xx 367 clase response codes. 369 This document defines the SIP response code 515, with the semantic 370 "Response requires congestion management" which IANA will add to the 371 registry of SIP response codes defined in [4] in the section for 5xx 372 clase response codes. 374 This document defines the SIP response code 516, with the semantic 375 "Proxying of request would induce fragmentation" which IANA will add 376 to the registry of SIP response codes defined in [4] in the section 377 for 5xx clase response codes. 379 The following is the registration for the congestion-managed option 380 tag: 382 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 383 this specification.] 385 Option Tag: congestion-managed 387 The following is the registration for the SIP response code 514: 389 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 390 this specification.] 392 Response Code: 514 No available route with congestion management 394 The following is the registration for the SIP response code 515: 396 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 397 this specification.] 399 Response Code: 515 Response requires congestion management 401 The following is the registration for the SIP response code 516: 403 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 404 this specification.] 406 Response Code: 516 Proxying of request would induce fragmentation 408 7. Acknowledgements 410 This document is a product of the SIP Working Group and contains 411 input from many contributors in that group. The named authors of this 412 document claim no personal contribution to the content excecpt as 413 provided in their capacity as participants in the working group. 414 Rather, they have attempted to act only in an editorial fashion, 415 documenting the consensus of the working group as it emerged. 416 Somebody had to do the typing. 418 Normative References 420 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 421 9, RFC 2026, October 1996. 423 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 424 Levels", BCP 14, RFC 2119, March 1997. 426 [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 427 2223, October 1997. 429 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 430 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 431 Session Initiation Protocol", RFC 3261, June 2002. 433 [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 434 Rosen, "Change Process for the Session Initiation Protocol 435 (SIP)", BCP 67, RFC 3427, December 2002. 437 Authors' Addresses 439 Dean Willis 440 dynamicsoft Inc. 441 5100 Tennyson Parkway 442 Suite 1200 443 Plano, TX 75028 444 US 446 Phone: +1 972 473 5455 447 EMail: dean.willis@softarmor.com 448 URI: http://www.dynamicsoft.com/ 450 Ben Campbell 451 dynamicsoft Inc. 452 5100 Tennyson Parkway 453 Suite 1200 454 Plano, TX 75028 455 US 457 Phone: +1 972 473 5452 458 EMail: bcampbell@dynamicsoft.com 459 URI: http://www.dynamicsoft.com/ 461 Intellectual Property Statement 463 The IETF takes no position regarding the validity or scope of any 464 intellectual property or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; neither does it represent that it 468 has made any effort to identify any such rights. Information on the 469 IETF's procedures with respect to rights in standards-track and 470 standards-related documentation can be found in BCP-11. Copies of 471 claims of rights made available for publication and any assurances of 472 licenses to be made available, or the result of an attempt made to 473 obtain a general license or permission for the use of such 474 proprietary rights by implementors or users of this specification can 475 be obtained from the IETF Secretariat. 477 The IETF invites any interested party to bring to its attention any 478 copyrights, patents or patent applications, or other proprietary 479 rights which may cover technology that may be required to practice 480 this standard. Please address the information to the IETF Executive 481 Director. 483 Full Copyright Statement 485 Copyright (C) The Internet Society (2003). All Rights Reserved. 487 This document and translations of it may be copied and furnished to 488 others, and derivative works that comment on or otherwise explain it 489 or assist in its implementation may be prepared, copied, published 490 and distributed, in whole or in part, without restriction of any 491 kind, provided that the above copyright notice and this paragraph are 492 included on all such copies and derivative works. However, this 493 document itself may not be modified in any way, such as by removing 494 the copyright notice or references to the Internet Society or other 495 Internet organizations, except as needed for the purpose of 496 developing Internet standards in which case the procedures for 497 copyrights defined in the Internet Standards process must be 498 followed, or as required to translate it into languages other than 499 English. 501 The limited permissions granted above are perpetual and will not be 502 revoked by the Internet Society or its successors or assignees. 504 This document and the information contained herein is provided on an 505 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 506 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 507 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 508 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 509 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 511 Acknowledgement 513 Funding for the RFC Editor function is currently provided by the 514 Internet Society.