idnits 2.17.1 draft-ietf-soc-overload-control-01.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 598 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 (January 20, 2011) is 4843 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 642, 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: July 24, 2011 Bell Labs/Alcatel-Lucent 6 H. Schulzrinne 7 Columbia University 8 January 20, 2011 10 Session Initiation Protocol (SIP) Overload Control 11 draft-ietf-soc-overload-control-01 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 July 24, 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 . . . . . . . . . . . . . . . . . . 18 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 365 "oc_validity" parameter defines the time in milliseconds during which 366 the content (i.e., the overload control feedback) of the "oc" 367 parameter is valid. The default value of the "oc_validity" parameter 368 is 500 (millisecond). A SIP server SHOULD use a shorter 369 "oc_validity" time if its overload status varies quickly and MAY use 370 a longer "oc_validity" time if this status is more stable. If the 371 "oc_validity" parameter is not present, its default value is used. 372 The "oc_validity" parameter MUST NOT be used in a Via header that did 373 not 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", 437 "oc_validity" and "oc-seq" parameters from all Via headers of a 438 response received, except for the topmost Via header. This prevents 439 overload control parameters that were accidentally or maliciously 440 inserted into Via headers by a downstream SIP server from traveling 441 upstream. 443 A SIP client maintains the "oc" parameter values received along with 444 the address and port number of the SIP servers from which they were 445 received for the duration specified in the "oc_validity" parameter or 446 the default duration. Each time a SIP client receives a response 447 with an "oc" parameter from a downstream SIP server, it overwrites 448 the "oc" value it has currently stored for this server with the new 449 value received. The SIP client restarts the validity period of an 450 "oc" parameter each time a response with an "oc" parameter is 451 received from this server. A stored "oc" parameter value MUST be 452 discarded once it has reached the end of its validity. 454 8. Using the Overload Control Parameter Values 456 A SIP client compliant to this specification MUST honor overload 457 control values it receives from downstream neighbors. The SIP client 458 MUST NOT forward more requests to a SIP server than allowed by the 459 current "oc" parameter value from a particular downstream server. 461 When forwarding a SIP request, a SIP client uses the SIP procedures 462 of [RFC3263] to determine the next hop SIP server. The procedures of 463 [RFC3263] take as input a SIP URI, extract the domain portion of that 464 URI for use as a lookup key, and query the Domain Name Service (DNS) 465 to obtain an ordered set of one or more IP addresses with a port 466 number and transport corresponding to each IP address in this set 467 (the "Expected Output"). 469 After selecting a specific SIP server from the Expected Output, the 470 SIP client MUST determine if it already has overload control 471 parameter values for the server chosen from the Expected Output. If 472 the SIP client has a non-expired "oc" parameter value for the server 473 chosen from the Expected Output, and this chosen server is operating 474 in overload control mode. Thus, the SIP client MUST determine if it 475 can or cannot forward the current request to the SIP server depending 476 on the nature of the request and the prevailing overload conditions. 478 The particular algorithm used to determine whether or not to forward 479 a particular SIP request is a matter of local policy, and may take 480 into account a variety of prioritization factors. However, this 481 local policy SHOULD generate the same number and rate of SIP requests 482 as the default algorithm (to be determined), which treats all 483 requests as equal. 485 In the absence of a different local policy, the SIP client SHOULD use 486 the following default algorithm to determine if it can forward the 487 request downstream (TODO: Need to devise an algorithm. The original 488 simple algorithm based on random number generation does not suffice 489 for all cases.) 491 9. Forwarding the overload control parameters 493 A SIP client MAY forward the content of an "oc" parameter it has 494 received from a downstream neighbor on to its upstream neighbor. 495 However, forwarding the content of the "oc" parameter is generally 496 NOT RECOMMENDED and should only be performed if permitted by the 497 configuration of SIP servers. For example, a SIP server that only 498 relays messages between exactly two SIP servers may forward an "oc" 499 parameter. The "oc" parameter is forwarded by copying it from the 500 Via in which it was received into the next Via header (i.e., the Via 501 header that will be on top after processing the response). If an 502 "oc_validity" parameter is present, MUST be copied along with the 503 "oc" parameter. 505 10. Self-Limiting 507 In some cases, a SIP client may not receive a response from a 508 downstream server after sending a request. RFC3261 [RFC3261] defines 509 that when a timeout error is received from the transaction layer, it 510 MUST be treated as if a 408 (Request Timeout) status code has been 511 received. If a fatal transport error is reported by the transport 512 layer, it MUST be treated as a 503 (Service Unavailable) status code. 514 In the event of repeated timeouts or fatal transport errors, the SIP 515 client MUST stop sending requests to this server. The SIP client 516 SHOULD occasionally forward a single request to probe if the 517 downstream server is alive. Once a SIP client has successfully 518 transmitted a request to the downstream server, the SIP client can 519 resume normal traffic rates. It should, of course, honor any "oc" 520 parameters it may receive subsequent to resuming normal traffic 521 rates. 523 OPEN ISSUE: If a downstream neighbor does not respond to a request 524 at all, the upstream SIP client will stop sending requests to the 525 downstream neighbor. The upstream SIP client will periodically 526 forward a single request to probe the health of its downstream 527 neighbor. It has been suggested --- see http://www.ietf.org/ 528 mail-archive/web/sip-overload/current/msg00229.html --- that we 529 have a notification mechanism in place for the downstream neighbor 530 to signal to the upstream SIP client that it is ready to receive 531 requests. This notification scheme has advantages, but comes with 532 obvious disadvantages as well. Need some more discussion around 533 this. 535 11. Responding to an Overload Indication 537 A SIP client can receive overload control feedback indicating that it 538 needs to reduce the traffic it sends to its downstream server. The 539 client can accomplish this task by sending some of the requests that 540 would have gone to the overloaded element to a different destination. 541 It needs to ensure, however, that this destination is not in overload 542 and capable of processing the extra load. An client can also buffer 543 requests in the hope that the overload condition will resolve quickly 544 and the requests still can be forwarded in time. In many cases, 545 however, it will need to reject these requests. 547 11.1. Message prioritization at the hop before the overloaded server 549 During an overload condition, a SIP client needs to prioritize 550 requests and select those requests that need to be rejected or 551 redirected. While this selection is largely a matter of local 552 policy, certain heuristics can be suggested. One, during overload 553 control, the SIP client should preserve existing dialogs as much as 554 possible. This suggests that mid-dialog requests MAY be given 555 preferential treatment. Similarly, requests that result in releasing 556 resources (such as a BYE) MAY also be given preferential treatment. 558 A SIP client SHOULD honor the local policy for prioritizing SIP 559 requests such as policies based on the content of the Resource- 560 Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) 561 RPH contents may indicate high priority requests that should be 562 preserved as much as possible during overload. The RPH contents can 563 also indicate a low-priority request that is eligible to be dropped 564 during times of overload. Other indicators, such as the SOS URN 565 [RFC5031] indicating an emergency request, may also be used for 566 prioritization. 568 Local policy could also include giving precedence to mid- dialog SIP 569 requests (re-INVITEs, UPDATEs, BYEs etc.) in times of overload. A 570 local policy can be expected to combine both the SIP request type and 571 the prioritization markings, and SHOULD be honored when overload 572 conditions prevail. 574 A SIP client SHOULD honor user-level load control filters installed 575 by signaling neighbors [I-D.ietf-soc-load-control-event-package] by 576 sending the SIP messages that matched the filter downstream. 578 11.2. Rejecting requests at an overloaded server 580 If the upstream SIP client to the overloaded server does not support 581 overload control, it will continue to direct requests to the 582 overloaded server. Thus, the overloaded server must bear the cost of 583 rejecting some session requests as well as the cost of processing 584 other requests to completion. It would be fair to devote the same 585 amount of processing at the overloaded server to the combination of 586 rejection and processing as the overloaded server would devote to 587 processing requests from an upstream SIP client that supported 588 overload control. This is to ensure that SIP servers that do not 589 support this specification don't receive an unfair advantage over 590 those that do. 592 A SIP server that is under overload and has started to throttle 593 incoming traffic MUST reject this request with a "503 (Service 594 Unavailable)" response without Retry-After header to reject a 595 fraction of requests from upstream neighbors that do not support 596 overload control. 598 12. 100-Trying provisional response and overload control parameters 600 The overload control information sent from a SIP server to a client 601 is transported in the responses. While implementations can insert 602 overload control information in any response, special attention 603 should be accorded to overload control information transported in a 604 100-Trying response. 606 Traditionally, the 100-Trying response has been used in SIP to quench 607 retransmissions. In some implementations, the 100-Trying message may 608 not be generated by the transaction user (TU) nor consumed by the TU. 610 In these implementations, the 100-Trying response is generated at the 611 transaction layer and sent to the upstream SIP client. At the 612 receiving SIP client, the 100-Trying is consumed at the transaction 613 layer by inhibiting the retransmission of the corresponding request. 614 Consequently, implementations that insert overload control 615 information in the 100-Trying cannot assume that the upstream SIP 616 client passed the overload control information in the 100-Trying to 617 their corresponding TU. For this reason, implementations that insert 618 overload control information in the 100-Trying MUST re-insert the 619 same (or updated) overload control information in the first non-100 620 response being sent to the upstream SIP client. 622 13. Relationship with other IETF SIP load control efforts 624 The overload control mechanism described in this document is reactive 625 in nature and apart from message prioritization directives listed in 626 Section 11.1 the mechanisms described in this draft will not 627 discriminate requests based on user identity, filtering action and 628 arrival time. SIP networks that require pro-active overload control 629 mechanisms can upload user-level load control filters as described in 630 [I-D.ietf-soc-load-control-event-package]. 632 14. Syntax 634 This specification extends the existing definition of the Via header 635 field parameters of [RFC3261] as follows: 637 via-params = via-ttl / via-maddr 638 / via-received / via-branch 639 / oc / oc-validity 640 / oc-seq / oc-algo / via-extension 642 oc = "oc" [EQUAL 0-100] 643 oc-validity = "oc_validity" [EQUAL delta-ms] 644 oc-seq = (1*12DIGIT "." 1*5DIGIT) 645 oc-algo = DQUOTE algo-list *(COMMA algo-list) DQUOTE 646 algo-list = "loss" / *(other-algo) 647 other-algo = %x41-5A / %x61-7A / %x30-39 649 15. Design Considerations 651 This section discusses specific design considerations for the 652 mechanism described in this document. General design considerations 653 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 [TBD.] 821 18. References 823 18.1. Normative References 825 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 826 Requirement Levels", BCP 14, RFC 2119, March 1997. 828 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 829 A., Peterson, J., Sparks, R., Handley, M., and E. 830 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 831 June 2002. 833 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 834 Protocol (SIP): Locating SIP Servers", RFC 3263, 835 June 2002. 837 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 838 Priority for the Session Initiation Protocol (SIP)", 839 RFC 4412, February 2006. 841 18.2. Informative References 843 [I-D.ietf-soc-load-control-event-package] 844 Shen, C., Schulzrinne, H., and A. Koike, "A Session 845 Initiation Protocol (SIP) Load Control Event Package", 846 draft-ietf-soc-load-control-event-package-00 (work in 847 progress), January 2011. 849 [I-D.ietf-soc-overload-design] 850 Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design 851 Considerations for Session Initiation Protocol (SIP) 852 Overload Control", draft-ietf-soc-overload-design-04 (work 853 in progress), December 2010. 855 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 856 Emergency and Other Well-Known Services", RFC 5031, 857 January 2008. 859 [RFC5390] Rosenberg, J., "Requirements for Management of Overload in 860 the Session Initiation Protocol", RFC 5390, December 2008. 862 Appendix A. Acknowledgements 864 Many thanks to Keith Drage, Janet Gunn, Rich Terpstra, Daryl Malas, 865 R. Parthasarathi, Jonathan Rosenberg, Charles Shen, Rahul Srivastava, 866 Padma Valluri, Shaun Bharrat, and Paul Kyzivat for their 867 contributions to this specification. 869 Appendix B. RFC5390 requirements 871 Table 1 provides a summary how this specification fulfills the 872 requirements of [RFC5390]. A more detailed view on how each 873 requirements is fulfilled is provided after the table. 875 +-------------+-------------------+ 876 | Requirement | Meets requirement | 877 +-------------+-------------------+ 878 | REQ 1 | Yes | 879 | REQ 2 | Yes | 880 | REQ 3 | Partially | 881 | REQ 4 | Partially | 882 | REQ 5 | Partially | 883 | REQ 6 | Not applicable | 884 | REQ 7 | Yes | 885 | REQ 8 | Partially | 886 | REQ 9 | Yes | 887 | REQ 10 | Yes | 888 | REQ 11 | Yes | 889 | REQ 12 | Yes | 890 | REQ 13 | Yes | 891 | REQ 14 | Yes | 892 | REQ 15 | Yes | 893 | REQ 16 | Yes | 894 | REQ 17 | Partially | 895 | REQ 18 | Yes | 896 | REQ 19 | Yes | 897 | REQ 20 | Yes | 898 | REQ 21 | Yes | 899 | REQ 22 | Yes | 900 | REQ 23 | Yes | 901 +-------------+-------------------+ 903 Summary of meeting requirements in RFC5390 905 Table 1 907 REQ 1: The overload mechanism shall strive to maintain the overall 908 useful throughput (taking into consideration the quality-of- service 909 needs of the using applications) of a SIP server at reasonable 910 levels, even when the incoming load on the network is far in excess 911 of its capacity. The overall throughput under load is the ultimate 912 measure of the value of an overload control mechanism. 914 Meeting REQ 1: Yes, the overload control mechanism allows an 915 overloaded SIP server to maintain a reasonable level of throughput as 916 it enters into congestion mode by requesting the upstream clients to 917 reduce traffic destined downstream. 919 REQ 2: When a single network element fails, goes into overload, or 920 suffers from reduced processing capacity, the mechanism should strive 921 to limit the impact of this on other elements in the network. This 922 helps to prevent a small-scale failure from becoming a widespread 923 outage. 925 Meeting REQ 2: Yes. When a SIP server enters overload mode, it will 926 request the upstream clients to throttle the traffic destined to it. 927 As a consequence of this, the overloaded SIP server will itself 928 generate proportionally less downstream traffic, thereby limiting the 929 impact on other elements in the network. 931 REQ 3: The mechanism should seek to minimize the amount of 932 configuration required in order to work. For example, it is better 933 to avoid needing to configure a server with its SIP message 934 throughput, as these kinds of quantities are hard to determine. 936 Meeting REQ 3: Partially. On the server side, the overload condition 937 is determined monitoring S (c.f., Section 4 of 938 [I-D.ietf-soc-overload-design]) and reporting a load feedback F as a 939 value to the "oc" parameter. On the client side, a throttle T is 940 applied to requests going downstream based on F. This specification 941 does not prescribe any value for S, nor a particular value for F. The 942 "oc-algo" parameter allows for automatic convergence to a particular 943 class of overload control algorithm. There are suggested default 944 values for the "oc-validity" parameter. 946 REQ 4: The mechanism must be capable of dealing with elements that do 947 not support it, so that a network can consist of a mix of elements 948 that do and don't support it. In other words, the mechanism should 949 not work only in environments where all elements support it. It is 950 reasonable to assume that it works better in such environments, of 951 course. Ideally, there should be incremental improvements in overall 952 network throughput as increasing numbers of elements in the network 953 support the mechanism. 955 Meeting REQ 4: Partially. The mechanism is designed to reduce 956 congestion when a pair of communicating entities support it. If a 957 downstream overloaded SIP server does not respond to a request in 958 time, a SIP client conformant to this specification will attempt to 959 reduce traffic destined towards the non-responsive server as outlined 960 in Section 10. 962 REQ 5: The mechanism should not assume that it will only be deployed 963 in environments with completely trusted elements. It should seek to 964 operate as effectively as possible in environments where other 965 elements are malicious; this includes preventing malicious elements 966 from obtaining more than a fair share of service. 968 Meeting REQ 5: Partially. Since overload control information is 969 shared between a pair of communicating entities, a confidential and 970 authenticated channel can be used for this communication. However, 971 if such a channel is not available, then the security ramifications 972 outlined in Section 16 apply. 974 REQ 6: When overload is signaled by means of a specific message, the 975 message must clearly indicate that it is being sent because of 976 overload, as opposed to other, non overload-based failure conditions. 977 This requirement is meant to avoid some of the problems that have 978 arisen from the reuse of the 503 response code for multiple purposes. 979 Of course, overload is also signaled by lack of response to requests. 980 This requirement applies only to explicit overload signals. 982 Meeting REQ 6: Not applicable. Overload control information is 983 signaled as part of the Via header and not in a new header. 985 REQ 7: The mechanism shall provide a way for an element to throttle 986 the amount of traffic it receives from an upstream element. This 987 throttling shall be graded so that it is not all- or-nothing as with 988 the current 503 mechanism. This recognizes the fact that "overload" 989 is not a binary state and that there are degrees of overload. 991 Meeting REQ 7: Yes, please see Section 8 and Section 11. 993 REQ 8: The mechanism shall ensure that, when a request was not 994 processed successfully due to overload (or failure) of a downstream 995 element, the request will not be retried on another element that is 996 also overloaded or whose status is unknown. This requirement derives 997 from REQ 1. 999 Meeting REQ 8: Partially. A SIP client that has overload information 1000 from multiple downstream servers will not retry the request on 1001 another element. However, if a SIP client does not know the overload 1002 status of a downstream server, it may send the request to that 1003 server. 1005 REQ 9: That a request has been rejected from an overloaded element 1006 shall not unduly restrict the ability of that request to be submitted 1007 to and processed by an element that is not overloaded. This 1008 requirement derives from REQ 1. 1010 Meeting REQ 9: Yes, a SIP client conformant to this specification 1011 will send the request to a different element. 1013 REQ 10: The mechanism should support servers that receive requests 1014 from a large number of different upstream elements, where the set of 1015 upstream elements is not enumerable. 1017 Meeting REQ 10: Yes, there are no constraints on the number of 1018 upstream clients. 1020 REQ 11: The mechanism should support servers that receive requests 1021 from a finite set of upstream elements, where the set of upstream 1022 elements is enumerable. 1024 Meeting REQ 11: Yes, there are no constraints on the number of 1025 upstream clients. 1027 REQ 12: The mechanism should work between servers in different 1028 domains. 1030 Meeting REQ 12: Yes, there are no inherent limitations on using 1031 overload control between domains. 1033 REQ 13: The mechanism must not dictate a specific algorithm for 1034 prioritizing the processing of work within a proxy during times of 1035 overload. It must permit a proxy to prioritize requests based on any 1036 local policy, so that certain ones (such as a call for emergency 1037 services or a call with a specific value of the Resource-Priority 1038 header field [RFC4412]) are given preferential treatment, such as not 1039 being dropped, being given additional retransmission, or being 1040 processed ahead of others. 1042 Meeting REQ 13: Yes, please see Section 11. 1044 REQ 14: REQ 14: The mechanism should provide unambiguous directions 1045 to clients on when they should retry a request and when they should 1046 not. This especially applies to TCP connection establishment and SIP 1047 registrations, in order to mitigate against avalanche restart. 1049 Meeting REQ 14: Yes, Section 10 provides normative behavior on when 1050 to retry a request after repeated timeouts and fatal transport errors 1051 resulting from communications with a non-responsive downstream SIP 1052 server. 1054 REQ 15: In cases where a network element fails, is so overloaded that 1055 it cannot process messages, or cannot communicate due to a network 1056 failure or network partition, it will not be able to provide explicit 1057 indications of the nature of the failure or its levels of congestion. 1058 The mechanism must properly function in these cases. 1060 Meeting REQ 15: Yes, Section 10 provides normative behavior on when 1061 to retry a request after repeated timeouts and fatal transport errors 1062 resulting from communications with a non-responsive downstream SIP 1063 server. 1065 REQ 16: The mechanism should attempt to minimize the overhead of the 1066 overload control messaging. 1068 Meeting REQ 16: Yes, overload control messages are sent in the 1069 topmost Via header, which is always processed by the SIP elements. 1071 REQ 17: The overload mechanism must not provide an avenue for 1072 malicious attack, including DoS and DDoS attacks. 1074 Meeting REQ 17: Partially. Since overload control information is 1075 shared between a pair of communicating entities, a confidential and 1076 authenticated channel can be used for this communication. However, 1077 if such a channel is not available, then the security ramifications 1078 outlined in Section 16 apply. 1080 REQ 18: The overload mechanism should be unambiguous about whether a 1081 load indication applies to a specific IP address, host, or URI, so 1082 that an upstream element can determine the load of the entity to 1083 which a request is to be sent. 1085 Meeting REQ 18: Yes, please see discussion in Section 8. 1087 REQ 19: The specification for the overload mechanism should give 1088 guidance on which message types might be desirable to process over 1089 others during times of overload, based on SIP-specific 1090 considerations. For example, it may be more beneficial to process a 1091 SUBSCRIBE refresh with Expires of zero than a SUBSCRIBE refresh with 1092 a non-zero expiration (since the former reduces the overall amount of 1093 load on the element), or to process re-INVITEs over new INVITEs. 1095 Meeting REQ 19: Yes, please see Section 11. 1097 REQ 20: In a mixed environment of elements that do and do not 1098 implement the overload mechanism, no disproportionate benefit shall 1099 accrue to the users or operators of the elements that do not 1100 implement the mechanism. 1102 Meeting REQ 20: Yes, an element that does not implement overload 1103 control does not receive any measure of extra benefit. 1105 REQ 21: The overload mechanism should ensure that the system remains 1106 stable. When the offered load drops from above the overall capacity 1107 of the network to below the overall capacity, the throughput should 1108 stabilize and become equal to the offered load. 1110 Meeting REQ 21: Yes, the overload control mechanism described in this 1111 draft ensures the stability of the system. 1113 REQ 22: It must be possible to disable the reporting of load 1114 information towards upstream targets based on the identity of those 1115 targets. This allows a domain administrator who considers the load 1116 of their elements to be sensitive information, to restrict access to 1117 that information. Of course, in such cases, there is no expectation 1118 that the overload mechanism itself will help prevent overload from 1119 that upstream target. 1121 Meeting REQ 22: Yes, an operator of a SIP server can configure the 1122 SIP server to only report overload control information for requests 1123 received over a confidential channel, for example. However, note 1124 that this requirement is in conflict with REQ 3, as it introduces a 1125 modicum of extra configuration. 1127 REQ 23: It must be possible for the overload mechanism to work in 1128 cases where there is a load balancer in front of a farm of proxies. 1130 Meeting REQ 23: Yes; depending on the type of load balancer, this 1131 requirement is automatically met. More information on a load 1132 balancer in the context of SIP overload is in Section 6 of 1133 [I-D.ietf-soc-overload-design]. 1135 Authors' Addresses 1137 Vijay K. Gurbani (editor) 1138 Bell Laboratories, Alcatel-Lucent 1139 1960 Lucent Lane, Rm 9C-533 1140 Naperville, IL 60563 1141 USA 1143 Email: vkg@bell-labs.com 1145 Volker Hilt 1146 Bell Labs/Alcatel-Lucent 1147 791 Holmdel-Keyport Rd 1148 Holmdel, NJ 07733 1149 USA 1151 Email: volkerh@bell-labs.com 1152 Henning Schulzrinne 1153 Columbia University/Department of Computer Science 1154 450 Computer Science Building 1155 New York, NY 10027 1156 USA 1158 Phone: +1 212 939 7004 1159 Email: hgs@cs.columbia.edu 1160 URI: http://www.cs.columbia.edu