idnits 2.17.1 draft-hilt-sipping-overload-design-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 728. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2008) is 5773 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt (Ed.) 3 Internet-Draft Bell Labs/Alcatel-Lucent 4 Intended status: Informational July 5, 2008 5 Expires: January 6, 2009 7 Design Considerations for Session Initiation Protocol (SIP) Overload 8 Control 9 draft-hilt-sipping-overload-design-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 6, 2009. 36 Abstract 38 Overload occurs in Session Initiation Protocol (SIP) networks when 39 SIP servers have insufficient resources to handle all SIP messages 40 they receive. Even though the SIP protocol provides a limited 41 overload control mechanism through its 503 (Service Unavailable) 42 response code, SIP servers are still vulnerable to overload. This 43 document discusses models and design considerations for a SIP 44 overload control mechanism. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Implicit vs. Explicit Overload Control . . . . . . . . . . . . 4 50 3. System Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 4. Degree of Cooperation . . . . . . . . . . . . . . . . . . . . 6 52 4.1. Hop-by-Hop . . . . . . . . . . . . . . . . . . . . . . . . 7 53 4.2. End-to-End . . . . . . . . . . . . . . . . . . . . . . . . 8 54 4.3. Local Overload Control . . . . . . . . . . . . . . . . . . 9 55 5. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6. Type of Overload Control Feedback . . . . . . . . . . . . . . 11 57 6.1. Rate-based Overload Control . . . . . . . . . . . . . . . 11 58 6.2. Loss-based Overload Control . . . . . . . . . . . . . . . 12 59 6.3. Window-based Overload Control . . . . . . . . . . . . . . 13 60 6.4. On-/Off Overload Control . . . . . . . . . . . . . . . . . 14 61 7. Overload Control Algorithms . . . . . . . . . . . . . . . . . 14 62 8. Self-Limiting . . . . . . . . . . . . . . . . . . . . . . . . 15 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 65 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 15 66 11. Informative References . . . . . . . . . . . . . . . . . . . . 16 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 Intellectual Property and Copyright Statements . . . . . . . . . . 17 70 1. Introduction 72 As with any network element, a Session Initiation Protocol (SIP) 73 [RFC3261] server can suffer from overload when the number of SIP 74 messages it receives exceeds the number of messages it can process. 75 Overload can pose a serious problem for a network of SIP servers. 76 During periods of overload, the throughput of a network of SIP 77 servers can be significantly degraded. In fact, overload may lead to 78 a situation in which the throughput drops down to a small fraction of 79 the original processing capacity. This is often called congestion 80 collapse. 82 Overload is said to occur if a SIP server does not have sufficient 83 resources to process all incoming SIP messages. These resources may 84 include CPU, memory, network bandwidth, input/output, or disk 85 resources. 87 For overload control, we only consider failure cases where SIP 88 servers are unable to process all SIP requests due to resource 89 constraints. There are other cases where a SIP server can 90 successfully process incoming requests but has to reject them due to 91 other failure conditions. For example, a PSTN gateway that runs out 92 of trunk lines but still has plenty of capacity to process SIP 93 messages should reject incoming INVITEs using a 488 (Not Acceptable 94 Here) response [RFC4412]. Similarly, a SIP registrar that has lost 95 connectivity to its registration database but is still capable of 96 processing SIP messages should reject REGISTER requests with a 500 97 (Server Error) response [RFC3261]. Overload control does not apply 98 to these cases and SIP provides appropriate response codes for them. 100 The SIP protocol provides a limited mechanism for overload control 101 through its 503 (Service Unavailable) response code. However, this 102 mechanism cannot prevent overload of a SIP server and it cannot 103 prevent congestion collapse. In fact, the use of the 503 (Service 104 Unavailable) response code may cause traffic to oscillate and to 105 shift between SIP servers and thereby worsen an overload condition. 106 A detailed discussion of the SIP overload problem, the problems with 107 the 503 (Service Unavailable) response code and the requirements for 108 a SIP overload control mechanism can be found in 109 [I-D.rosenberg-sipping-overload-reqs]. 111 This document discusses the models, assumptions and design 112 considerations for a SIP overload control mechanism. The document is 113 a product of the SIP overload control design team. 115 2. Implicit vs. Explicit Overload Control 117 Two fundamental approaches to overload control exist: implicit and 118 explicit overload control. 120 A key contributor to the SIP congestion collapse 121 [I-D.rosenberg-sipping-overload-reqs] is the regenerative behavior of 122 overload in the SIP protocol. Messages that get dropped by a SIP 123 server due to overload are retransmitted and increase the offered 124 load for the already overloaded server. This increase in load 125 worsens the severity of the overload condition and, in turn, causes 126 more messages to be dropped. The goal of an implicit overload 127 control is therefore to change the fundamental mechanisms of the SIP 128 protocol such that regenerative behavior of overload is avoided. In 129 the ideal case, overload behavior of SIP would be fully non- 130 regenerative, which would lead to a stable operation during overload. 131 Even if a fully non-regenerative behavior for SIP is challenging to 132 achieve, changes to the SIP retransmission timer mechanisms can help 133 to reduce the degree of regeneration during overload. More work is 134 needed to understand the impact of SIP retransmission timers on the 135 regenerative overload behavior of SIP. 137 For a SIP INVITE transaction to be successful a minimum of three 138 messages need to be forwarded by a SIP server, often five or more. 139 If a SIP server under overload randomly discards messages without 140 evaluating them, the chances that all messages belonging to a 141 transaction are passed on will decrease as the load increases. Thus, 142 the number of successful transactions will decrease even if the 143 message throughput of a server remains up and the overload behavior 144 is fully non-regenerative. A SIP server might (partially) parse 145 incoming messages to determine if it is a new request or a message 146 belonging to an existing transaction. However, after having spend 147 resources on parsing a SIP message, discarding this message becomes 148 expensive as the resources already spend are lost. The number of 149 successful transactions will therefore decline with an increase in 150 load as less and less resources can be spent on forwarding messages. 151 The slope of the decline depends on the amount of resources spent to 152 evaluate each message. 154 The main idea of a explicit overload control is to use an explicit 155 overload signal to request a reduction in the offered load. This 156 enables a SIP server to adjust the offered load to a level at which 157 it can perform at maximum capacity. 159 Reducing the extent to which SIP server overload is regenerative and 160 an efficient explicit overload control mechanism to control incoming 161 load are two complementary approaches to improve SIP performance 162 under overload. 164 3. System Model 166 The model shown in Figure 1 identifies fundamental components of an 167 explicit SIP overload control mechanism: 169 SIP Processor: The SIP Processor processes SIP messages and is the 170 component that is protected by overload control. 171 Monitor: The Monitor measures the current load of the SIP processor 172 on the receiving entity. It implements the mechanisms needed to 173 determine the current usage of resources relevant for the SIP 174 processor and reports load samples (S) to the Control Function. 175 Control Function: The Control Function implements the overload 176 control algorithm. The control function uses the load samples (S) 177 and determines if overload has occurred and a throttle (T) needs 178 to be set to adjust the load sent to the SIP processor on the 179 receiving entity. The control function on the receiving entity 180 sends load feedback (F) to the sending entity. 181 Actuator: The Actuator implements the algorithms needed to act on 182 the throttles (T) and to adjust the amount of traffic forwarded to 183 the receiving entity. For example, a throttle may instruct the 184 Actuator to reduce the traffic destined to the receiving entity by 185 10%. The algorithms in the Actuator then determine how the 186 traffic reduction is achieved, e.g., by selecting the messages 187 that will be affected and determining whether they are rejected or 188 redirected. 190 The type of feedback (F) conveyed from the receiving to the sending 191 entity depends on the overload control method used (i.e., loss-based, 192 rate-based or window-based overload control; see Section 6), the 193 overload control algorithm (see Section 7) as well as other design 194 parameters. In any case, the feedback (F) enables the sending entity 195 to adjust the amount of traffic forwarded to the receiving entity to 196 a level that is acceptable to the receiving entity without causing 197 overload. 199 Sending Receiving 200 Entity Entity 201 +----------------+ +----------------+ 202 | Server A | | Server B | 203 | +----------+ | | +----------+ | -+ 204 | | Control | | F | | Control | | | 205 | | Function |<-+------+--| Function | | | 206 | +----------+ | | +----------+ | | 207 | T | | | ^ | | Overload 208 | v | | | S | | Control 209 | +----------+ | | +----------+ | | 210 | | Actuator | | | | Monitor | | | 211 | +----------+ | | +----------+ | | 212 | | | | ^ | -+ 213 | v | | | | -+ 214 | +----------+ | | +----------+ | | 215 <-+--| SIP | | | | SIP | | | SIP 216 --+->|Processor |--+------+->|Processor |--+-> | System 217 | +----------+ | | +----------+ | | 218 +----------------+ +----------------+ -+ 220 Figure 1: System Model for Overload Control 222 4. Degree of Cooperation 224 A SIP request is often processed by more than one SIP server on its 225 path to the destination. Thus, a design choice for overload control 226 is where to place the components of overload control along the path 227 of a request and, in particular, where to place the Monitor and 228 Actuator. This design choice determines the degree of cooperation 229 between the SIP servers on the path. Overload control can be 230 implemented hop-by-hop with the Monitor on one server and the 231 Actuator on its direct upstream neighbor. Overload control can be 232 implemented end-to-end with Monitors on all SIP servers along the 233 path of a request and one Actuator on the sender. In this case, 234 Monitors have to cooperate to jointly determine the current resource 235 usage on this path. Finally, overload control can be implemented 236 locally on a SIP server if Monitor and Actuator reside on the same 237 server. In this case, the sending entity and receiving entity are 238 the same SIP server and Actuator and Monitor operate on the same SIP 239 processor (although, the Actuator typically operates on a pre- 240 processing stage in local overload control). These three 241 configurations are shown in Figure 2. 243 +-+ +---------+ 244 v | +------+ | | 245 +-+ +-+ +---+ | | | +---+ 246 v | v | //=>| C | v | v //=>| C | 247 +---+ +---+ // +---+ +---+ +---+ // +---+ 248 | A |===>| B | | A |===>| B | 249 +---+ +---+ \\ +---+ +---+ +---+ \\ +---+ 250 \\=>| D | ^ \\=>| D | 251 +---+ | +---+ 252 ^ | | | 253 +-+ +---------+ 255 (a) local (b) hop-by-hop 257 +------(+)---------+ 258 | ^ | 259 | | +---+ 260 v | //=>| C | 261 +---+ +---+ // +---+ 262 | A |===>| B | 263 +---+ +---+ \\ +---+ 264 ^ | \\=>| D | 265 | | +---+ 266 | v | 267 +------(+)---------+ 269 (c) end-to-end 271 ==> SIP request flow 272 <-- Overload feedback loop 274 Figure 2: Degree of Cooperation between Servers 276 4.1. Hop-by-Hop 278 The idea of hop-by-hop overload control is to instantiate a separate 279 control loop between all neighboring SIP servers that directly 280 exchange traffic. I.e., the Actuator is located on the SIP server 281 that is the direct upstream neighbor of the SIP server that has the 282 corresponding Monitor. Each control loop between two servers is 283 completely independent of the control loop between other servers 284 further up- or downstream. In the example in Figure 2(b), three 285 independent overload control loops are instantiated: A - B, B - C and 286 B - D. Each loop only controls a single hop. Overload feedback 287 received from a downstream neighbor is not forwarded further 288 upstream. Instead, a SIP server acts on this feedback, for example, 289 by re-routing or rejecting traffic if needed. If the upstream 290 neighbor of a server also becomes overloaded, it will report this 291 problem to its upstream neighbors, which again take action based on 292 the reported feedback. Thus, in hop-by-hop overload control, 293 overload is always resolved by the direct upstream neighbors of the 294 overloaded server without the need to involve entities that are 295 located multiple SIP hops away. 297 Hop-by-hop overload control reduces the impact of overload on a SIP 298 network and, in particular, can avoid congestion collapse. In 299 addition, hop-by-hop overload control is simple and scales well to 300 networks with many SIP entities. It does not require a SIP entity to 301 aggregate a large number of overload status values or keep track of 302 the overload status of SIP servers it is not communicating with. 304 4.2. End-to-End 306 End-to-end overload control implements an overload control loop along 307 the entire path of a SIP request, from UAC to UAS. An end-to-end 308 overload control mechanism consolidates overload information from all 309 SIP servers on the way including all proxies and the UAS and uses 310 this information to throttle traffic as far upstream as possible. An 311 end-to-end overload control mechanism has to be able to frequently 312 collect the overload status of all servers on the potential path(s) 313 to a destination and combine this data into meaningful overload 314 feedback. 316 A UA or SIP server only needs to throttle requests if it knows that 317 these requests will eventually be forwarded to an overloaded server. 318 For example, if D is overloaded in Figure 2(c), A should only 319 throttle requests it forwards to B when it knows that they will be 320 forwarded to D. It should not throttle requests that will eventually 321 be forwarded to C, since server C is not overloaded. In many cases, 322 it is difficult for A to determine which requests will be routed to C 323 and D since this depends on the local routing decision made by B. 325 The main problem of end-to-end path overload control is its inherent 326 complexity since UAC or SIP servers need to monitor all potential 327 paths to a destination in order to determine which requests should be 328 throttled and which requests may be sent. In addition, the routing 329 decisions of a SIP server depend on local policy, which can be 330 difficult to infer for an upstream neighbor. Therefore, end-to-end 331 overload control is likely to only work well in simple, well-known 332 topologies (e.g., a server that is known to only have one downstream 333 neighbor) or if a UA/server sends many requests to the exact same 334 destination. 336 4.3. Local Overload Control 338 Local overload control does not require an explicit overload signal 339 between SIP entities as it is implemented locally on a SIP server. 340 It can be by a SIP server to determine when to reject incoming 341 requests instead of forwarding them based on current resource usage. 342 Local overload control can be used in conjunction with an explicit 343 overload control mechanisms and provides an additional layer of 344 protection against overload, for example, when upstream servers do 345 not support explicit overload control. In general, servers should 346 use an explicit mechanisms if available to throttle upstream 347 neighbors before using local overload control as a mechanism of last 348 resort. 350 5. Topologies 352 The following topologies describe four generic SIP server 353 configurations, which each poses specific challenges for an overload 354 control mechanism. 356 In the "load balancer" configuration shown in Figure 3(a) a set of 357 SIP servers (D, E and F) receives traffic from a single source A. A 358 load balancer is a typical example for such a configuration. In this 359 configuration, overload control needs to prevent server A (i.e., the 360 load balancer) from sending too much traffic to any of its downstream 361 neighbors D, E and F. If one of the downstream neighbors becomes 362 overloaded, A can direct traffic to the servers that still have 363 capacity. If one of the servers serves as a backup, it can be 364 activated once one of the primary servers reaches overload. 366 If A can reliably determine that D, E and F are its only downstream 367 neighbors and all of them are in overload, it may choose to report 368 overload upstream on behalf of D, E and F. However, if the set of 369 downstream neighbors is not fixed or only some of them are in 370 overload then A should not use overload control since A can still 371 forward the requests destined to non-overloaded downstream neighbors. 372 These requests would be throttled as well if A would use overload 373 control towards its upstream neighbors. 375 In the "multiple sources" configuration shown in Figure 3(b), a SIP 376 server D receives traffic from multiple upstream sources A, B and C. 377 Each of these sources can contribute a different amount of traffic, 378 which can vary over time. The set of active upstream neighbors of D 379 can change as servers may become inactive and previously inactive 380 servers may start contributing traffic to D. 382 If D becomes overloaded, it needs to generate feedback to reduce the 383 amount of traffic it receives from its upstream neighbors. D needs 384 to decide by how much each upstream neighbor should reduce traffic. 385 This decision can require the consideration of the amount of traffic 386 sent by each upstream neighbor and it may need to be re-adjusted as 387 the traffic contributed by each upstream neighbor varies over time. 389 In many configurations, SIP servers form a "mesh" as shown in 390 Figure 3(c). Here, multiple upstream servers A, B and C forward 391 traffic to multiple alternative servers D and E. This configuration 392 is a combination of the "load balancer" and "multiple sources" 393 scenario. 395 +---+ +---+ 396 /->| D | | A |-\ 397 / +---+ +---+ \ 398 / \ +---+ 399 +---+-/ +---+ +---+ \->| | 400 | A |------>| E | | B |------>| D | 401 +---+-\ +---+ +---+ /->| | 402 \ / +---+ 403 \ +---+ +---+ / 404 \->| F | | C |-/ 405 +---+ +---+ 407 (a) load balancer (b) multiple sources 409 +---+ 410 | A |---\ a--\ 411 +---+-\ \---->+---+ \ 412 \/----->| D | b--\ \--->+---+ 413 +---+--/\ /-->+---+ \---->| | 414 | B | \/ c-------->| D | 415 +---+---\/\--->+---+ | | 416 /\---->| E | ... /--->+---+ 417 +---+--/ /-->+---+ / 418 | C |-----/ z--/ 419 +---+ 421 (c) mesh (d) edge proxy 423 Figure 3: Topologies 425 Overload control that is based on reducing the number of messages a 426 sender is allowed to send is not suited for servers that receive 427 requests from a very large population of senders, each of which only 428 infrequently sends a request. This scenario is shown in Figure 3(d). 430 An edge proxy that is connected to many UAs is a typical example for 431 such a configuration. 433 Since each UA typically only contributes a few requests, which are 434 often related to the same call, it can't decrease its message rate to 435 resolve the overload. In such a configuration, a SIP server can 436 resort to local overload control by rejecting a percentage of the 437 requests it receives with 503 (Service Unavailable) responses. Since 438 there are many upstream neighbors that contribute to the overall 439 load, sending 503 (Service Unavailable) to a fraction of them can 440 gradually reduce load without entirely stopping all incoming traffic. 441 Using 503 (Service Unavailable) towards individual sources can, 442 however, not prevent overload if a large number of users places calls 443 at the same time. 445 Note: The requirements of the "edge proxy" topology are different 446 than the ones of the other topologies, which may require a 447 different method for overload control. 449 6. Type of Overload Control Feedback 451 The type of feedback generated by a receiver to limit the amount of 452 traffic it receives is an important aspect of the design. We discuss 453 the following three different types of overload control feedback: 454 rate-based, loss-based and window-based overload control. 456 6.1. Rate-based Overload Control 458 The key idea of rate-based overload control is to limit the request 459 rate at which an upstream element is allowed to forward to the 460 downstream neighbor. If overload occurs, a SIP server instructs each 461 upstream neighbor to send at most X requests per second. Each 462 upstream neighbor can be assigned a different rate cap. 464 The rate cap ensures that the number of requests received by a SIP 465 server never increases beyond the sum of all rate caps granted to 466 upstream neighbors. It can protect a SIP server against overload 467 even during load spikes if no new upstream neighbors start sending 468 traffic. New upstream neighbors need to be factored into the rate 469 caps assigned as soon as they appear. The current overall rate cap 470 used by a SIP server is determined by an overload control algorithm, 471 e.g., based on system load. 473 An algorithm for the sending entity to implement a rate cap of a 474 given number of requests per second X is request gapping. After 475 transmitting a request to a downstream neighbor, a server waits for 476 1/X seconds before it transmits the next request to the same 477 neighbor. Requests that arrive during the waiting period are not 478 forwarded and are either redirected, rejected or buffered. 480 A drawback of this mechanism is that it requires a SIP server to 481 assign a certain rate cap to each of its upstream neighbors during an 482 overload condition based on its overall capacity. Effectively, a 483 server assigns a share of its capacity to each upstream neighbor 484 during overload. The server needs to ensure that the sum of all rate 485 caps assigned to upstream neighbors is not (significantly) higher 486 than its actual processing capacity. This requires a SIP server to 487 keep track of the set of upstream neighbors and to adjust the rate 488 cap if a new upstream neighbor appears or an existing neighbor stops 489 transmitting. If the cap assigned to upstream neighbors is too high, 490 the server may still experience overload. However, if the cap is too 491 low, the upstream neighbors will reject requests even though they 492 could be processed by the server. 494 A SIP server can evaluate the amount of load it receives from each 495 upstream neighbor and assign a rate cap that is suitable for this 496 neighbor without limiting it too much. This way, the SIP server can 497 allocate resources that are not used by one upstream neighbor because 498 it is sending less requests than allowed by the rate cap to another 499 server. 501 An alternative technique to allocate a rate cap to each upstream 502 neighbor is using a fixed proportion of some control variable, X, 503 where X is initially equal to the capacity of the SIP server. The 504 server then increases or decreases X until the workload arrival rate 505 matches the actual server capacity. Usually, this will mean that the 506 sum of the rate caps sent out by the server (=X) exceeds its actual 507 capacity, but enables upstream neighbors who are not generating more 508 than their fair share of the work to be effectively unrestricted. An 509 advantage of this approach is that the server only has to measure the 510 aggregate arrival rate, and that the calculation of the individual 511 rate caps is fairly trivial. 513 6.2. Loss-based Overload Control 515 A loss percentage enables a SIP server to ask an upstream neighbor to 516 reduce the number of requests it would normally forward to this 517 server by a percentage X. For example, a SIP server can ask an 518 upstream neighbor to reduce the number of requests this neighbor 519 would normally send by 10%. The upstream neighbor then redirects or 520 rejects X percent of the traffic that is destined for this server. 522 An algorithm for the sending entity to implement a loss percentage is 523 to draw a random number between 1 and 100 for each request to be 524 forwarded. The request is not forwarded to the server if the random 525 number is less than or equal to X. 527 An advantage of loss-based overload control is that, the receiving 528 entity does not need to track the set of upstream neighbors or the 529 request rate it receives from each upstream neighbor. It is 530 sufficient to monitor the overall system utilization. To reduce 531 load, a server can ask its upstream neighbors to lower the traffic 532 forwarded by a certain percentage. The server calculates this 533 percentage by combining the loss percentage that is currently in use 534 (i.e., the loss percentage the upstream neighbors are currently using 535 when forwarding traffic), the current system utilization and the 536 desired system utilization. For example, if the server load 537 approaches 90% and the current loss percentage is set to a 50% 538 traffic reduction, then the server can decide to increase the loss 539 percentage to 55% in order to get to a system utilization of 80%. 540 Similarly, the server can lower the loss percentage if permitted by 541 the system utilization. 543 The main drawback of percentage throttling is that the throttle 544 percentage needs to be adjusted to the current number of requests 545 received by the server. This is in particular important if the 546 number of requests received fluctuates quickly. For example, if a 547 SIP server sets a throttle value of 10% at time t1 and the number of 548 requests increases by 20% between time t1 and t2 (t1