idnits 2.17.1 draft-ietf-soc-overload-rate-control-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 103 has weird spacing: '...ards an overl...' -- The document date (April 8, 2013) is 4035 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: 'RFC2119' is mentioned on line 118, but not defined -- Looks like a reference, but probably isn't: '0' on line 425 == Missing Reference: 'T' is mentioned on line 425, but not defined == Unused Reference: 'RFC5390' is defined on line 562, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5390 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SOC Working Group Eric Noel 2 Internet-Draft AT&T Labs 3 Intended status: Standards Track Philip M Williams 4 Expires: October 8, 2013 BT Innovate & Design 6 April 8, 2013 8 Session Initiation Protocol (SIP) Rate Control 9 draft-ietf-soc-overload-rate-control-04.txt 11 Abstract 13 The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in 14 Next Generation Networks necessitates that SIP networks provide 15 adequate control mechanisms to maintain transaction throughput by 16 preventing congestion collapse during traffic overloads. Already 17 [draft-ietf-soc-overload-control-12] proposes a loss-based solution 18 to remedy known vulnerabilities of the [RFC3261] SIP 503 (service 19 unavailable) overload control mechanism. This document proposes a 20 rate-based control solution to complement the loss-based control 21 defined in [draft-ietf-soc-overload-control-12]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 8, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Terminology....................................................3 59 3. Rate-based algorithm scheme....................................4 60 3.1. Overview..................................................4 61 3.2. Summary of via headers parameters for overload control....4 62 3.3. Client and server rate-control algorithm selection........5 63 3.4. Server operation..........................................5 64 3.5. Client operation..........................................6 65 3.5.1. Default algorithm....................................6 66 3.5.2. Optional enhancement: avoidance of resonance........10 67 4. Example.......................................................11 68 5. Syntax........................................................12 69 6. Security Considerations.......................................13 70 7. IANA Considerations...........................................14 71 8. References....................................................14 72 8.1. Normative References.....................................14 73 8.2. Informative References...................................14 74 Appendix A. Contributors.........................................15 75 Appendix B. Acknowledgments......................................15 77 1. Introduction 79 The use of SIP in large scale Next Generation Networks requires that 80 SIP based networks provide adequate control mechanisms for handling 81 traffic growth. In particular, SIP networks must be able to handle 82 traffic overloads gracefully, maintaining transaction throughput by 83 preventing congestion collapse. 85 A promising SIP based overload control solution has been proposed in 86 [draft-ietf-soc-overload-control-12]. That solution provides a 87 communication scheme for overload control algorithms. It also 88 includes a default loss-based overload control algorithm that makes 89 it possible for a set of clients to limit offered load towards an 90 overloaded server. 92 However, such loss control algorithm is sensitive to variations in 93 load so that any increase in load would be directly reflected by the 94 clients in the offered load presented to the overloaded servers. 95 More importantly, a loss-based control cannot guarantee clients to 96 produce a bounded offered load from the clients towards an 97 overloaded server and requires frequent updates which may have 98 implications for stability. 100 This document proposes extensions to [draft-ietf-soc-overload- 101 control-12] to support a rate-based control that guarantees an upper 102 bound on the rate, constant between server updates, of requests sent 103 by clients towards an overloaded server.. The tradeoff is in terms 104 of algorithmic complexity, since the overloaded server must estimate 105 a separate target for each client, rather than an overall loss 106 percentage, equally applicable to all clients. 107 The proposed rate-based overload control algorithm mitigates 108 congestion in SIP networks while adhering to the overload signaling 109 scheme in [draft-ietf-soc-overload-control-12] and presenting a rate 110 based control as an optional alternative to the default loss-based 111 control in [draft-ietf-soc-overload-control-12]. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 The normative statements in this specification as they apply to SIP 120 clients and SIP servers assume that both the SIP clients and SIP 121 servers support this specification. If, for instance, only a SIP 122 client supports this specification and not the SIP server, then 123 follows that the normative statements in this specification 124 pertinent to the behavior of a SIP server do not apply to the server 125 that does not support this specification. 127 3. Rate-based algorithm scheme 129 3.1. Overview 131 The server is what the overload control algorithm defined here 132 protects and the client is what throttles traffic towards the 133 server. 135 Following the procedures defined in [draft-ietf-soc-overload- 136 control-12], the server and clients signal one another support for 137 rate-based overload control. 139 Then periodically, the server relies on internal measurements (e.g. 140 CPU utilization, queueing delay...) to evaluate its overload state 141 and estimate a target SIP request rate (as opposed to target percent 142 loss in the case of loss-based control). 144 When in overload, the server uses [draft-ietf-soc-overload-control- 145 12] via header oc parameters of SIP responses to inform the clients 146 of its overload state and of the target SIP request rate. 148 Upon receiving the oc parameters with a target SIP request rate, 149 each client throttles new SIP requests towards the overloaded 150 server. 152 3.2. Summary of via headers parameters for overload control 154 oc: Used by SIP clients to indicate draft-ietf-soc-overload-control- 155 12 support and by SIP servers to indicate the load reduction amount. 157 oc parameters defined in draft-ietf-soc-overload-control-12 are 158 summarized below: 160 oc-algo: Used by SIP clients to advertise supported overload control 161 algorithms and by SIP servers to notify clients of algorithm in 162 effect. Support values: loss (default), rate (optional). 164 oc-validity: Used by SIP servers to indicate an interval of time 165 (msec) that the load reduction should be in effect. A value of 0 is 166 reserved for server to stop overload control. A non-zero value is 167 required in conjunction with an "oc" parameter. 169 oc-seq: A sequence number associated with the "oc" parameter. 171 The use of the via header oc parameter(s) inform of the desired 172 rate, but they don't explicitly ''inform clients of the overload 173 state''. 175 3.3. Client and server rate-control algorithm selection 177 Per [draft-ietf-soc-overload-control-12], new clients indicate 178 supported overload control algorithms to servers by inserting oc and 179 oc-algo, with the names of the supported algorithms, in Via header 180 of SIP requests destined to servers. The inclusion by the client of 181 the string ''rate'' indicates that the client supports a rate based 182 algorithm. Conversely, servers notify clients of selected overload 183 control algorithm through the oc-algo parameter in the Via header of 184 SIP responses to clients. The inclusion by the server of the string 185 ''rate'' indicates that the rate based algorithm has been selected by 186 the server. 188 Support of rate-based control MUST be indicated by clients setting 189 oc-algo to "rate". Selection of rate-based control MUST be indicated 190 by servers by setting oc-algo to ''rate''. 192 3.4. Server operation 194 The actual algorithm used by the server to determine its overload 195 state and estimate a target SIP request rate is beyond the scope of 196 this document. 198 However, the server MUST be able to evaluate periodically its 199 overload state and estimate a target SIP request rate beyond which 200 it would become overloaded. The server must allocate a portion of 201 the target SIP request rate to each of its client. The server may 202 set the same rate for every client, or may set different rates for 203 different clients. 205 The max rate determined by the server for a client applies to the 206 entire stream of SIP requests, even though throttling may only 207 affect a particular subset of the requests, since as per [draft- 208 ietf-soc-overload-control-12] and REQ 13 of RFC 5390, request 209 prioritization is the client responsibility. But when deriving this 210 rate the server may need to take into account characteristics of the 211 requests, and the effect of the client prioritization on the load it 212 receives, e.g. CPU utilization will depend upon the characteristics 213 of the requests which would presumably allow the server to take in 214 account prioritization. 215 Note that the target SIP request rate is a max rate that may not be 216 attained by the arrival rate at the client, and the server cannot 217 assume that it will. 219 Upon detection of overload, the server MUST follow the 220 specifications in [draft-ietf-soc-overload-control-12] to notify its 221 clients of the allocated target SIP request rate. 223 The server MUST use [draft-ietf-soc-overload-control-12] oc 224 parameter to send a target SIP request rate to each of its clients. 226 3.5. Client operation 228 3.5.1. Default algorithm 230 To throttle new SIP requests at the rate specified in the oc value 231 sent by the server to its clients, the client MAY use the proposed 232 default algorithm for rate-based control or any other equivalent 233 algorithm. 235 The default Leaky Bucket algorithm presented here is based on [ITU-T 236 Rec. I.371] Appendix A.2. The algorithm makes it possible for 237 clients to deliver SIP requests at a rate specified in the oc value 238 with tolerance parameter TAU (preferably configurable). 240 Conceptually, the Leaky Bucket algorithm can be viewed as a finite 241 capacity bucket whose real-valued content drains out at a continuous 242 rate of 1 unit of content per time unit and whose content increases 243 by the increment T for each forwarded SIP request. T is computed as 244 the inverse of the rate specified in the oc value, namely T = 1 / 245 oc-value. 247 Note that when the oc-value is 0 with a non-zero oc-validity, then 248 the client should reject 100% of SIP requests destined to the 249 overload server. However, when both oc-value and oc-validity are 0, 250 the client should immediately stop throttling. 252 If at a new SIP request arrival the content of the bucket is less 253 than or equal to the limit value TAU, then the SIP request is 254 forwarded to the server; otherwise, the SIP request is rejected. 256 Note that the capacity of the bucket (the upper bound of the 257 counter) is (T + TAU). 259 The tolerance parameter TAU determines how close the long-term 260 admitted rate is to an ideal control that would admit all SIP 261 requests for arrival rates less than 1/T and then admit SIP requests 262 precisely rate at 1/T for arrival rates above 1/T. In particular at 263 mean arrival rates close to 1/T, it determines the tolerance to 264 deviation of the inter-arrival time from T (the larger TAU the more 265 tolerance to deviations from the inter-departure interval T). 266 This deviation from the inter-departure interval influences the 267 admitted rate burstyness, or the number consecutive SIP requests 268 forwarded to the SIP server (burst size proportional to TAU over the 269 difference between 1/T and the arrival rate). 271 SIP servers with a very large number of clients, each with a 272 relatively small arrival rate, will generally benefit from a smaller 273 value for TAU in order to limit queuing (and hence response times) 274 at the server when subjected to a sudden surge of traffic from all 275 clients. Conversely, a SIP server with a relatively small number of 276 clients, each with proportionally larger arrival rate, will benefit 277 from a larger value of TAU. 279 At the arrival time of the k-th new SIP request ta(k) after control 280 has been activated, the content of the bucket is provisionally 281 updated to the value 283 X' = X - ([ta(k) - LCT]) 285 where X is the content of the bucket after arrival of the last 286 forwarded SIP request, and LCT is the time at which the last SIP 287 request was forwarded. 289 If X' is less than or equal to the limit value TAU, then the new SIP 290 request is forwarded and the bucket content X is set to X' (or to 0 291 if X' is negative) plus the increment T, and LCT is set to the 292 current time ta(k). If X' is greater than the limit value TAU, then 293 the new SIP request is rejected and the values of X and LCT are 294 unchanged. 296 When the first response from the server has been received indicating 297 control activation (oc-validity>0), LCT is set to the time of 298 activation, and the occupancy of the bucket is initialized to the 299 parameter TAU0 (preferably configurable) which is 0 or larger but 300 less than or equal to TAU. 302 Following [draft-ietf-soc-overload-control-12], the client is 303 responsible for message priority and for maintaining two categories 304 of requests: Requests candidate for reduction, requests not subject 305 to reduction (except under extenuating circumstances when there 306 aren't any messages in the first category that can be reduced). 308 Accordingly, the proposed Leaky bucket implementation is modified to 309 support priority using two thresholds for SIP requests in the set of 310 requests candidate for reduction. With two priorities, the proposed 311 Leaky bucket requires two thresholds TAU1 < TAU2: 312 . All new requests would be admitted when the bucket fill is at 313 or below TAU1, 314 . Only higher priority requests would be admitted when the bucket 315 fill is between TAU1 and TAU2, 316 . All requests would be rejected when the bucket fill is above 317 TAU2. 318 This can be generalized to n priorities using n thresholds for n>2 319 in the obvious way. 321 With a priority scheme that relies on two tolerance parameters (TAU2 322 influences the priority traffic, TAU1 influences the non-priority 323 traffic), always set TAU1 <= TAU2 (TAU is replaced by TAU1 and 324 TAU2). Setting both tolerance parameters to the same value is 325 equivalent to having no priority. TAU1 influences the admitted rate 326 the same way as TAU does when no priority are set. And the larger 327 the difference between TAU1 and TAU2, the closer to the control is 328 to strict priority. 330 TAU (or TAU1 and TAU2) can assume any positive real number value and 331 is not necessarily bounded by T. 333 Note that specification of a value for TAU is beyond the scope of 334 this document. 336 A reference algorithm is shown below. 338 No priority case: 340 // T: emission interval, set to 1 / TargetRate 341 // TAU: tolerance parameter 342 // ta: arrival time of last arrival 343 // LCT: arrival time of last conforming SIP request (initialized to 344 // the first arrival time) 345 // X: current value of leaky bucket counter (initialized to 0) 347 // After first arrival, calculate auxiliary variable Xp 348 Xp = X - (ta - LCT); 350 if (Xp <= TAU) { 351 // Accept SIP request 352 // Update X and LCT 353 X = max(0,Xp) + T; 354 LCT = ta; 355 } else { 356 // Reject SIP request 357 // Do not update X and LCT 358 } 360 Priority case: 362 // T: emission interval, set to 1 / TargetRate 363 // TAU1: tolerance parameter of no priority SIP requests 364 // TAU2: tolerance parameter of priority SIP requests 365 // ta: arrival time of last arrival 366 // LCT: arrival time of last conforming SIP request (initialized to 367 // the first arrival time) 368 // X: current value of leaky bucket counter (initialized to 0) 370 // After first arrival, calculate auxiliary variable Xp 371 Xp = X - (ta - LCT); 372 if (AnyRequestReceived && Xp <= TAU1 || PriorityRequestReceived && 373 Xp <= TAU2 && Xp > TAU1) { 374 // Accept SIP request 375 // Update X and LCT 376 X = max(0,Xp) + T; 377 LCT = ta; 378 } else { 379 // Reject SIP request 380 // Do not update X and LCT 381 } 383 3.5.2. Optional enhancement: avoidance of resonance 385 As the number of client sources of traffic increases and the 386 throughput of the server decreases, the maximum rate admitted by 387 each client needs to decrease, and therefore the value of T becomes 388 larger. Under some circumstances, e.g. if the traffic arises very 389 quickly simultaneously at many sources, the occupancies of each 390 bucket can become synchronized, resulting in the admissions from 391 each source being close in time and batched or very 'peaky' arrivals 392 at the server, which not only gives rise to control instability, but 393 also very poor delays and even lost messages. An appropriate term 394 for this is 'resonance' [Erramilli]. 396 If the network topology is such that this can occur, then a simple 397 way to avoid this is to randomize the bucket occupancy at two 398 appropriate points: At the activation of control, and whenever the 399 bucket empties, as follows. 401 After updating the bucket occupancy to X', generate a value u as 402 follows: 404 if X' > 0, then u=0 406 else if X' <= 0 then uniformly distributed between -1/2 and +1/2 408 Then (only) if the arrival is admitted, increase the bucket by an 409 amount T + uT, which will therefore be just T if the bucket hadn't 410 emptied, or lie between T/2 and 3T/2 if it had. 412 This randomization should also be done when control is activated, 413 i.e. instead of simply initializing the bucket fill to TAU0, 414 initialize it to TAU0 + uT, where u is uniformly distributed as 415 above. Since activation would have been a result of response to a 416 request sent by the client, the second term in this expression can 417 be interpreted as being the bucket increment following that 418 admission. 420 This method has the following characteristics: 422 . If TAU0 is chosen to be equal to TAU and all sources were to 423 activate control at the same time due to an extremely high 424 request rate, then the time until the first request admitted by 425 each client would be uniformly distributed over [0,T]; 427 . The maximum occupancy is TAU + (3/2)T, rather than TAU + T 428 without randomization; 430 . For the special case of 'classic gapping' where TAU=0, then the 431 minimum time between admissions is uniformly distributed over 432 [T/2, 3T/2], and the mean time between admissions is the same, 433 i.e. T+1/R where R is the request arrival rate; 435 . At high load randomization rarely occurs, so there is no loss 436 of precision of the admitted rate, even though the randomized 437 'phasing' of the buckets remains. 439 4. Example 441 Adapting [draft-ietf-soc-overload-control-12] example in section 6.2 442 where SIP client P1 sends requests to a downstream server P2: 444 INVITE sips:user@example.com SIP/2.0 446 Via: SIP/2.0/TLS p1.example.net; 448 branch=z9hG4bK2d4790.1;received=192.0.2.111; 450 oc;oc-algo="loss,rate" 452 ... 454 SIP/2.0 100 Trying 456 Via: SIP/2.0/TLS p1.example.net; 458 branch=z9hG4bK2d4790.1;received=192.0.2.111; 460 oc-algo="rate";oc-validity=0; 461 oc-seq=1282321615.781 463 ... 465 In the messages above, the first line is sent by P1 to P2. This 466 line is a SIP request; because P1 supports overload control, it 467 inserts the "oc" parameter in the topmost Via header that it 468 created. P1 supports two overload control algorithms: loss and rate. 470 The second line --- a SIP response --- shows the top most Via header 471 amended by P2 according to this specification and sent to P1. 472 Because P2 also supports overload control, it chooses the ''rate'' 473 based scheme and sends that back to P1 in the ''oc-algo'' parameter. 474 It uses oc-validity=0 to indicate no overload. 476 At some later time, P2 starts to experience overload. It sends the 477 following SIP message indicating P1 should send SIP requests at a 478 rate no greater than or equal to 150 SIP requests per seconds. 480 SIP/2.0 180 Ringing 482 Via: SIP/2.0/TLS p1.example.net; 484 branch=z9hG4bK2d4790.1;received=192.0.2.111; 486 oc=150;oc-algo="rate";oc-validity=1000; 488 oc-seq=1282321615.782 490 ... 492 5. Syntax 494 This specification extends the existing definition of the Via header 495 field parameters of [RFC3261] as follows: 497 oc = "oc" EQUAL oc-value 499 oc-value = "NaN" / oc-num 501 oc-num = 1*DIGIT 503 6. Security Considerations 505 For completeness, draft-ietf-soc-overload-control-12 Security 506 Considerations section is repeated here. 508 Overload control mechanisms can be used by an attacker to conduct a 509 denial-of-service attack on a SIP entity if the attacker can pretend 510 that the SIP entity is overloaded. When such a forged overload 511 indication is received by an upstream SIP client, it will stop 512 sending traffic to the victim. Thus, the victim is subject to a 513 denial-of-service attack. 515 An attacker can create forged overload feedback by inserting itself 516 into the communication between the victim and its upstream 517 neighbors. The attacker would need to add overload feedback 518 indicating a high load to the responses passed from the victim to 519 its upstream neighbor. Proxies can prevent this attack by 520 communicating via TLS. Since overload feedback has no meaning beyond 521 the next hop, there is no need to secure the communication over 522 multiple hops. 524 Another way to conduct an attack is to send a message containing a 525 high overload feedback value through a proxy that does not support 526 this extension. If this feedback is added to the second Via headers 527 (or all Via headers), it will reach the next upstream proxy. If the 528 attacker can make the recipient believe that the overload status was 529 created by its direct downstream neighbor (and not by the attacker 530 further downstream) the recipient stops sending traffic to the 531 victim. A precondition for this attack is that the victim proxy does 532 not support this extension since it would not pass through overload 533 control feedback otherwise. 535 A malicious SIP entity could gain an advantage by pretending to 536 support this specification but never reducing the amount of traffic 537 it forwards to the downstream neighbor. If its downstream neighbor 538 receives traffic from multiple sources which correctly implement 539 overload control, the malicious SIP entity would benefit since all 540 other sources to its downstream neighbor would reduce load. 542 The solution to this problem depends on the overload control method. 543 For rate-based and window-based overload control, it is very easy 544 for a downstream entity to monitor if the upstream neighbor 545 throttles traffic forwarded as directed. For percentage throttling 546 this is not always obvious since the load forwarded depends on the 547 load received by the upstream neighbor. 549 7. IANA Considerations 551 None. 553 8. References 555 8.1. Normative References 557 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 558 A., Peterson, J., Sparks, R., Handley, M., and E. 559 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 560 June 2002. 562 [RFC5390] Rosenberg, J., "Requirements for Management of Overload in 563 the Session Initiation Protocol", RFC 5390, December 2008. 565 8.2. Informative References 567 [draft-ietf-soc-overload-control-12] 568 Gurbani, V., Hilt, V., Schulzrinne, H., "Session 569 Initiation Protocol (SIP) Overload Control", draft-ietf- 570 soc-overload-control-12. 572 [ITU-T Rec. I.371] 573 "Traffic control and congestion control in B-ISDN", ITU-T 574 Recommendation I.371. 576 [Erramilli] 577 A. Erramilli and L. J. Forys, "Traffic Synchronization 578 Effects In Teletraffic Systems", ITC-13, 1991. 580 Appendix A. Contributors 582 Significant contributions to this document were made by Janet Gunn. 584 Appendix B. Acknowledgments 586 Many thanks for comments and feedback on this document to: Volker 587 Hilt. 589 This document was prepared using 2-Word-v2.0.template.dot. 591 Authors' Addresses 593 Eric Noel 594 AT&T Labs 595 200s Laurel Avenue 596 Middletown, NJ, 07747 597 USA 599 Philip M Williams 600 BT Innovate & Design 601 UK