idnits 2.17.1 draft-ietf-soc-overload-control-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 597 has weird spacing: '...control param...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (February 28, 2011) is 4799 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) == Missing Reference: 'EQUAL 0-100' is mentioned on line 640, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-soc-load-control-event-package-00 == Outdated reference: A later version (-08) exists of draft-ietf-soc-overload-design-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SOC Working Group V. Gurbani, Ed. 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Standards Track V. Hilt 5 Expires: September 1, 2011 Bell Labs/Alcatel-Lucent 6 H. Schulzrinne 7 Columbia University 8 February 28, 2011 10 Session Initiation Protocol (SIP) Overload Control 11 draft-ietf-soc-overload-control-02 13 Abstract 15 Overload occurs in Session Initiation Protocol (SIP) networks when 16 SIP servers have insufficient resources to handle all SIP messages 17 they receive. Even though the SIP protocol provides a limited 18 overload control mechanism through its 503 (Service Unavailable) 19 response code, SIP servers are still vulnerable to overload. This 20 document defines an overload control mechanism for SIP. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 1, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview of operations . . . . . . . . . . . . . . . . . . . . 4 59 4. Via Header Parameters for Overload Control . . . . . . . . . . 5 60 4.1. The oc paramater . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. The oc-algo parameter . . . . . . . . . . . . . . . . . . 6 62 4.3. The oc-validity parameter . . . . . . . . . . . . . . . . 7 63 4.4. The oc-seq parameter . . . . . . . . . . . . . . . . . . . 7 64 5. Creating and updating the overload control parameters . . . . 8 65 6. Determining the 'oc' Parameter Value . . . . . . . . . . . . . 9 66 7. Processing the Overload Control Parameters . . . . . . . . . . 10 67 8. Using the Overload Control Parameter Values . . . . . . . . . 10 68 9. Forwarding the overload control parameters . . . . . . . . . . 11 69 10. Self-Limiting . . . . . . . . . . . . . . . . . . . . . . . . 11 70 11. Responding to an Overload Indication . . . . . . . . . . . . . 12 71 11.1. Message prioritization at the hop before the 72 overloaded server . . . . . . . . . . . . . . . . . . . . 12 73 11.2. Rejecting requests at an overloaded server . . . . . . . . 13 74 12. 100-Trying provisional response and overload control 75 parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 13. Relationship with other IETF SIP load control efforts . . . . 14 77 14. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 15. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 79 15.1. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 15 80 15.1.1. SIP Response Header . . . . . . . . . . . . . . . . . 15 81 15.1.2. SIP Event Package . . . . . . . . . . . . . . . . . . 15 82 15.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 16 83 16. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 18.1. Normative References . . . . . . . . . . . . . . . . . . . 18 87 18.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 89 Appendix B. RFC5390 requirements . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 92 1. Introduction 94 As with any network element, a Session Initiation Protocol (SIP) 95 [RFC3261] server can suffer from overload when the number of SIP 96 messages it receives exceeds the number of messages it can process. 97 Overload can pose a serious problem for a network of SIP servers. 98 During periods of overload, the throughput of a network of SIP 99 servers can be significantly degraded. In fact, overload may lead to 100 a situation in which the throughput drops down to a small fraction of 101 the original processing capacity. This is often called congestion 102 collapse. 104 Overload is said to occur if a SIP server does not have sufficient 105 resources to process all incoming SIP messages. These resources may 106 include CPU processing capacity, memory, network bandwidth, input/ 107 output, or disk resources. 109 For overload control, we only consider failure cases where SIP 110 servers are unable to process all SIP requests due to resource 111 constraints. There are other cases where a SIP server can 112 successfully process incoming requests but has to reject them due to 113 failure conditions unrelated to the SIP server being overloaded. For 114 example, a PSTN gateway that runs out of trunks but still has plenty 115 of capacity to process SIP messages should reject incoming INVITEs 116 using a 488 (Not Acceptable Here) response [RFC4412]. Similarly, a 117 SIP registrar that has lost connectivity to its registration database 118 but is still capable of processing SIP requests should reject 119 REGISTER requests with a 500 (Server Error) response [RFC3261]. 120 Overload control does not apply to these cases and SIP provides 121 appropriate response codes for them. 123 The SIP protocol provides a limited mechanism for overload control 124 through its 503 (Service Unavailable) response code. However, this 125 mechanism cannot prevent overload of a SIP server and it cannot 126 prevent congestion collapse. In fact, the use of the 503 (Service 127 Unavailable) response code may cause traffic to oscillate and to 128 shift between SIP servers and thereby worsen an overload condition. 129 A detailed discussion of the SIP overload problem, the problems with 130 the 503 (Service Unavailable) response code and the requirements for 131 a SIP overload control mechanism can be found in [RFC5390]. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 The normative statements in this specification as they apply to SIP 140 clients and SIP servers assume that both the SIP clients and SIP 141 servers support this specification. If, for instance, only a SIP 142 client supports this specification and not the SIP server, then 143 follows that the normative statements in this specification pertinent 144 to the behavior of a SIP server do not apply to the server that does 145 not support this specification. 147 3. Overview of operations 149 We now explain the overview of how the overload control mechanism 150 operates by introducing the overload control parameters. Section 4 151 provides more details and normative behavior on the parameters listed 152 below. 154 Because overload control is best performed hop-by-hop, the Via 155 parameter is attractive since it allows two adjacent SIP entities to 156 indicate support for, and exchange information associated with 157 overload control. Additional advantages of this choice are discussed 158 in Section 15.1.1. An alternative mechanism using SIP event packages 159 was also considered, and the characteristics of that choice are 160 further outlined in Section 15.1.2. 162 This document defines four new parameters for the SIP Via header for 163 overload control. These parameters provide a SIP mechanism for 164 conveying overload control information between adjacent SIP 165 entities.) These parameters are: 167 1. oc: This parameter serves a dual purpose; when inserted by a SIP 168 client in a request going downstream, the parameter indicates 169 that the SIP client supports overload control. When the 170 downstream SIP server sends a response, the downstream SIP server 171 will add a value to the parameter that indicates a loss rate (in 172 percentage) by which the requests arriving at the downstream SIP 173 server should be reduced. 174 2. oc-algo: This parameter serves a dual purpose: when inserted by a 175 SIP client in a request going downstream, the parameter contains 176 a comma-separated list of the class of overload control algorithm 177 supported by the SIP client. When the downstream SIP server 178 sends a response, the downstream SIP server will pick one 179 overload control algorithm from the list and will pare the list 180 down to include the one chosen algorithm. In this manner, the 181 upstream SIP client and the downstream SIP server can negotiate 182 the specific class of algorithm that is utilized for overload 183 control. 185 3. oc-validity: Inserted by the SIP server sending a response 186 upstream. This parameter contains a value that indicates the 187 time (in millisecond resolution) that the load reduction 188 specified by the "oc" parameter should be in effect. 189 4. oc-seq: Inserted by the SIP server sending a response upstream. 190 This parameter contains a value that indicates the sequence 191 number associated with the "oc" parameter defined above. 193 Consider a SIP client, P1, which is sending requests to another 194 downstream SIP server, P2. The following snippets of SIP messages 195 demonstrate how the overload control parameters work. 197 INVITE sips:user@example.com SIP/2.0 198 Via: SIP/2.0/TLS p1.example.net; 199 branch=z9hG4bK2d4790.1;received=192.0.2.111;oc; 200 oc-algo="loss,rate" 201 ... 203 SIP/2.0 100 Trying 204 Via: SIP/2.0/TLS p1.example.net; 205 branch=z9hG4bK2d4790.1;received=192.0.2.111; 206 oc=20;oc-algo="loss";oc-validity=500; 207 oc-seq=1282321615.781 208 ... 210 In the messages above, the first line is sent by P1 to P2. This line 211 is a SIP request; because P1 supports overload control, it inserts 212 the "oc" parameter in the topmost Via header that it created. 214 The second line --- a SIP response --- shows the topmost Via header 215 amended by P2 according to this specification and sent to P1. 216 Because P2 also supports overload control, it sends back further 217 overload control parameters towards P1 requesting that P1 reduce the 218 incoming traffic by 20% for 500ms. P2 updates the "oc" parameter to 219 add a value and inserts the remaining two parameters, "oc-validity" 220 and "oc-seq". 222 4. Via Header Parameters for Overload Control 224 4.1. The oc paramater 226 This parameter is inserted by the SIP client and updated by the SIP 227 server. 229 A SIP client MUST add an "oc" parameter to the topmost Via header it 230 inserts into the SIP request. This provides an indication to 231 downstream neighbors that this server supports overload control. 233 When inserted into a request by a SIP client to indicate support for 234 overload control, there MUST NOT be a value associated with the 235 parameter. 237 The downstream server MUST add a value to the "oc" parameter in the 238 response going upstream; this value indicates a loss rate (in 239 percentage) by which the requests arriving at the downstream server 240 should be reduced. 242 When adding a value to the "oc" parameter, the downstream server MUST 243 restrain that value to a number between 0 and 100. This value 244 describes the percentage by which the traffic (SIP requests) destined 245 to the SIP server should be reduced. The default value for this 246 parameter is 0. 248 When a SIP client receives a response with the value in the "oc" 249 parameter filled in, it SHOULD reduce, in terms of a percentage, the 250 number of requests going downstream to the SIP server from which it 251 received the response (see Section 11 for pertinent discussion on 252 traffic reduction). 254 4.2. The oc-algo parameter 256 This parameter is inserted by the SIP client and updated by the SIP 257 server. 259 A SIP client MAY add an "oc-algo" parameter to the topmost Via header 260 it inserts into the SIP request. This parameter contains a comma- 261 separated list of a class of overload control algorithms. Currently, 262 three classes of overload control algorithms are known: loss-based, 263 rate-based, and window-based. This document supports overload 264 control through a loss-based mechanism, therefore the single 265 mandatory to implement class of overload control algorithm is loss- 266 based. All implementations that support overload control MUST 267 implement a loss-based overload control mechanism. 269 If a SIP client only supports the loss-based overload control 270 mechanism, then the "oc-algo" parameter can be omitted. When a SIP 271 server receives a request without an "oc-algo" parameter, it MUST NOT 272 add the parameter in the response going upstream as the absence of 273 the parameter in the request implied that the upstream SIP client 274 only supported a loss-based overload control mechanism. 276 If a SIP client supports multiple class of overload control 277 algorithms, then it will insert a comma-separated list in the "oc- 278 algo" parameter value. Each element in the comma-separated list 279 corresponds to the class of overload control algorithms supported by 280 the SIP client. Currently, three classes of overload control 281 algorithms are known: loss-based, rate-based, and window-based. When 282 a downstream SIP server receives a request with a choice of overload 283 control algorithms specified in the "oc-algo" parameter value, it 284 MUST choose one algorithm from the list and MUST pare the list down 285 to include the one chosen algorithm. The pared down list consisting 286 of the chosen algorithm MUST be returned to the upstream SIP client 287 in the response. 289 It is RECOMMENDED that once an upstream SIP client and a downstream 290 SIP server have converged to a mutually agreeable class of overload 291 control algorithm, the agreed upon class stays in effect for a non- 292 trivial duration of time. That is, the adjacent peers MUST NOT 293 renegotiate the overload control algorithm class per transaction, or 294 per request-response message exchange. A rapid renegotiation of the 295 overload control algorithm will not benefit the client or the server 296 as such flapping does not allow the chosen algorithm to measure and 297 fine tune its behavior over a period of time. 299 Exigent realities of deployments of SIP clients and servers 300 necessitate that the overload control algorithm be renegotiated upon 301 a system reboot or a software upgrade, however, frequent 302 renegotiations of the overload control algorithm MUST be avoided. 303 Renegotiation, when desired, is simply accomplished by the SIP client 304 sending a fresh "oc-algo" parameter in a request going downstream. 305 The downstream server, as before, MUST choose one algorithm from the 306 list and MUST pare the list down to include the one chosen algorithm. 307 The pared down list consisting of the chosen algorithm MUST be 308 returned to the upstream SIP client in the response and stays in 309 effect until the next renegotiation. 311 4.3. The oc-validity parameter 313 This parameter is inserted by the SIP server. 315 This parameter contains a value that indicates an interval of time 316 (measured in milliseconds) that the load reduction specified value of 317 the "oc" parameter should be in effect. The default value of the 318 "oc-validity" parameter is 500 (millisecond). 320 The "oc-validity" parameter can only be present in a Via header in 321 conjunction with an "oc" parameter. 323 4.4. The oc-seq parameter 325 This parameter is inserted by the SIP server. 327 This parameter contains a value that indicates the sequence number 328 associated with the "oc" parameter. Some implementations may be 329 capable of updating the overload control information before the 330 validity period specified by the "oc-validity" parameter expires. 331 Such implementations MUST have an increasing value in the "oc-seq" 332 parameter for each response sent to the upstream SIP client. This is 333 to allow the upstream SIP client to properly collate out-of-order 334 responses. 336 5. Creating and updating the overload control parameters 338 A SIP server can provide overload control feedback to its upstream 339 neighbors by providing a value for the "oc" parameter to the topmost 340 Via header field of a SIP response. The topmost Via header is 341 determined after the SIP server has removed its own Via header; i.e., 342 it is the Via header that was generated by the upstream neighbor. 344 Since the topmost Via header of a response will be removed by an 345 upstream neighbor after processing it, overload control feedback 346 contained in the "oc" parameter will not travel beyond the upstream 347 SIP client. A Via header parameter therefore provides hop-by-hop 348 semantics for overload control feedback (see 349 [I-D.ietf-soc-overload-design]) even if the next hop neighbor does 350 not support this specification. 352 The "oc" parameter can be used in all response types, including 353 provisional, success and failure responses (please see Section 12 for 354 special consideration on transporting overload control parameters in 355 a 100-Trying response). A SIP server MAY update the "oc" parameter 356 in all responses it is sending. A SIP server MUST update the "oc" 357 parameter to responses when the transmission of overload control 358 feedback is required by the overload control algorithm to limit the 359 traffic received by the server. I.e., a SIP server MUST update the 360 "oc" parameter when the overload control algorithm sets the value of 361 an "oc" parameter to a value different than the default value. 363 A SIP server that has updated the "oc" parameter to Via header SHOULD 364 also add a "oc-validity" parameter to the same Via header. The "oc- 365 validity" parameter defines the time in milliseconds during which the 366 content (i.e., the overload control feedback) of the "oc" parameter 367 is valid. The default value of the "oc-validity" parameter is 500 368 (millisecond). A SIP server SHOULD use a shorter "oc-validity" time 369 if its overload status varies quickly and MAY use a longer "oc- 370 validity" time if this status is more stable. If the "oc-validity" 371 parameter is not present, its default value is used. The "oc- 372 validity" parameter MUST NOT be used in a Via header that did not 373 originally contain an "oc" parameter when received. Furthermore, 374 when a SIP server receives a request with the topmost Via header 375 containing only an "oc-validity" parameter without the accompanying 376 "oc" parameter. it MUST ignore the "oc-validity" parameter. 378 When a SIP server retransmits a response, it SHOULD use the "oc" 379 parameter value and "oc-validity" parameter value consistent with the 380 overload state at the time the retransmitted response is sent. This 381 implies that the values in the "oc" and "oc-validity" parameters may 382 be different then the ones used in previous retransmissions of the 383 response. Due to the fact that responses sent over UDP may be 384 subject to delays in the network and arrive out of order, the "oc- 385 seq" parameter aids in detecting a stale "oc" parameter value. 387 Implementations that are capable of updating the "oc" and "oc- 388 validity" parameter values for retransmissions MUST insert the "oc- 389 seq" parameter. The value of this parameter MUST be a set of numbers 390 drawn from an increasing sequence. 392 Implementations that are not capable of updating the "oc" and "oc- 393 validity" parameter values for retransmissions --- or implementations 394 that do not want to do so because they will have to regenerate the 395 message to be retransmitted --- MUST still insert a "oc-seq" 396 parameter in the first response associated with a transaction; 397 however, they do not have to update the value in subsequent 398 retransmissions. 400 The "oc-validity" and "oc-seq" Via header parameters are only defined 401 in SIP responses and MUST NOT be used in SIP requests. These 402 parameters are only useful to the upstream neighbor of a SIP server 403 (i.e., the entity that is sending requests to the SIP server) since 404 this is the entity that can offload traffic by redirecting/rejecting 405 new requests. If requests are forwarded in both directions between 406 two SIP servers (i.e., the roles of upstream/downstream neighbors 407 change), there are also responses flowing in both directions. Thus, 408 both SIP servers can exchange overload information. 410 Since overload control protects a SIP server from overload, it is 411 RECOMMENDED that a SIP server use the mechanisms described in this 412 specification. However, if a SIP server wanted to limit its overload 413 control capability for privacy reasons, it MAY decide to perform 414 overload control only for requests that are received on a secure 415 transport channel, such as TLS. This enables a SIP server to protect 416 overload control information and ensure that it is only visible to 417 trusted parties. 419 6. Determining the 'oc' Parameter Value 421 The value of the "oc" parameter is determined by an overload control 422 algorithm (see [I-D.ietf-soc-overload-design]). This specification 423 does not mandate the use of a specific overload control algorithm. 424 However, the output of an overload control algorithm MUST be 425 compliant to the semantics of this Via header parameter. 427 The "oc" parameter value specifies the percentage by which the load 428 forwarded to this SIP server should be reduced. Possible values 429 range from 0 (the traffic forwarded is reduced by 0%, i.e., all 430 traffic is forwarded) to 100 (the traffic forwarded is reduced by 431 100%, i.e., no traffic forwarded). The default value of this 432 parameter is 0. 434 7. Processing the Overload Control Parameters 436 A SIP client compliant to this specification SHOULD remove "oc", "oc- 437 validity" and "oc-seq" parameters from all Via headers of a response 438 received, except for the topmost Via header. This prevents overload 439 control parameters that were accidentally or maliciously inserted 440 into Via headers by a downstream SIP server from traveling upstream. 442 A SIP client maintains the "oc" parameter values received along with 443 the address and port number of the SIP servers from which they were 444 received for the duration specified in the "oc-validity" parameter or 445 the default duration. Each time a SIP client receives a response 446 with an "oc" parameter from a downstream SIP server, it overwrites 447 the "oc" value it has currently stored for this server with the new 448 value received. The SIP client restarts the validity period of an 449 "oc" parameter each time a response with an "oc" parameter is 450 received from this server. A stored "oc" parameter value MUST be 451 discarded once it has reached the end of its validity. 453 8. Using the Overload Control Parameter Values 455 A SIP client compliant to this specification MUST honor overload 456 control values it receives from downstream neighbors. The SIP client 457 MUST NOT forward more requests to a SIP server than allowed by the 458 current "oc" parameter value from a particular downstream server. 460 When forwarding a SIP request, a SIP client uses the SIP procedures 461 of [RFC3263] to determine the next hop SIP server. The procedures of 462 [RFC3263] take as input a SIP URI, extract the domain portion of that 463 URI for use as a lookup key, and query the Domain Name Service (DNS) 464 to obtain an ordered set of one or more IP addresses with a port 465 number and transport corresponding to each IP address in this set 466 (the "Expected Output"). 468 After selecting a specific SIP server from the Expected Output, the 469 SIP client MUST determine if it already has overload control 470 parameter values for the server chosen from the Expected Output. If 471 the SIP client has a non-expired "oc" parameter value for the server 472 chosen from the Expected Output, and this chosen server is operating 473 in overload control mode. Thus, the SIP client MUST determine if it 474 can or cannot forward the current request to the SIP server depending 475 on the nature of the request and the prevailing overload conditions. 477 The particular algorithm used to determine whether or not to forward 478 a particular SIP request is a matter of local policy, and may take 479 into account a variety of prioritization factors. However, this 480 local policy SHOULD generate the same number and rate of SIP requests 481 as the default algorithm (to be determined), which treats all 482 requests as equal. 484 In the absence of a different local policy, the SIP client SHOULD use 485 the following default algorithm to determine if it can forward the 486 request downstream (TODO: Need to devise an algorithm. The original 487 simple algorithm based on random number generation does not suffice 488 for all cases.) 490 9. Forwarding the overload control parameters 492 A SIP client MAY forward the content of an "oc" parameter it has 493 received from a downstream neighbor on to its upstream neighbor. 494 However, forwarding the content of the "oc" parameter is generally 495 NOT RECOMMENDED and should only be performed if permitted by the 496 configuration of SIP servers. For example, a SIP server that only 497 relays messages between exactly two SIP servers may forward an "oc" 498 parameter. The "oc" parameter is forwarded by copying it from the 499 Via in which it was received into the next Via header (i.e., the Via 500 header that will be on top after processing the response). If an 501 "oc-validity" parameter is present, MUST be copied along with the 502 "oc" parameter. 504 10. Self-Limiting 506 In some cases, a SIP client may not receive a response from a 507 downstream server after sending a request. RFC3261 [RFC3261] defines 508 that when a timeout error is received from the transaction layer, it 509 MUST be treated as if a 408 (Request Timeout) status code has been 510 received. If a fatal transport error is reported by the transport 511 layer, it MUST be treated as a 503 (Service Unavailable) status code. 513 In the event of repeated timeouts or fatal transport errors, the SIP 514 client MUST stop sending requests to this server. The SIP client 515 SHOULD occasionally forward a single request to probe if the 516 downstream server is alive. Once a SIP client has successfully 517 transmitted a request to the downstream server, the SIP client can 518 resume normal traffic rates. It should, of course, honor any "oc" 519 parameters it may receive subsequent to resuming normal traffic 520 rates. 522 OPEN ISSUE: If a downstream neighbor does not respond to a request 523 at all, the upstream SIP client will stop sending requests to the 524 downstream neighbor. The upstream SIP client will periodically 525 forward a single request to probe the health of its downstream 526 neighbor. It has been suggested --- see http://www.ietf.org/ 527 mail-archive/web/sip-overload/current/msg00229.html --- that we 528 have a notification mechanism in place for the downstream neighbor 529 to signal to the upstream SIP client that it is ready to receive 530 requests. This notification scheme has advantages, but comes with 531 obvious disadvantages as well. Need some more discussion around 532 this. 534 11. Responding to an Overload Indication 536 A SIP client can receive overload control feedback indicating that it 537 needs to reduce the traffic it sends to its downstream server. The 538 client can accomplish this task by sending some of the requests that 539 would have gone to the overloaded element to a different destination. 540 It needs to ensure, however, that this destination is not in overload 541 and capable of processing the extra load. A client can also buffer 542 requests in the hope that the overload condition will resolve quickly 543 and the requests still can be forwarded in time. In many cases, 544 however, it will need to reject these requests. 546 11.1. Message prioritization at the hop before the overloaded server 548 During an overload condition, a SIP client needs to prioritize 549 requests and select those requests that need to be rejected or 550 redirected. While this selection is largely a matter of local 551 policy, certain heuristics can be suggested. One, during overload 552 control, the SIP client should preserve existing dialogs as much as 553 possible. This suggests that mid-dialog requests MAY be given 554 preferential treatment. Similarly, requests that result in releasing 555 resources (such as a BYE) MAY also be given preferential treatment. 557 A SIP client SHOULD honor the local policy for prioritizing SIP 558 requests such as policies based on the content of the Resource- 559 Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) 560 RPH contents may indicate high priority requests that should be 561 preserved as much as possible during overload. The RPH contents can 562 also indicate a low-priority request that is eligible to be dropped 563 during times of overload. Other indicators, such as the SOS URN 564 [RFC5031] indicating an emergency request, may also be used for 565 prioritization. 567 Local policy could also include giving precedence to mid-dialog SIP 568 requests (re-INVITEs, UPDATEs, BYEs etc.) in times of overload. A 569 local policy can be expected to combine both the SIP request type and 570 the prioritization markings, and SHOULD be honored when overload 571 conditions prevail. 573 A SIP client SHOULD honor user-level load control filters installed 574 by signaling neighbors [I-D.ietf-soc-load-control-event-package] by 575 sending the SIP messages that matched the filter downstream. 577 11.2. Rejecting requests at an overloaded server 579 If the upstream SIP client to the overloaded server does not support 580 overload control, it will continue to direct requests to the 581 overloaded server. Thus, the overloaded server must bear the cost of 582 rejecting some session requests as well as the cost of processing 583 other requests to completion. It would be fair to devote the same 584 amount of processing at the overloaded server to the combination of 585 rejection and processing as the overloaded server would devote to 586 processing requests from an upstream SIP client that supported 587 overload control. This is to ensure that SIP servers that do not 588 support this specification don't receive an unfair advantage over 589 those that do. 591 A SIP server that is under overload and has started to throttle 592 incoming traffic MUST reject this request with a "503 (Service 593 Unavailable)" response without Retry-After header to reject a 594 fraction of requests from upstream neighbors that do not support 595 overload control. 597 12. 100-Trying provisional response and overload control parameters 599 The overload control information sent from a SIP server to a client 600 is transported in the responses. While implementations can insert 601 overload control information in any response, special attention 602 should be accorded to overload control information transported in a 603 100-Trying response. 605 Traditionally, the 100-Trying response has been used in SIP to quench 606 retransmissions. In some implementations, the 100-Trying message may 607 not be generated by the transaction user (TU) nor consumed by the TU. 608 In these implementations, the 100-Trying response is generated at the 609 transaction layer and sent to the upstream SIP client. At the 610 receiving SIP client, the 100-Trying is consumed at the transaction 611 layer by inhibiting the retransmission of the corresponding request. 612 Consequently, implementations that insert overload control 613 information in the 100-Trying cannot assume that the upstream SIP 614 client passed the overload control information in the 100-Trying to 615 their corresponding TU. For this reason, implementations that insert 616 overload control information in the 100-Trying MUST re-insert the 617 same (or updated) overload control information in the first non-100 618 response being sent to the upstream SIP client. 620 13. Relationship with other IETF SIP load control efforts 622 The overload control mechanism described in this document is reactive 623 in nature and apart from message prioritization directives listed in 624 Section 11.1 the mechanisms described in this draft will not 625 discriminate requests based on user identity, filtering action and 626 arrival time. SIP networks that require pro-active overload control 627 mechanisms can upload user-level load control filters as described in 628 [I-D.ietf-soc-load-control-event-package]. 630 14. Syntax 632 This specification extends the existing definition of the Via header 633 field parameters of [RFC3261] as follows: 635 via-params = via-ttl / via-maddr 636 / via-received / via-branch 637 / oc / oc-validity 638 / oc-seq / oc-algo / via-extension 640 oc = "oc" [EQUAL 0-100] 641 oc-validity = "oc-validity" [EQUAL delta-ms] 642 oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT 643 oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) 644 DQUOTE 645 algo-list = "loss" / *(other-algo) 646 other-algo = %x41-5A / %x61-7A / %x30-39 648 15. Design Considerations 650 This section discusses specific design considerations for the 651 mechanism described in this document. General design considerations 652 for SIP overload control can be found in 654 [I-D.ietf-soc-overload-design]. 656 15.1. SIP Mechanism 658 A SIP mechanism is needed to convey overload feedback from the 659 receiving to the sending SIP entity. A number of different 660 alternatives exist to implement such a mechanism. 662 15.1.1. SIP Response Header 664 Overload control information can be transmitted using a new Via 665 header field parameter for overload control. A SIP server can add 666 this header parameter to the responses it is sending upstream to 667 provide overload control feedback to its upstream neighbors. This 668 approach has the following characteristics: 670 o A Via header parameter is light-weight and creates very little 671 overhead. It does not require the transmission of additional 672 messages for overload control and does not increase traffic or 673 processing burdens in an overload situation. 674 o Overload control status can frequently be reported to upstream 675 neighbors since it is a part of a SIP response. This enables the 676 use of this mechanism in scenarios where the overload status needs 677 to be adjusted frequently. It also enables the use of overload 678 control mechanisms that use regular feedback such as window-based 679 overload control. 680 o With a Via header parameter, overload control status is inherent 681 in SIP signaling and is automatically conveyed to all relevant 682 upstream neighbors, i.e., neighbors that are currently 683 contributing traffic. There is no need for a SIP server to 684 specifically track and manage the set of current upstream or 685 downstream neighbors with which it should exchange overload 686 feedback. 687 o Overload status is not conveyed to inactive senders. This avoids 688 the transmission of overload feedback to inactive senders, which 689 do not contribute traffic. If an inactive sender starts to 690 transmit while the receiver is in overload it will receive 691 overload feedback in the first response and can adjust the amount 692 of traffic forwarded accordingly. 693 o A SIP server can limit the distribution of overload control 694 information by only inserting it into responses to known upstream 695 neighbors. A SIP server can use transport level authentication 696 (e.g., via TLS) with its upstream neighbors. 698 15.1.2. SIP Event Package 700 Overload control information can also be conveyed from a receiver to 701 a sender using a new event package. Such an event package enables a 702 sending entity to subscribe to the overload status of its downstream 703 neighbors and receive notifications of overload control status 704 changes in NOTIFY requests. This approach has the following 705 characteristics: 707 o Overload control information is conveyed decoupled from SIP 708 signaling. It enables an overload control manager, which is a 709 separate entity, to monitor the load on other servers and provide 710 overload control feedback to all SIP servers that have set up 711 subscriptions with the controller. 712 o With an event package, a receiver can send updates to senders that 713 are currently inactive. Inactive senders will receive a 714 notification about the overload and can refrain from sending 715 traffic to this neighbor until the overload condition is resolved. 716 The receiver can also notify all potential senders once they are 717 permitted to send traffic again. However, these notifications do 718 generate additional traffic, which adds to the overall load. 719 o A SIP entity needs to set up and maintain overload control 720 subscriptions with all upstream and downstream neighbors. A new 721 subscription needs to be set up before/while a request is 722 transmitted to a new downstream neighbor. Servers can be 723 configured to subscribe at boot time. However, this would require 724 additional protection to avoid the avalanche restart problem for 725 overload control. Subscriptions need to be terminated when they 726 are not needed any more, which can be done, for example, using a 727 timeout mechanism. 728 o A receiver needs to send NOTIFY messages to all subscribed 729 upstream neighbors in a timely manner when the control algorithm 730 requires a change in the control variable (e.g., when a SIP server 731 is in an overload condition). This includes active as well as 732 inactive neighbors. These NOTIFYs add to the amount of traffic 733 that needs to be processed. To ensure that these requests will 734 not be dropped due to overload, a priority mechanism needs to be 735 implemented in all servers these request will pass through. 736 o As overload feedback is sent to all senders in separate messages, 737 this mechanism is not suitable when frequent overload control 738 feedback is needed. 739 o A SIP server can limit the set of senders that can receive 740 overload control information by authenticating subscriptions to 741 this event package. 742 o This approach requires each proxy to implement user agent 743 functionality (UAS and UAC) to manage the subscriptions. 745 15.2. Backwards Compatibility 747 An new overload control mechanism needs to be backwards compatible so 748 that it can be gradually introduced into a network and functions 749 properly if only a fraction of the servers support it. 751 Hop-by-hop overload control (see [I-D.ietf-soc-overload-design]) has 752 the advantage that it does not require that all SIP entities in a 753 network support it. It can be used effectively between two adjacent 754 SIP servers if both servers support overload control and does not 755 depend on the support from any other server or user agent. The more 756 SIP servers in a network support hop-by-hop overload control, the 757 better protected the network is against occurrences of overload. 759 A SIP server may have multiple upstream neighbors from which only 760 some may support overload control. If a server would simply use this 761 overload control mechanism, only those that support it would reduce 762 traffic. Others would keep sending at the full rate and benefit from 763 the throttling by the servers that support overload control. In 764 other words, upstream neighbors that do not support overload control 765 would be better off than those that do. 767 A SIP server should therefore use 5xx responses towards upstream 768 neighbors that do not support overload control. The server should 769 reject the same amount of requests with 5xx responses that would be 770 otherwise be rejected/redirected by the upstream neighbor if it would 771 support overload control. If the load condition on the server does 772 not permit the creation of 5xx responses, the server should drop all 773 requests from servers that do not support overload control. 775 16. Security Considerations 777 Overload control mechanisms can be used by an attacker to conduct a 778 denial-of-service attack on a SIP entity if the attacker can pretend 779 that the SIP entity is overloaded. When such a forged overload 780 indication is received by an upstream SIP client, it will stop 781 sending traffic to the victim. Thus, the victim is subject to a 782 denial-of-service attack. 784 An attacker can create forged overload feedback by inserting itself 785 into the communication between the victim and its upstream neighbors. 786 The attacker would need to add overload feedback indicating a high 787 load to the responses passed from the victim to its upstream 788 neighbor. Proxies can prevent this attack by communicating via TLS. 789 Since overload feedback has no meaning beyond the next hop, there is 790 no need to secure the communication over multiple hops. 792 Another way to conduct an attack is to send a message containing a 793 high overload feedback value through a proxy that does not support 794 this extension. If this feedback is added to the second Via headers 795 (or all Via headers), it will reach the next upstream proxy. If the 796 attacker can make the recipient believe that the overload status was 797 created by its direct downstream neighbor (and not by the attacker 798 further downstream) the recipient stops sending traffic to the 799 victim. A precondition for this attack is that the victim proxy does 800 not support this extension since it would not pass through overload 801 control feedback otherwise. 803 A malicious SIP entity could gain an advantage by pretending to 804 support this specification but never reducing the amount of traffic 805 it forwards to the downstream neighbor. If its downstream neighbor 806 receives traffic from multiple sources which correctly implement 807 overload control, the malicious SIP entity would benefit since all 808 other sources to its downstream neighbor would reduce load. 810 The solution to this problem depends on the overload control 811 method. For rate-based and window-based overload control, it is 812 very easy for a downstream entity to monitor if the upstream 813 neighbor throttles traffic forwarded as directed. For percentage 814 throttling this is not always obvious since the load forwarded 815 depends on the load received by the upstream neighbor. 817 17. IANA Considerations 819 This specification defines four new Via header parameters as detailed 820 below in the "Header Field Parameter and Parameter Values" sub- 821 registry as per the registry created by [RFC3968]. The required 822 information is: 824 Header Field Parameter Name Predefined Values Reference 825 __________________________________________________________ 826 Via oc Yes RFCXXXX 827 Via oc-validity Yes RFCXXXX 828 Via oc-seq Yes RFCXXXX 829 Via oc-algo Yes RFCXXXX 831 RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC 832 number of this specification.] 834 18. References 836 18.1. Normative References 838 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 839 Requirement Levels", BCP 14, RFC 2119, March 1997. 841 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 842 A., Peterson, J., Sparks, R., Handley, M., and E. 843 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 844 June 2002. 846 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 847 Protocol (SIP): Locating SIP Servers", RFC 3263, 848 June 2002. 850 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 851 (IANA) Header Field Parameter Registry for the Session 852 Initiation Protocol (SIP)", BCP 98, RFC 3968, 853 December 2004. 855 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 856 Priority for the Session Initiation Protocol (SIP)", 857 RFC 4412, February 2006. 859 18.2. Informative References 861 [I-D.ietf-soc-load-control-event-package] 862 Shen, C., Schulzrinne, H., and A. Koike, "A Session 863 Initiation Protocol (SIP) Load Control Event Package", 864 draft-ietf-soc-load-control-event-package-00 (work in 865 progress), January 2011. 867 [I-D.ietf-soc-overload-design] 868 Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design 869 Considerations for Session Initiation Protocol (SIP) 870 Overload Control", draft-ietf-soc-overload-design-04 (work 871 in progress), December 2010. 873 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 874 Emergency and Other Well-Known Services", RFC 5031, 875 January 2008. 877 [RFC5390] Rosenberg, J., "Requirements for Management of Overload in 878 the Session Initiation Protocol", RFC 5390, December 2008. 880 Appendix A. Acknowledgements 882 Many thanks to Bruno Chatras, Keith Drage, Janet Gunn, Rich Terpstra, 883 Daryl Malas, R. Parthasarathi, Antoine Roly, Jonathan Rosenberg, 884 Charles Shen, Rahul Srivastava, Padma Valluri, Shaun Bharrat, and 885 Paul Kyzivat for their contributions to this specification. 887 Appendix B. RFC5390 requirements 889 Table 1 provides a summary how this specification fulfills the 890 requirements of [RFC5390]. A more detailed view on how each 891 requirements is fulfilled is provided after the table. 893 +-------------+-------------------+ 894 | Requirement | Meets requirement | 895 +-------------+-------------------+ 896 | REQ 1 | Yes | 897 | REQ 2 | Yes | 898 | REQ 3 | Partially | 899 | REQ 4 | Partially | 900 | REQ 5 | Partially | 901 | REQ 6 | Not applicable | 902 | REQ 7 | Yes | 903 | REQ 8 | Partially | 904 | REQ 9 | Yes | 905 | REQ 10 | Yes | 906 | REQ 11 | Yes | 907 | REQ 12 | Yes | 908 | REQ 13 | Yes | 909 | REQ 14 | Yes | 910 | REQ 15 | Yes | 911 | REQ 16 | Yes | 912 | REQ 17 | Partially | 913 | REQ 18 | Yes | 914 | REQ 19 | Yes | 915 | REQ 20 | Yes | 916 | REQ 21 | Yes | 917 | REQ 22 | Yes | 918 | REQ 23 | Yes | 919 +-------------+-------------------+ 921 Summary of meeting requirements in RFC5390 923 Table 1 925 REQ 1: The overload mechanism shall strive to maintain the overall 926 useful throughput (taking into consideration the quality-of-service 927 needs of the using applications) of a SIP server at reasonable 928 levels, even when the incoming load on the network is far in excess 929 of its capacity. The overall throughput under load is the ultimate 930 measure of the value of an overload control mechanism. 932 Meeting REQ 1: Yes, the overload control mechanism allows an 933 overloaded SIP server to maintain a reasonable level of throughput as 934 it enters into congestion mode by requesting the upstream clients to 935 reduce traffic destined downstream. 937 REQ 2: When a single network element fails, goes into overload, or 938 suffers from reduced processing capacity, the mechanism should strive 939 to limit the impact of this on other elements in the network. This 940 helps to prevent a small-scale failure from becoming a widespread 941 outage. 943 Meeting REQ 2: Yes. When a SIP server enters overload mode, it will 944 request the upstream clients to throttle the traffic destined to it. 945 As a consequence of this, the overloaded SIP server will itself 946 generate proportionally less downstream traffic, thereby limiting the 947 impact on other elements in the network. 949 REQ 3: The mechanism should seek to minimize the amount of 950 configuration required in order to work. For example, it is better 951 to avoid needing to configure a server with its SIP message 952 throughput, as these kinds of quantities are hard to determine. 954 Meeting REQ 3: Partially. On the server side, the overload condition 955 is determined monitoring S (c.f., Section 4 of 956 [I-D.ietf-soc-overload-design]) and reporting a load feedback F as a 957 value to the "oc" parameter. On the client side, a throttle T is 958 applied to requests going downstream based on F. This specification 959 does not prescribe any value for S, nor a particular value for F. The 960 "oc-algo" parameter allows for automatic convergence to a particular 961 class of overload control algorithm. There are suggested default 962 values for the "oc-validity" parameter. 964 REQ 4: The mechanism must be capable of dealing with elements that do 965 not support it, so that a network can consist of a mix of elements 966 that do and don't support it. In other words, the mechanism should 967 not work only in environments where all elements support it. It is 968 reasonable to assume that it works better in such environments, of 969 course. Ideally, there should be incremental improvements in overall 970 network throughput as increasing numbers of elements in the network 971 support the mechanism. 973 Meeting REQ 4: Partially. The mechanism is designed to reduce 974 congestion when a pair of communicating entities support it. If a 975 downstream overloaded SIP server does not respond to a request in 976 time, a SIP client conformant to this specification will attempt to 977 reduce traffic destined towards the non-responsive server as outlined 978 in Section 10. 980 REQ 5: The mechanism should not assume that it will only be deployed 981 in environments with completely trusted elements. It should seek to 982 operate as effectively as possible in environments where other 983 elements are malicious; this includes preventing malicious elements 984 from obtaining more than a fair share of service. 986 Meeting REQ 5: Partially. Since overload control information is 987 shared between a pair of communicating entities, a confidential and 988 authenticated channel can be used for this communication. However, 989 if such a channel is not available, then the security ramifications 990 outlined in Section 16 apply. 992 REQ 6: When overload is signaled by means of a specific message, the 993 message must clearly indicate that it is being sent because of 994 overload, as opposed to other, non overload-based failure conditions. 995 This requirement is meant to avoid some of the problems that have 996 arisen from the reuse of the 503 response code for multiple purposes. 997 Of course, overload is also signaled by lack of response to requests. 998 This requirement applies only to explicit overload signals. 1000 Meeting REQ 6: Not applicable. Overload control information is 1001 signaled as part of the Via header and not in a new header. 1003 REQ 7: The mechanism shall provide a way for an element to throttle 1004 the amount of traffic it receives from an upstream element. This 1005 throttling shall be graded so that it is not all- or-nothing as with 1006 the current 503 mechanism. This recognizes the fact that "overload" 1007 is not a binary state and that there are degrees of overload. 1009 Meeting REQ 7: Yes, please see Section 8 and Section 11. 1011 REQ 8: The mechanism shall ensure that, when a request was not 1012 processed successfully due to overload (or failure) of a downstream 1013 element, the request will not be retried on another element that is 1014 also overloaded or whose status is unknown. This requirement derives 1015 from REQ 1. 1017 Meeting REQ 8: Partially. A SIP client that has overload information 1018 from multiple downstream servers will not retry the request on 1019 another element. However, if a SIP client does not know the overload 1020 status of a downstream server, it may send the request to that 1021 server. 1023 REQ 9: That a request has been rejected from an overloaded element 1024 shall not unduly restrict the ability of that request to be submitted 1025 to and processed by an element that is not overloaded. This 1026 requirement derives from REQ 1. 1028 Meeting REQ 9: Yes, a SIP client conformant to this specification 1029 will send the request to a different element. 1031 REQ 10: The mechanism should support servers that receive requests 1032 from a large number of different upstream elements, where the set of 1033 upstream elements is not enumerable. 1035 Meeting REQ 10: Yes, there are no constraints on the number of 1036 upstream clients. 1038 REQ 11: The mechanism should support servers that receive requests 1039 from a finite set of upstream elements, where the set of upstream 1040 elements is enumerable. 1042 Meeting REQ 11: Yes, there are no constraints on the number of 1043 upstream clients. 1045 REQ 12: The mechanism should work between servers in different 1046 domains. 1048 Meeting REQ 12: Yes, there are no inherent limitations on using 1049 overload control between domains. 1051 REQ 13: The mechanism must not dictate a specific algorithm for 1052 prioritizing the processing of work within a proxy during times of 1053 overload. It must permit a proxy to prioritize requests based on any 1054 local policy, so that certain ones (such as a call for emergency 1055 services or a call with a specific value of the Resource-Priority 1056 header field [RFC4412]) are given preferential treatment, such as not 1057 being dropped, being given additional retransmission, or being 1058 processed ahead of others. 1060 Meeting REQ 13: Yes, please see Section 11. 1062 REQ 14: REQ 14: The mechanism should provide unambiguous directions 1063 to clients on when they should retry a request and when they should 1064 not. This especially applies to TCP connection establishment and SIP 1065 registrations, in order to mitigate against avalanche restart. 1067 Meeting REQ 14: Yes, Section 10 provides normative behavior on when 1068 to retry a request after repeated timeouts and fatal transport errors 1069 resulting from communications with a non-responsive downstream SIP 1070 server. 1072 REQ 15: In cases where a network element fails, is so overloaded that 1073 it cannot process messages, or cannot communicate due to a network 1074 failure or network partition, it will not be able to provide explicit 1075 indications of the nature of the failure or its levels of congestion. 1076 The mechanism must properly function in these cases. 1078 Meeting REQ 15: Yes, Section 10 provides normative behavior on when 1079 to retry a request after repeated timeouts and fatal transport errors 1080 resulting from communications with a non-responsive downstream SIP 1081 server. 1083 REQ 16: The mechanism should attempt to minimize the overhead of the 1084 overload control messaging. 1086 Meeting REQ 16: Yes, overload control messages are sent in the 1087 topmost Via header, which is always processed by the SIP elements. 1089 REQ 17: The overload mechanism must not provide an avenue for 1090 malicious attack, including DoS and DDoS attacks. 1092 Meeting REQ 17: Partially. Since overload control information is 1093 shared between a pair of communicating entities, a confidential and 1094 authenticated channel can be used for this communication. However, 1095 if such a channel is not available, then the security ramifications 1096 outlined in Section 16 apply. 1098 REQ 18: The overload mechanism should be unambiguous about whether a 1099 load indication applies to a specific IP address, host, or URI, so 1100 that an upstream element can determine the load of the entity to 1101 which a request is to be sent. 1103 Meeting REQ 18: Yes, please see discussion in Section 8. 1105 REQ 19: The specification for the overload mechanism should give 1106 guidance on which message types might be desirable to process over 1107 others during times of overload, based on SIP-specific 1108 considerations. For example, it may be more beneficial to process a 1109 SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh with 1110 a non-zero expiration (since the former reduces the overall amount of 1111 load on the element), or to process re-INVITEs over new INVITEs. 1113 Meeting REQ 19: Yes, please see Section 11. 1115 REQ 20: In a mixed environment of elements that do and do not 1116 implement the overload mechanism, no disproportionate benefit shall 1117 accrue to the users or operators of the elements that do not 1118 implement the mechanism. 1120 Meeting REQ 20: Yes, an element that does not implement overload 1121 control does not receive any measure of extra benefit. 1123 REQ 21: The overload mechanism should ensure that the system remains 1124 stable. When the offered load drops from above the overall capacity 1125 of the network to below the overall capacity, the throughput should 1126 stabilize and become equal to the offered load. 1128 Meeting REQ 21: Yes, the overload control mechanism described in this 1129 draft ensures the stability of the system. 1131 REQ 22: It must be possible to disable the reporting of load 1132 information towards upstream targets based on the identity of those 1133 targets. This allows a domain administrator who considers the load 1134 of their elements to be sensitive information, to restrict access to 1135 that information. Of course, in such cases, there is no expectation 1136 that the overload mechanism itself will help prevent overload from 1137 that upstream target. 1139 Meeting REQ 22: Yes, an operator of a SIP server can configure the 1140 SIP server to only report overload control information for requests 1141 received over a confidential channel, for example. However, note 1142 that this requirement is in conflict with REQ 3, as it introduces a 1143 modicum of extra configuration. 1145 REQ 23: It must be possible for the overload mechanism to work in 1146 cases where there is a load balancer in front of a farm of proxies. 1148 Meeting REQ 23: Yes. Depending on the type of load balancer, this 1149 requirement is met. A load balancer fronting a farm of SIP proxies 1150 could be a SIP-aware load balancer or one that is not SIP-aware. If 1151 the load balancer is SIP-aware, it can make conscious decisions on 1152 throttling outgoing traffic towards the individual server in the farm 1153 based on the overload control parameters returned by the server. On 1154 the other hand, if the load balancer is not SIP-aware, then there are 1155 other strategies to perform overload control. Section 6 of 1156 [I-D.ietf-soc-overload-design] documents some of these strategies in 1157 more detail (see discussion related to Figure 3(a) in Section 6). 1159 Authors' Addresses 1161 Vijay K. Gurbani (editor) 1162 Bell Laboratories, Alcatel-Lucent 1163 1960 Lucent Lane, Rm 9C-533 1164 Naperville, IL 60563 1165 USA 1167 Email: vkg@bell-labs.com 1169 Volker Hilt 1170 Bell Labs/Alcatel-Lucent 1171 791 Holmdel-Keyport Rd 1172 Holmdel, NJ 07733 1173 USA 1175 Email: volkerh@bell-labs.com 1176 Henning Schulzrinne 1177 Columbia University/Department of Computer Science 1178 450 Computer Science Building 1179 New York, NY 10027 1180 USA 1182 Phone: +1 212 939 7004 1183 Email: hgs@cs.columbia.edu 1184 URI: http://www.cs.columbia.edu