idnits 2.17.1 draft-noel-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 (September 2, 2011) is 4620 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 112, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: March 5 2012 BT Innovate & Design 5 Janet Gunn 6 CSC 8 September 2, 2011 10 Session Initiation Protocol (SIP) Rate Control 11 draft-noel-soc-overload-rate-control-01.txt 13 Abstract 15 The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in 16 Next Generation Networks necessitates that SIP networks provide 17 adequate control mechanisms to optimize transaction throughput and 18 prevent congestion collapse during traffic overloads. Already 19 [draft-ietf-soc-overload-control-03] proposes a loss-based solution 20 to remedy known vulnerabilities of the [RFC3261] SIP 503 (service 21 unavailable) overload control mechanism. This document proposes a 22 rate-based control solution to complement the loss-based control 23 defined in [draft-ietf-soc-overload-control-03]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 2, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction...................................................2 60 2. Terminology....................................................3 61 3. Rate-based algorithm scheme....................................3 62 3.1. Overview..................................................3 63 3.2. Client and server rate-control algorithm selection........4 64 3.3. Server operation..........................................4 65 3.4. Client operation (default algorithm)......................5 66 4. Example........................................................6 67 5. Syntax.........................................................7 68 6. Security Considerations........................................7 69 7. IANA Considerations............................................8 70 8. References.....................................................8 71 8.1. Normative References......................................8 72 8.2. Informative References....................................8 73 Appendix A. Acknowledgments.......................................9 75 1. Introduction 77 The use of SIP in large scale Next Generation Networks requires that 78 SIP based networks provide adequate control mechanisms for handling 79 traffic growth. In particular, SIP networks must be able to handle 80 traffic overloads gracefully, optimizing transaction throughput 81 without causing congestion collapse. 83 A promising SIP based overload control solution has been proposed in 84 [draft-ietf-soc-overload-control-03]. That solution includes a 85 default loss-based overload control algorithm that makes it possible 86 for a set of clients to limit offered load towards an overloaded 87 server. 89 However, such loss control algorithm is sensitive to variations in 90 load so that any increase in load would be directly reflected by the 91 clients in the offered load presented to the overloaded servers. In 92 other words, a loss-based control cannot guarantee clients to 93 produce a constant offered load towards an overloaded server. 95 This document proposes a rate-based control that guarantees clients 96 produce a constant offered load towards an overloaded server. The 97 penalty for such a benefit is in terms of algorithmic complexity, 98 since the overloaded server must estimate a target offered load and 99 allocate a portion to each conversing client. 101 The proposed rate-based overload control algorithm mitigates 102 congestion in SIP networks while adhering to the overload signaling 103 scheme in [draft-ietf-soc-overload-control-03] and proposing a rate 104 control in addition to the default loss-based control in [draft- 105 ietf-soc-overload-control-03]. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 The normative statements in this specification as they apply to SIP 114 clients and SIP servers assume that both the SIP clients and SIP 115 servers support this specification. If, for instance, only a SIP 116 client supports this specification and not the SIP server, then 117 follows that the normative statements in this specification 118 pertinent to the behavior of a SIP server do not apply to the server 119 that does not support this specification. 121 3. Rate-based algorithm scheme 123 3.1. Overview 125 The server is what the overload control algorithm defined here 126 protects and the client is what throttles traffic towards the 127 client. 129 Following the procedures defined in [draft-ietf-soc-overload- 130 control-03], the server and clients signal one another support for 131 rate-based overload control. 133 Then periodically, the server relies on internal measurements (e.g. 134 CPU utilization, queueing delay...) to evaluate its overload state 135 and estimate a target SIP request rate (as opposed to target percent 136 loss in the case of loss-based control). 138 When in overload, the server uses [draft-ietf-soc-overload-control- 139 03] via header oc parameters of SIP responses to inform the clients 140 of its overload state and of the target SIP request rate. 142 Upon receiving the oc parameters with a target SIP request rate, 143 each client throttles new SIP requests towards the overloaded 144 server. 146 3.2. Client and server rate-control algorithm selection 148 Per [draft-ietf-soc-overload-control-03], new clients indicate 149 supported overload control algorithms to servers by inserting oc and 150 oc-algo in Via header of SIP requests destined to servers. While 151 servers notify clients of selected overload control algorithm 152 through the oc-algo parameter in the Via header of SIP responses to 153 clients. 155 Support of rate-based control MUST be indicated by clients and 156 servers by setting oc-algo to "rate". 158 3.3. Server operation 160 The actual algorithm used by the server to determine its overload 161 state and estimate a target SIP request rate is beyond the scope of 162 this document. 164 However, the server MUST be able to evaluate periodically its 165 overload state and estimate a target SIP request rate beyond which 166 it would become overloaded. The server must allocate a portion of 167 the target SIP request rate to each of its client. 169 Upon detection of overload, the server MUST follow the 170 specifications in [draft-ietf-soc-overload-control-03] to notify its 171 clients of its overload state and of the allocated target SIP 172 request rate. 174 The server MUST use [draft-ietf-soc-overload-control-03] oc 175 parameter to send a target SIP request rate to each of its client. 177 3.4. Client operation (default algorithm) 179 To throttle new SIP requests at the rate specified in the oc value 180 sent by the server to its clients, the client MAY use the proposed 181 default algorithm for rate-based control or any other equivalent 182 algorithm. 184 The default Leaky Bucket algorithm presented here is based on [ITU-T 185 Rec. I.371] Appendix A.2. The algorithm makes it possible for 186 client to deliver SIP requests at a rate specified in the oc value 187 with tolerance TAU. 189 Conceptually, the Leaky Bucket algorithm can be viewed as a finite 190 capacity bucket whose real-valued content drains out at a continuous 191 rate of 1 unit of content per time unit and whose content increases 192 by the increment T for each forwarded SIP request. T is computed as 193 the inverse of the rate specified in the oc value, namely T = 1 / 194 oc-value. 196 If at a new SIP request arrival the content of the bucket is less 197 than or equal to the limit value TAU, then the SIP request is 198 forwarded to the server; otherwise, the SIP request is rejected. 200 Note that the capacity of the bucket (the upper bound of the 201 counter) is (T + TAU). 203 At the arrival time of the k-th new SIP request ta(k), the content 204 of the bucket is provisionally updated to the value 206 X' = X - ([ta(k) - LCT]) 208 where X is the content of the bucket after arrival of the last 209 forwarded SIP request, and LCT is the time at which the last SIP 210 request was forwarded. 212 If X' is less than or equal to the limit value TAU, then the new SIP 213 request is forwarded and the bucket content X is set to X' (or to 0 214 if X' is negative) plus the increment T, and LCT is set to the 215 current time ta(k). If X' is greater than the limit value tau, then 216 the new SIP request is rejected and the values of X and LCT are 217 unchanged. 219 At the arrival time of the first new SIP request ta(1), the content 220 of the bucket X is set to zero and LCT is set to ta(1). 222 Note that specification of a value for TAU is beyond the scope of 223 this document. 225 4. Example 227 Adapting [draft-ietf-soc-overload-control-03] example in section 6.2 228 where SIP client P1 sends requests to a downstream server P2: 230 INVITE sips:user@example.com SIP/2.0 232 Via: SIP/2.0/TLS p1.example.net; 234 branch=z9hG4bK2d4790.1;received=192.0.2.111; 236 oc;oc-algo="loss,rate" 238 ... 240 SIP/2.0 100 Trying 242 Via: SIP/2.0/TLS p1.example.net; 244 branch=z9hG4bK2d4790.1;received=192.0.2.111; 246 oc=0;oc-algo="rate";oc-validity=500; 248 oc-seq=1282321615.781 250 ... 252 In the messages above, the first line is sent by P1 to P2. This 253 line is a SIP request; because P1 supports overload control, it 254 inserts the "oc" parameter in the topmost Via header that it 255 created. P1 supports two overload control algorithms: loss and rate. 257 The second line --- a SIP response --- shows the topmost Via header 258 amended by P2 according to this specification and sent to P1. 259 Because P2 also supports overload control, it chooses the "rate" 260 based scheme and sends that back to P1 in the "oc-algo" parameter. 261 It also sets the value of "oc" parameter to 0. 263 At some later time, P2 starts to experience overload. It sends the 264 following SIP message indicating P1 should send SIP requests at a 265 rate no greater than or equal to 150 SIP requests per seconds. 267 SIP/2.0 180 Ringing 269 Via: SIP/2.0/TLS p1.example.net; 271 branch=z9hG4bK2d4790.1;received=192.0.2.111; 273 oc=150;oc-algo="rate";oc-validity=1000; 275 oc-seq=1282321615.782 277 ... 279 5. Syntax 281 This specification extends the existing definition of the Via header 282 field parameters of [RFC3261] as follows: 284 oc = "oc" EQUAL oc-value 286 oc-value = "NaN" / oc-num 288 oc-num = 1*DIGIT 290 6. Security Considerations 292 None. 294 7. IANA Considerations 296 None. 298 8. References 300 8.1. Normative References 302 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 303 A., Peterson, J., Sparks, R., Handley, M., and E. 304 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 305 June 2002. 307 8.2. Informative References 309 [draft-ietf-soc-overload-control-03] 310 Gurbani, V., Hilt, V., Schulzrinne, H., "Session 311 Initiation Protocol (SIP) Overload Control", draft-ietf- 312 soc-overload-control-03. 314 [ITU-T Rec. I.371] 315 "Traffic control and congestion control in B-ISDN", ITU-T 316 Recommendation I.371. 318 Appendix A. Acknowledgments 320 Many thanks for the contributions, comments and feedback on this 321 document to: 323 This document was prepared using 2-Word-v2.0.template.dot. 325 Authors' Addresses 327 Eric Noel 328 AT&T Labs 329 200s Laurel Avenue 330 Middletown, NJ, 07747 331 USA 333 Philip M Williams 334 BT Innovate & Design 335 UK 337 Janet Gunn 338 CSC 339 USA