idnits 2.17.1 draft-ietf-soc-overload-rate-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 : ---------------------------------------------------------------------------- ** 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 -- The document date (March 8, 2012) is 4431 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 117, but not defined -- Looks like a reference, but probably isn't: '0' on line 323 == Missing Reference: 'T' is mentioned on line 323, but not defined Summary: 1 error (**), 0 flaws (~~), 3 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: August 8 2012 BT Innovate & Design 6 March 8, 2012 8 Session Initiation Protocol (SIP) Rate Control 9 draft-ietf-soc-overload-rate-control-01.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-07] 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-07]. 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 August 8, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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........4 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.........8 67 4. Example........................................................9 68 5. Syntax........................................................10 69 6. Security Considerations.......................................10 70 7. IANA Considerations...........................................11 71 8. References....................................................11 72 8.1. Normative References.....................................11 73 8.2. Informative References...................................11 74 Appendix A. Acknowledgments......................................12 76 1. Introduction 78 The use of SIP in large scale Next Generation Networks requires that 79 SIP based networks provide adequate control mechanisms for handling 80 traffic growth. In particular, SIP networks must be able to handle 81 traffic overloads gracefully, maintaining transaction throughput by 82 preventing congestion collapse. 84 A promising SIP based overload control solution has been proposed in 85 [draft-ietf-soc-overload-control-07]. That solution provides a 86 communication scheme for overload control algorithms. It also 87 includes a default loss-based overload control algorithm that makes 88 it possible for a set of clients to limit offered load towards an 89 overloaded server. 91 However, such loss control algorithm is sensitive to variations in 92 load so that any increase in load would be directly reflected by the 93 clients in the offered load presented to the overloaded servers. 94 More importantly, a loss-based control cannot guarantee clients to 95 produce a bounded offered load towards an overloaded server and 96 requires frequent updates which may have implications for stability. 98 This document proposes extensions to [draft-ietf-soc-overload- 99 control-07] so as to support a rate-based control that guarantees 100 clients produce a limited upper bound to the Invite rate towards an 101 overloaded server, which is constant between server updates. The 102 penalty for such a benefit is in terms of algorithmic complexity, 103 since the overloaded server must estimate a target offered load and 104 allocate a portion to each conversing client. 106 The proposed rate-based overload control algorithm mitigates 107 congestion in SIP networks while adhering to the overload signaling 108 scheme in [draft-ietf-soc-overload-control-07] and proposing a rate 109 control in addition to the default loss-based control in [draft- 110 ietf-soc-overload-control-07]. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 The normative statements in this specification as they apply to SIP 119 clients and SIP servers assume that both the SIP clients and SIP 120 servers support this specification. If, for instance, only a SIP 121 client supports this specification and not the SIP server, then 122 follows that the normative statements in this specification 123 pertinent to the behavior of a SIP server do not apply to the server 124 that does not support this specification. 126 3. Rate-based algorithm scheme 128 3.1. Overview 130 The server is what the overload control algorithm defined here 131 protects and the client is what throttles traffic towards the 132 server. 134 Following the procedures defined in [draft-ietf-soc-overload- 135 control-07], the server and clients signal one another support for 136 rate-based overload control. 138 Then periodically, the server relies on internal measurements (e.g. 139 CPU utilization, queueing delay...) to evaluate its overload state 140 and estimate a target SIP request rate (as opposed to target percent 141 loss in the case of loss-based control). 143 When in overload, the server uses [draft-ietf-soc-overload-control- 144 07] via header oc parameters of SIP responses to inform the clients 145 of its overload state and of the target SIP request rate. 147 Upon receiving the oc parameters with a target SIP request rate, 148 each client throttles new SIP requests towards the overloaded 149 server. 151 3.2. Summary of via headers parameters for overload control 153 To do: Repeat draft-ietf-soc-overload-control-07 definitions of the 154 oc parameters here. 156 The use of the via header oc parameter(s) inform of the desired 157 rate, but they don't explicitly "inform clients of the overload 158 state". 160 3.3. Client and server rate-control algorithm selection 162 Per [draft-ietf-soc-overload-control-07], new clients indicate 163 supported overload control algorithms to servers by inserting oc and 164 oc-algo in Via header of SIP requests destined to servers. While 165 servers notify clients of selected overload control algorithm 166 through the oc-algo parameter in the Via header of SIP responses to 167 clients. 169 Support of rate-based control MUST be indicated by clients and 170 servers by setting oc-algo to "rate". 172 3.4. Server operation 174 The actual algorithm used by the server to determine its overload 175 state and estimate a target SIP request rate is beyond the scope of 176 this document. 178 However, the server MUST be able to evaluate periodically its 179 overload state and estimate a target SIP request rate beyond which 180 it would become overloaded. The server must allocate a portion of 181 the target SIP request rate to each of its client. 183 The max rate determined by the server for a client applies to the 184 entire stream of SIP requests, even though it may only affect a 185 particular subset of the requests, since as per [draft-ietf-soc- 186 overload-control-07], request prioritization is the client 187 responsibility. But when deriving this rate the server may need to 188 take into account the effect of the client prioritization on the 189 load it receives, e.g. CPU utilization will depend upon the 190 characteristics of the requests. 192 Note that the target SIP request rate is a max rate that may not be 193 attained by the arrival rate at the client, and the server cannot 194 assume that it will. 196 Upon detection of overload, the server MUST follow the 197 specifications in [draft-ietf-soc-overload-control-07] to notify its 198 clients of its overload state and of the allocated target SIP 199 request rate. 201 The server MUST use [draft-ietf-soc-overload-control-07] oc 202 parameter to send a target SIP request rate to each of its client. 204 3.5. Client operation 206 3.5.1. Default algorithm 208 To throttle new SIP requests at the rate specified in the oc value 209 sent by the server to its clients, the client MAY use the proposed 210 default algorithm for rate-based control or any other equivalent 211 algorithm. 213 The default Leaky Bucket algorithm presented here is based on [ITU-T 214 Rec. I.371] Appendix A.2. The algorithm makes it possible for 215 clients to deliver SIP requests at a rate specified in the oc value 216 with tolerance parameter TAU (preferably configurable). 218 Conceptually, the Leaky Bucket algorithm can be viewed as a finite 219 capacity bucket whose real-valued content drains out at a continuous 220 rate of 1 unit of content per time unit and whose content increases 221 by the increment T for each forwarded SIP request. T is computed as 222 the inverse of the rate specified in the oc value, namely T = 1 / 223 adjusted-oc-value. 225 Note that when the oc-value is 0 with a non zero oc-validity, then 226 the client should reject 100% of SIP requests destined to the 227 overload server. However, when both oc-value and oc-validity are 0, 228 the client should immediately stop throttling. 230 If at a new SIP request arrival the content of the bucket is less 231 than or equal to the limit value TAU, then the SIP request is 232 forwarded to the server; otherwise, the SIP request is rejected. 234 Note that the capacity of the bucket (the upper bound of the 235 counter) is (T + TAU). 237 At the arrival time of the k-th new SIP request ta(k) after control 238 has been activated, the content of the bucket is provisionally 239 updated to the value 241 X' = X - ([ta(k) - LCT]) 242 where X is the content of the bucket after arrival of the last 243 forwarded SIP request, and LCT is the time at which the last SIP 244 request was forwarded. 246 If X' is less than or equal to the limit value TAU, then the new SIP 247 request is forwarded and the bucket content X is set to X' (or to 0 248 if X' is negative) plus the increment T, and LCT is set to the 249 current time ta(k). If X' is greater than the limit value tau, then 250 the new SIP request is rejected and the values of X and LCT are 251 unchanged. 253 When the first response from the server has been received indicating 254 control activation (oc-validity>0), LCT is set to the time of 255 activation, and the occupancy of the bucket is initialized to the 256 parameter TAU0 (preferably configurable) which is 0 or larger but 257 less than or equal to TAU. 259 Following [draft-ietf-soc-overload-control-07], the client is 260 responsible for message priority and for maintaining two categories 261 of requests: Requests candidate for reduction, requests not subject 262 to reduction (except under extenuating circumstances when there 263 aren't any messages in the first category that can be reduced). 265 Accordingly, the proposed Leaky bucket implementation is modified to 266 support priority using two thresholds for SIP requests in the set of 267 requests candidate for reduction. With two priorities, the proposed 268 Leaky bucket requires two thresholds TAU1 < TAU2: 269 . All new requests would be admitted when the bucket fill is at 270 or below TAU1, 271 . Only higher priority requests would be admitted when the bucket 272 fill is between TAU1 and TAU2, 273 . All requests would be rejected when the bucket fill is above 274 TAU2. 275 This can be generalized to n priorities using n thresholds for n>2 276 in the obvious way. 278 Note that specification of a value for TAU is beyond the scope of 279 this document. 281 3.5.2. Optional enhancement: avoidance of resonance 283 As the number of client sources of traffic increases and the 284 throughput of the server decreases, the maximum rate admitted by 285 each client needs to decrease, and therefore the value of T becomes 286 larger. Under some circumstances, e.g. if the traffic arises very 287 quickly simultaneously at many sources, the occupancies of each 288 bucket can become synchronized, resulting in the admissions from 289 each source being close in time and batched or very 'peaky' arrivals 290 at the server, which not only gives rise to control instability, but 291 also very poor delays and even lost messages. An appropriate term 292 for this is 'resonance' [Erramilli]. 294 If the network topology is such that this can occur, then a simple 295 way to avoid this is to randomize the bucket occupancy at two 296 appropriate points: At the activation of control, and whenever the 297 bucket empties, as follows. 299 After updating the bucket occupancy to X', generate a value u as 300 follows: 302 if X' > 0, then u=0 304 else if X' <= 0 then uniformly distributed between -1/2 and +1/2 306 Then (only) if the arrival is admitted, increase the bucket by an 307 amount T + uT, which will therefore be just T if the bucket hadn't 308 emptied, or lie between T/2 and 3T/2 if it had. 310 This randomization should also be done when control is activated, 311 i.e. instead of simply initializing the bucket fill to TAU0, 312 initialize it to TAU0 + uT, where u is uniformly distributed as 313 above. Since activation would have been a result of response to a 314 request sent by the client, the second term in this expression can 315 be interpreted as being the bucket increment following that 316 admission. 318 This method has the following characteristics: 320 . If TAU0 is chosen to be equal to TAU and all sources were to 321 activate control at the same time due to an extremely high 322 request rate, then the time until the first request admitted by 323 each client would be uniformly distributed over [0,T]; 325 . The maximum occupancy is TAU + (3/2)T, rather than TAU + T 326 without randomization; 328 . For the special case of 'classic gapping' where TAU=0, then the 329 minimum time between admissions is uniformly distributed over 330 [T/2, 3T/2], and the mean time between admissions is the same, 331 i.e. T+1/R where R is the request arrival rate; 333 . At high load randomization rarely occurs, so there is no loss 334 of precision of the admitted rate, even though the randomized 335 'phasing' of the buckets remains. 337 4. Example 339 Adapting [draft-ietf-soc-overload-control-07] example in section 6.2 340 where SIP client P1 sends requests to a downstream server P2: 342 INVITE sips:user@example.com SIP/2.0 344 Via: SIP/2.0/TLS p1.example.net; 346 branch=z9hG4bK2d4790.1;received=192.0.2.111; 348 oc;oc-algo="loss,rate" 350 ... 352 SIP/2.0 100 Trying 354 Via: SIP/2.0/TLS p1.example.net; 356 branch=z9hG4bK2d4790.1;received=192.0.2.111; 358 oc-algo="rate";oc-validity=0; 360 oc-seq=1282321615.781 362 ... 364 In the messages above, the first line is sent by P1 to P2. This 365 line is a SIP request; because P1 supports overload control, it 366 inserts the "oc" parameter in the topmost Via header that it 367 created. P1 supports two overload control algorithms: loss and rate. 369 The second line --- a SIP response --- shows the topmost Via header 370 amended by P2 according to this specification and sent to P1. 371 Because P2 also supports overload control, it chooses the "rate" 372 based scheme and sends that back to P1 in the "oc-algo" parameter. 373 It uses oc-validity=0 to indicate no overload. 375 At some later time, P2 starts to experience overload. It sends the 376 following SIP message indicating P1 should send SIP requests at a 377 rate no greater than or equal to 150 SIP requests per seconds. 379 SIP/2.0 180 Ringing 381 Via: SIP/2.0/TLS p1.example.net; 383 branch=z9hG4bK2d4790.1;received=192.0.2.111; 385 oc=150;oc-algo="rate";oc-validity=1000; 387 oc-seq=1282321615.782 389 ... 391 5. Syntax 393 This specification extends the existing definition of the Via header 394 field parameters of [RFC3261] as follows: 396 oc = "oc" EQUAL oc-value 398 oc-value = "NaN" / oc-num 400 oc-num = 1*DIGIT 402 6. Security Considerations 404 To do: Use draft-ietf-soc-overload-control-07 section here. 406 7. IANA Considerations 408 None. 410 8. References 412 8.1. Normative References 414 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 415 A., Peterson, J., Sparks, R., Handley, M., and E. 416 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 417 June 2002. 419 8.2. Informative References 421 [draft-ietf-soc-overload-control-07] 422 Gurbani, V., Hilt, V., Schulzrinne, H., "Session 423 Initiation Protocol (SIP) Overload Control", draft-ietf- 424 soc-overload-control-07. 426 [ITU-T Rec. I.371] 427 "Traffic control and congestion control in B-ISDN", ITU-T 428 Recommendation I.371. 430 [Erramilli] 431 A. Erramilli and L. J. Forys, "Traffic Synchronization 432 Effects In Teletraffic Systems", ITC-13, 1991. 434 Appendix A. Acknowledgments 436 Many thanks for the contributions, comments and feedback on this 437 document to: Janet Gunn. 439 This document was prepared using 2-Word-v2.0.template.dot. 441 Authors' Addresses 443 Eric Noel 444 AT&T Labs 445 200s Laurel Avenue 446 Middletown, NJ, 07747 447 USA 449 Philip M Williams 450 BT Innovate & Design 451 UK