idnits 2.17.1 draft-williams-soc-nxrate-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 342 has weird spacing: '... values requ...' == Line 363 has weird spacing: '...Request exe...' -- The document date (October 3, 2019) is 1638 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft P M Williams, Ed. 2 SOC Working Group (concluded) NICC Standards & BT 3 Intended status: Standards Track 4 Expires: April 3, 2020 October 3, 2019 6 Session Initiation Protocol (SIP) Non-eXempt Rate Control 7 draft-williams-soc-nxrate-control-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on April 3, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. 44 Abstract 46 A SIP overload control signalling protocol framework has previously 47 been published, with the flexibility to allow different SIP request 48 rate limiting algorithms to be selected. This document proposes a 49 similar algorithm of maximum rate type with two advantages over 50 existing proposals. Firstly, it exempts certain classes of SIP 51 requests that are fundamental to correct operation of the SIP 52 protocol which, if rejected by control, would worsen rather than 53 improve SIP performance. Secondly, it allows target servers to 54 control SIP traffic from sources not compliant with this document so 55 that it can be deployed in heterogeneous network environments. 57 Table of Contents 59 1. Introduction ................................................ 3 60 2. Terminology ................................................. 4 61 3. Overview .................................................... 5 62 4. Request priorities, including exemption from restriction .... 5 63 4.1. Exempt request methods ................................. 6 64 4.2. Non-exempt request priorities .......................... 7 65 4.2.1. Factors determining priorities of within dialogue 66 request methods ................................... 7 67 4.2.2. Illustrative numerical values of priority ......... 8 68 5. "nxrate" token for oc-algo parameter value ................. 10 69 5.1. Control algorithm selection ........................... 11 70 6. Rate control algorithm ..................................... 11 71 6.1. Target server rate control for non-compliant or non- 72 conforming sources (clients) .......................... 12 73 6.1.1. Enhanced rate control algorithm for target server 13 74 6.1.2. Rate controller allocation and treatment of requests 75 for a target server .............................. 14 76 6.1.3. Summary of performance characteristics of the 77 solution ......................................... 14 78 6.1.4. Steady-state outcome rates of the enhanced target 79 rate control ..................................... 15 80 7. Server operation ........................................... 16 81 7.1. Control rate (oc value) allocation over sources ....... 16 82 7.2. Overload control objectives ........................... 17 83 8. Target server failover configuration ....................... 18 84 8.1. oc-validity values .................................... 18 85 8.2. oc-seq values ......................................... 21 86 8.2.1. Control state is shared .......................... 21 87 8.2.2. Control state is not shared ...................... 21 88 8.3. Relationship of source restrictor to a target and its 89 standby ............................................... 22 90 9. Example - including failover ............................... 23 91 10. Syntax .................................................... 25 92 11. Backwards compatibility ................................... 25 93 12. Security considerations ................................... 26 94 13. IANA considerations........................................ 26 95 14. References ................................................ 26 96 14.1. Normative References ................................. 26 97 14.2. Informative References ............................... 27 98 15. Acknowledgments ........................................... 27 99 Appendix A. RFC5390 requirements .............................. 28 101 1. Introduction 103 A SIP signalling protocol for control of SIP overload is already 104 specified [RFC7339]. Although this framework supports the use of 105 alternative client restriction algorithms, so far only proportional 106 "loss" - the mandatory default method in [RFC7339], and maximum 107 "rate" - the default of [RFC7415], have been defined. In both cases 108 the value of the control parameter, whether the % of requests 109 rejected or the maximum rate of requests respectively, applies to the 110 entire stream of requests that a (source) client is trying to send to 111 the (target) server subjected to overload. The priority assigned to 112 requests, that determines the probability of being admitted or 113 rejected by the clients, is the responsibility of clients alone. 115 This has several serious drawbacks. Certain within-dialogue requests 116 methods are critical to the performance of SIP and therefore should 117 never be rejected because doing so would lead to timeouts, 118 retransmissions, inefficient use of resources and degraded user 119 experience. Leaving the decision up to clients alone about which 120 requests these are and how they are treated is unreliable. Some could 121 make poor decisions about which request methods are exempt from 122 control. 124 Because certain requests are exempt from rate limiting, for the 125 maximum rate-based method the rate enforced at the client is lower 126 than the entire sent rate. This rate reduction requires every client 127 to execute a function - in real-time because the exempt traffic mix 128 changes over time - to map from the received oc parameter rate to a 129 lower rate that applies only to requests that are not exempt from 130 restriction. As a consequence a server that is the target of overload 131 could be receiving requests from a range of sources where each client 132 is dynamically making different choices about which requests are 133 exempt and which are not. This compromises the ability of the target 134 server to protect itself and maintain good throughput. 136 This new recommendation proposes a simpler and more reliable 137 approach, which is to specify the exempt request methods so that they 138 are known in advance by server and clients, and for the target server 139 (rate-based method) to produce a maximum rate that applies only to 140 request methods that are not exempt from rejection by control. The 141 framework of [RFC7339] conveniently enables this if a new oc-algo 142 parameter value "nxrate" (non-exempt rate) is introduced. The 143 algorithm negotiation mechanism of [RFC7339] still applies so that 144 clients and server can differentiate between "nxrate", "rate" and 145 "loss" and therefore still operate in a mixed control scheme network 146 environment whilst enabling convergence to support any one of these. 148 Also included is an enhanced rate control algorithm at the target 149 server that is a simple extension of the [RFC7415] default, to 150 control traffic from (source) clients that do not comply with the use 151 of the oc Via header parameters, but in a way that favours compliant 152 sources. This is essential in the likely situation that a network has 153 connection between many communication or equipment providers, some of 154 which do not support the use of these oc parameters. The need for 155 this is recognised in [RFC7339] (section 5.10.2) but a solution is 156 not provided. 158 The appendix of [RFC7339] provides an assessment against the 159 requirements for SIP overload control as described in [RFC5390]. See 160 the Appendix A RFC5390 requirements herein for an updated assessment 161 against this specification. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 In this document a "source" is used to refer to any SIP (client) 170 entity that sends traffic to a downstream (next hop) SIP (server) 171 entity, referred to as a "target". 173 Limiting the rate of sending SIP requests will be referred to as 174 "restriction", and an instance of a control that does this is 175 referred to as a "restrictor". Elsewhere in published literature 176 these terms are sometimes referred to as "throttling" and a 177 "throttle" respectively. 179 If a SIP request is not admitted by a restrictor, then "rejection" 180 means that an explicit SIP failure response is returned, whereas 181 "discard" means that the request is ignored with minimal action taken 182 (such as being counted) and in particular no SIP response is 183 returned. 185 3. Overview 187 The functional architecture is identical to that described in 188 [RFC7415], i.e. the target (server) is subject to load and protected 189 by the overload control scheme and the sources (clients) restrict 190 traffic towards the target. 192 The Via header parameters oc, oc-algo, oc-validity, oc-seq have the 193 same usage as defined in section 4 of [RFC7339], with the same method 194 of algorithm selection as section 5.1. 196 Here we introduce the new oc-algo non-exempt rate token "nxrate". 198 4. Request priorities, including exemption from restriction 200 According to [RFC7339], prioritizing which requests are subject to 201 rejection by control is 'largely' a matter of local (client) policy 202 (section 5.10.1) and, in order that client and server have a common 203 understanding of which messages overload control applies to, the oc 204 parameter value applies to all requests from client to server 205 (section 5.3). 207 Because of this approach the server will not know which request types 208 may be rejected by a client and which are exempt from control, which 209 could also vary from one client to another. Furthermore if certain 210 request types are to be exempt from control then each client must 211 compute an adjustment to the oc parameter value received from the 212 server. For the rate-based method of [RFC7415] this amounts to a 213 'rate reduction factor' that multiplies the rate to obtain a lower 214 maximum admit rate. This must be dynamic since it depends upon the 215 request method mix, and the computation method and its parameters 216 (including update frequency) may vary from one client to another. It 217 is possible that some clients may make poor decisions about which 218 request methods are exempt from control or have poor implementations 219 of the rate reduction factor function. This could have consequences 220 for the target server to properly protect itself and maintain 221 adequate and effective throughput. 223 In contrast this specification assumes that certain request methods, 224 defined below, are critical to the performance of SIP and must not be 225 rejected by control, and these exempt methods will therefore be known 226 in advance by server and clients. By means of defining a new oc-algo 227 parameter token value (section 5) the client will understand that 228 the oc parameter only applies to request methods that are not exempt, 229 so there is a common understanding of which messages control applies 230 to. This approach also simplifies implementation and configuration 231 since it obviates the need for each client to calculate a rate 232 reduction factor value in real-time. 234 4.1. Exempt request methods 236 Because a SIP response to an ACK is disallowed, not admitting an ACK 237 would lead to timeout and retransmission. Similarly rejecting a PRACK 238 would lead to timeout and retransmission. CANCEL and BYE both result 239 in terminating a dialogue and therefore freeing up resources. For 240 these reasons the following request methods, and only these methods, 241 MUST be exempt from restriction: ACK, PRACK, CANCEL, BYE. 243 These four request methods are implicitly prevented from overloading 244 the SIP network by limiting the rate of sending dialogue-initiating 245 INVITEs, as follows. 247 o An ACK is sent to confirm the receipt of a final response to 248 sending an INVITE (whether dialogue-initiating or within 249 dialogue), and hence there is a one-to-one correspondence between 250 INVITE's sent and ACKs sent. Consequently in the longer term 251 (although not under very short-term transients) limiting the rate 252 of sending INVITEs will also limit the rate of sending ACKs; 254 o A PRACK is sent to confirm receipt of a provisional response to an 255 INVITE, so that there is a one-to-one correspondence with each 256 provisional response, and although there is no strict bound on the 257 number of provisional responses per INVITE sent, in practice the 258 number is likely to be very small (and often one); 260 o Similarly there is an upper bound on the ratio of CANCELs to 261 INVITEs since there can be at most one CANCEL per INVITE (and 262 usually zero); 264 o BYE is the only way to terminate a confirmed dialogue - and 265 therefore release associated resources - and hence there is a 266 similar correspondence with dialogue-initiating INVITEs, although 267 the timescale of dependence is greater. 269 Note: As per section 14 of [RFC3261], automatic generation of BYEs 270 following detection of media failure should not be synchronised, i.e. 271 sending should be spread out over time (e.g. randomised), in order to 272 avoid overload. If needed a server may control the non-exempt (e.g. 273 INVITE) acceptance rate to reduce the queuing and processing time 274 required for BYEs. 276 4.2. Non-exempt request priorities 278 In line with section 5.10.1 of [RFC7339], the non-exempt priority 279 levels SHOULD be derived with respect to the general principles that 280 requests within a dialogue shall be given higher priority than those 281 that are not within a dialogue, and that the highest priority levels 282 of non-exempt requests includes all those associated with emergency 283 calls as identified by the SIP user or SOS URN, or contents of the 284 Resource-Priority header, etc. Note that although these non-exempt 285 requests are given the highest priority, it is possible that (for 286 example) emergency traffic alone could be sufficient to cause 287 overload, therefore they cannot be made exempt from restriction. 289 4.2.1. Factors determining priorities of within dialogue request methods 291 It is undesirable to reject within-dialogue (early or confirmed) 292 requests because this could prevent certain sessions from being 293 established and would cause inefficient use of SIP resources or poor 294 quality of service. 296 For example, an INVITE may be sent within a dialogue in order to 297 modify the dialogue state or session parameters. Rejecting such a re- 298 INVITE may result in termination of the session, causing poor quality 299 of user experience, inefficient use of resources - which had 300 previously been devoted to the session, and a possible user retry. 301 The UPDATE method is similar, but in addition it may be sent for an 302 early dialogue and hence required for dialogue initiation. In this 303 case rejecting it may prevent certain types of sessions from being 304 setup. 306 Although it is undesirable to reject such within-dialogue request 307 methods, more extreme/unusual traffic conditions could arise which 308 dictate that such methods need to be rejected. For example, if there 309 were a very large number of concurrent dialogues at a SIP node 310 because the holding time is large and the rate of within-dialogue 311 requests such as UPDATEs for every dialogue is also high (perhaps 312 because of some future application or because of rogue behaviour), if 313 UPDATEs were exempt from restriction then overload could arise and 314 the control would be unable to do anything about it. 316 4.2.2. Illustrative numerical values of priority 318 It is convenient to define default priority values by means of 319 counting numbers, ordered inversely to importance. The requests with 320 the highest importance, exempt requests, have a priority of 0 which 321 does not change, and the remaining non-exempt request priorities are 322 in order of decreasing importance, from 1 upwards. This makes it 323 straightforward to map one-one between priorities and multiple leaky 324 bucket thresholds of the default restriction method included in 325 section 3.5.2 of [RFC7415]. It also means that that priority values 326 can be straightforwardly assigned by configuration of SIP or the SIP 327 user. 329 It is recognised that the most important requests, which includes 330 emergency calls, may include more than one category of request, so we 331 assume that there are n distinct additional such levels. 333 The principles above result in default priority values having the 334 requests associated as shown in Table 1. 336 When the request method is complemented by the other criteria, then 337 with a single level of highest priority non-exempt requests (n=1), we 338 obtain the complete list of assigned priority values shown in Table 339 2. 341 priority 342 values requests methods 343 ________ ________________ 345 0 exempt methods ACK, PRACK, CANCEL, BYE 347 1...n highest priority non-exempt request levels, including 348 emergency calls 350 1+n within-dialogue (confirmed or unconfirmed) methods, not 351 associated with highest non-exempt priorities 353 2+n out-of-dialogue methods other than INVITE or REGISTER, 354 not associated with highest non-exempt priorities 356 3+n out-of-dialogue INVITE or REGISTER methods (e.g. new 357 calls), not associated with highest non-exempt 358 priorities 360 Table 1: Descriptions of requests associated with default priority 361 values 363 Request exempt within highest priority priority 364 Method ? dialogue? non-exempt? Value 365 ________________________________________________________ 367 ACK yes yes n/a 0 368 BYE yes yes n/a 0 369 CANCEL yes yes n/a 0 370 PRACK yes yes n/a 0 371 INFO no yes no 2 372 INFO no yes yes 1 373 INVITE no no no 4 374 INVITE no no yes 1 375 INVITE no yes no 2 376 INVITE no yes yes 1 377 MESSAGE no no no 3 378 MESSAGE no no yes 1 379 MESSAGE no yes no 2 380 MESSAGE no yes yes 1 381 NOTIFY no yes no 2 382 NOTIFY no yes yes 1 383 OPTIONS no no no 3 384 OPTIONS no no yes 1 385 OPTIONS no yes no 2 386 OPTIONS no yes yes 1 387 PUBLISH no no no 3 388 PUBLISH no no yes 1 389 REFER no no no 3 390 REFER no no yes 1 391 REGISTER no no no 4 392 REGISTER no no yes 1 393 SUBSCRIBE no no no 3 394 SUBSCRIBE no no yes 1 395 SUBSCRIBE no yes no 2 396 SUBSCRIBE no yes yes 1 397 UPDATE no yes no 2 398 UPDATE no yes yes 1 399 Table 2: Priority value assignment to request methods with 400 additional criteria, for a single highest request category that 401 includes emergency calls (n=1 highest category) 403 5. "nxrate" token for oc-algo parameter value 405 According to section 5.3 of [RFC7339] the server produces an oc 406 parameter value that "...it expects the receiving SIP clients to 407 apply to all downstream SIP requests (dialogue forming as well as in- 408 dialogue)...". Similarly section 3.4 of [RFC7415] requires that " The 409 maximum rate determined by the server for a client applies to the 410 entire stream of SIP requests, even though throttling may only affect 411 a particular subset of the requests...". 413 The scheme specified here interprets the oc parameter differently 414 because it only applies to the non-exempt requests that have been 415 defined in section 4.1. To ensure that a client communicating with 416 overload control capable servers can differentiate the max rate-based 417 method of [RFC7415], which uses the oc-algo token "rate", from this 418 max rate-based method, we introduce the new token "nxrate" indicating 419 that the oc value provides the non-exempt rate. 421 5.1. Control algorithm selection 423 For a source (client) to be compliant with non-exempt rate-based 424 control it MUST include the token "nxrate" in the oc-algo list. 426 For a target (server) to be compliant with non-exempt rate-based 427 control it MUST select and return "nxrate" as the only oc-algo list 428 value if and only if "nxrate" is present in the oc-algo list received 429 from a source. In addition, if "nxrate" is not present it MUST treat 430 the source as non-compliant and allocate a local restrictor as 431 defined in section 6.1.1. 433 6. Rate control algorithm 435 Clients MUST implement a type of algorithm that enforces maximum 436 admission rate (as required by [RFC7415]), which shall also be able 437 to differentiate between the range of non-exempt priority levels 438 defined in section 4.2, in such a way that higher priority requests 439 are admitted in preference to lower priority requests, whilst the 440 total admission rate for all priorities of non-exempt requests is 441 subject to the maximum non-exempt rate. 443 The default leaky bucket algorithm in section 3.5.1 of [RFC7415] with 444 the additional features in section 3.5.2 (for priorities) SHOULD be 445 used, where the number of 'tolerance' reject thresholds required will 446 be equal to the number of priorities. The features of section 3.5.3 447 SHOULD also be included to avoid performance degradation due to 448 'resonance' which can occur when there are a large number of sources 449 connected to a target. 451 Isomorphic algorithms that give identical behaviour MAY be used as 452 alternatives to a leaky bucket, e.g. a token bank rather than a leaky 453 bucket, whereby the bank is filled with tokens at a rate equal to the 454 leak rate. 456 Servers employ an enhanced version of the rate control for non- 457 compliant or non-conforming sources, as described in the following 458 subsections. 460 6.1. Target server rate control for non-compliant or non-conforming 461 sources (clients) 463 For a realistic overload control deployment, especially for 464 connection between networks managed by different communication 465 providers, or where the control capability is being deployed in 466 stages, a SIP server is very likely to be connected to a mix of some 467 client nodes that conform with an overload control protocol 468 ([RFC7339] or [RFC7415]) and others that do not. A source (client) is 469 conformant if it is both compliant with the overload control protocol 470 but also modulates the SIP requests that it sends to a target 471 according to the control information that it has received; being 472 compliant means that it correctly advertises support for an overload 473 control in the SIP requests that it sends. Therefore a non-conforming 474 source may be non-compliant or may be compliant but not apply control 475 properly. 477 A target must be able to protect itself effectively against traffic 478 from non-compliant sources. But rejecting requests incurs an overhead 479 that must be limited by the target, else it cannot properly protect 480 its capacity and prevent overload. In a less trustworthy/tested 481 network environment it must be able to protect against non-conforming 482 sources as well. Furthermore it should be advantageous for sources to 483 become compliant and conformant as an incentive for this overload 484 control scheme to be deployed and a deterrent to malicious non- 485 conformance. 487 Some of the above factors are recognised in section 5.10.2 of 488 [RFC7339] where requirements on a server connected to non-compliant 489 clients are outlined, but a solution is not provided. 491 To address this a rate control algorithm is defined (section 6.1.1) 492 that is an enhancement of the default algorithm in [RFC7415]. When a 493 such rate controller should be allocated at a target, and how it 494 treats arriving requests is described in section 6.1.1, and the 495 steady-state throughput of this algorithm in terms of different 496 request outcomes is analysed in section 6.1.4. 498 6.1.1. Enhanced rate control algorithm for target server 500 The target restriction function MUST use the type of algorithm 501 defined as the default in [RFC7415], including multiple priorities as 502 per section 3.5.2, and with the following additional features: 504 o An additional bucket 'discard' threshold TAU* that is greater than 505 any other threshold. Whenever a request (including those that are 506 exempt) is received and the fill is greater than TAU*, then the 507 request is discarded, i.e. ignored without sending a response. 509 o The bucket fill is increased when rejecting a request as well as 510 when admitting one. The increase fill amount represents the cost 511 of rejection and will be system dependent. Some possibilities are 512 outlined in section 6.1.4. The fill is NOT increased when 513 discarding a request. 515 Isomorphic algorithms that give identical behaviour may be used as 516 alternatives to a leaky bucket, e.g. a token bank rather than a leaky 517 bucket, whereby the bank is filled with tokens at a rate equal to the 518 leak rate, and that take account of the cost of rejection and allow 519 discard of requests in a similar way. 521 Note: The algorithm described in [RFC7415] compares the bucket fill 522 with a reject or 'tolerance' threshold before admitting a request, so 523 that if admitted the fill may increase above the threshold. Similar 524 rate control behaviour results if the fill comparison is made 525 assuming that the request would have been admitted (even if it then 526 isn't), in which case the fill cannot increase above the threshold 527 for that request on admission, although it can on rejection. In the 528 latter case the maximum fill of the bucket is the discard threshold, 529 whereas in the former case the maximum fill will be the discard 530 threshold plus the maximum increase on rejection. 532 The original algorithm, without the above enhancements, which is used 533 for the source restriction function (since discard is forbidden at 534 this point), is in fact a special case of the enhanced algorithm, 535 obtained simply by setting a 0 cost of rejection. As long as the 536 discard threshold TAU* is sufficiently larger than the highest reject 537 threshold, it will have no effect since the fill cannot attain TAU*. 539 6.1.2. Rate controller allocation and treatment of requests for a target 540 server 542 When a target server activates overload control it MUST derive a 543 maximum non-exempt rate - the control rate - for every source from 544 which it receives SIP traffic. It SHOULD allocate a rate controller 545 of the type defined in section 6.1.1 to control traffic from every 546 source that is non-compliant and it MUST allocate one for any non- 547 compliant source where the received non-exempt rate exceeds the 548 control rate. 550 To guard against any non-conformant sources the target MAY allocate a 551 rate controller against compliant sources as well. This would be 552 desirable for less trusted or less tested connections, but may be 553 deemed unnecessary within a trusted or wholly owned network domain. 555 Every request from the source MUST query the restrictor on arrival at 556 the target, including requests that are exempt from restriction at 557 the source. As a result the request may be 559 o admitted, 561 o rejected with response, but only if the request is non-exempt, 563 o discarded, possibly even if the request is exempt (under an 564 extreme condition defined in section 6.1.1, depending upon the 565 leaky bucket implementation variant). 567 To discard means that the request is ignored, i.e. the receiving 568 target does not take any further action (such as returning a SIP 569 response), apart from possibly counting the discard action e.g. for 570 management statistics. 572 6.1.3. Summary of performance characteristics of the solution 574 As shown in section 6.1.4 the solution has the following desirable 575 behaviour: 577 o For a request arrival rate up to the control (oc) rate derived by 578 the target, requests will be processed normally; 580 o As the request arrival rate rises above the control rate, the rate 581 of admitted requests decreases and the remainder are rejected; 583 o After the admission rate reaches 0 (because all requests are being 584 rejected), as the arrival rate increases further, the arrivals 585 that make up the excess rate are discarded, using minimal 586 processing. Once in this region the source receives no service 587 from the target; 589 o Non-compliant sources are penalised if they exceed their assigned 590 control rates because the success rate decreases and eventually 591 they get no service at all. 593 In this way the target workload due to the arriving traffic 594 represented by the rate controller always remains bounded. 596 6.1.4. Steady-state outcome rates of the enhanced target rate control 598 For any specific traffic source the maximum admitted request rate for 599 that source as derived by the target will be related in some way to 600 the average resource workload required to process requests according 601 to the current mix of traffic. Whereas the default rate controller 602 algorithm as specified in section 3.5 of [RFC7415] does not take 603 account of the overhead of rejecting a request, the enhanced 604 algorithm does so by increasing the bucket fill on rejection by an 605 amount that depends in general on the system design. 607 For example this amount MAY be of the simple form T0+pT in terms of 608 the current value of the bucket increment T (defined in [RFC7415] as 609 the reciprocal of the oc rate value), with parameters T0 (constant) 610 and p, the fraction of the cost of admission, where one or the other 611 (but not both) of these could be 0. 613 The effect of the algorithm will be that as the request arrival rate 614 increases above the max rate R, the admitted rate will decrease. This 615 will be illustrated by an example. 617 The bucket leaks at a constant rate of 1, so that once the bucket is 618 'full' the bucket load is 1 and the arrival rate A and admission rate 619 a are just equal (no rejects): 621 AT = aT = 1 623 Since T=1/R these rates equal to the oc rate R. 625 As the arrival rate increases the admission rate will (automatically) 626 decrease just enough so that the bucket utilisation remains at 1, 627 i.e. 629 A + (A-a)(pT+T0)=1 631 which has the solution 633 / A A < R 634 a = ( (R - A(p+RT0))/(1-p-RT0) R <= A <= R/(p+RT0) 635 \ 0 R/(p+RT0) <= A 637 so that as the arrival rate increases above R the admit rate 638 decreases linearly with gradient -(p+RT0))/(1-p-RT0). 640 Once the bucket is rejecting every request, i.e. a=0, if the arrival 641 rate continues to increase then A > R/(p+RT0) which implies that 643 A + (A-a)(pT+T0) > R(pT+T0)/(p+RT0) = 1 645 i.e. the offered bucket load is greater than 1, and since it leaks at 646 a constant rate of 1 this means that it is unstable and the occupancy 647 (fill) would rise constantly. This is prevented by having the 648 additional discard threshold TAU*. In this range of extreme arrival 649 rate, we have: 651 a = 0 652 r = R/(p+RT0) 653 d = A - r 655 where r is the reject rate and d the discard rate, i.e. the reject 656 rate remains constant and the discard rate continues to rise as the 657 difference between the arrival rate and the reject rate. 659 7. Server operation 661 7.1. Control rate (oc value) allocation over sources 663 The actual algorithm used by the server to determine its overload 664 state and estimate a target maximum SIP request rate, which we will 665 refer to here as the goal rate, is not within the scope of [RFC7415]. 666 However the server is required to evaluate this goal rate and it must 667 determine how it will distribute the rates over its client sources. 669 Although neither the objectives nor the method of this rate 670 distribution function are prescribed by [RFC7415], they are critical 671 since they affect the quality of service, both absolute, and relative 672 between, different client sources. Although the method is not 673 specified here, the objectives are made more precise. 675 7.2. Overload control objectives 677 The target server overload control MUST satisfy the following two 678 objectives: 680 1. Objective (total rate received from all sources) - Prevent the 681 target from overload and maximise the rate received by the target, 682 subject to the goal rate bound, i.e. when the total source rate 684 o exceeds the goal rate, then the arrival rate is equal to, or very 685 close to, the goal rate 687 o less than the goal rate, no requests are rejected at the sources, 688 i.e. the rate received by the target is the entire source rate; 690 2. Objective (allocation of rates over sources) - Shape the 691 allocation of rates received from each source in a predictable way 692 that can be regarded as 'fair' in some precise sense or conforming 693 with an SLA previously agreed with client sources. 695 The first objective will make the most effective use of the target 696 capacity - in particular it is essential to avoid 'over-restriction' 697 whereby the received rate is significantly lower than the goal if the 698 total arrival rate at the sources is less than the goal rate, or 699 'under-restriction', whereby insufficient demand is rejected, which 700 could lead to the problems of overload. 702 To demonstrate the importance of Objective 2 it is useful to give 703 examples of control behaviour that would be unacceptable or at least 704 highly undesirable, even though they both meet Objective 1: 706 1. Example - It may be possible to satisfy Objective 1 in a way so 707 that some sources are denied any service at all (given an oc rate 708 of 0). Furthermore, such an extreme distribution could vary over 709 time, i.e. those sources that are denied any service could change, 710 perhaps randomly. 712 2. Example - The overload of a target may be dominated by traffic 713 from just a few sources, thereby significantly affecting the rate 714 of loss due to rejection experienced by traffic from other 715 sources, even though their levels of traffic are relatively low at 716 'normal' expected levels. 718 8. Target server failover configuration 720 In order to provide resilience to failure it is usual for each active 721 target server to have a standby. It is possible for a target server 722 failover to occur whilst overload control is ongoing. This requires 723 special consideration. 725 Active and standby servers may or may not share IP addresses and they 726 may or may not share overload control state. These factors affect 727 overload control behaviour during failover and choice of oc-validity 728 and oc-seq parameter values. 730 The control parameters that are returned from an overloaded target 731 are associated with its IP address and port number. If that server 732 fails the restrictor allocated at the source against that 733 address/port will persist through the failover with the oc max rate 734 parameter value from the failed target, as long as the duration timer 735 (of length oc-validity) remains running or until an update with a new 736 oc value and higher oc-seq value is received for the same 737 address/port. If the activated standby has a different IP address and 738 it signals overload then a new restrictor would be allocated against 739 that address, unless an identification between the active and standby 740 addresses is made by the source. If control state is not shared then 741 the activated standby would not start in an overload state and 742 therefore return an oc-validity value of 0, which would have the 743 effect of terminating any control already active against its 744 address/port. 746 The above factors have implications for the minimum size of the oc- 747 validity parameter and the oc-seq values that are sent in responses 748 from the standby target as it activates. 750 8.1. oc-validity values 752 The required minimum size of oc-validity can be determined with 753 reference to the timing of events shown in Error! Reference source 754 not found.. 756 Under normal conditions when the target remains active, to prevent a 757 control restrictor at a source expiring before another update is 758 received, thereby causing a sudden surge of traffic being sent, the 759 oc-validity value should be larger than the time between updates 760 (which may be variable) and the time it takes to distribute control 761 to all sources that are sending at a 'sufficiently high' rate. Such 762 sources are those sending at a rate above the max control rate 763 determined by the oc value (if a source with a lower rate terminates 764 control it would have no effect on the admitted traffic, so such 765 sources do not need to receive an update - which would take a long 766 time to be received in any case). Since the distribution time will be 767 variable it is safer to use an oc-validity value equal to twice the 768 (maximum) time between updates, since updates should not normally be 769 made before distribution has become effective. 771 Considering now failover from an active target, in terms of ensuring 772 that control persists for long enough according to the oc-validity 773 size, the worst time for this to occur would be just before all 774 updates have been received (see Error! Reference source not found.). 775 So the restrictors should persist for an additional time which is the 776 time it takes for the newly activated server to start responding and 777 stabilise. This duration will depend upon several factors, including 779 o the method of target failure detection used by the sources 781 o whether or not state is shared between active and standby 783 o whether overload control is active before or after the failover 784 (or both) 786 Therefore the minimum value of oc-validity returned by a server MUST 787 be 789 2x(time between control updates) 790 + (expected duration of failover stabilisation) 792 In addition if client/sources receive updates at nearly the same 793 time, then if they were all to apply the same oc-validity value the 794 duration timers would expire near simultaneously, resulting in a 795 surge of traffic. Therefore it is better to spread out the expiry 796 times. 798 Values of oc-validity returned by an overloaded target MUST be 799 distributed over a range with the minimum value above. The maximum of 800 this range SHOULD by default be 802 3x(time between control updates) 803 + (expected duration of failover stabilisation) 805 so that the range duration is the length of time between control 806 updates. 808 time 809 : 810 : size of 811 Update --> U oc-validity 812 | distribution 813 | over max 814 | sources 815 v ^ 816 : | 817 Update --> U | 818 | distribution | 819 | over min | 820 | sources | 821 v ^ | 822 : | | 823 Update --> U | | 824 | distribution | | 825 | over | | 826 | sources | | 827 V | | 828 : | | 829 Update --> U | | 830 | distribution | | 831 | over | | 832 | sources | | 833 v | | 834 Failure starts --> X | | 835 x standby server | | 836 x does not | | 837 x respond | | 838 Standby responses start --> S | | 839 ( target | | 840 ) server | | 841 ( stabilisation | | 842 ) [ control | | 843 ( may | | 844 ) activate ] | | 845 v v v 846 : 847 : 849 Figure 1 Timeline of events around target server failover effecting 850 the minimum duration of the oc-validity parameter 852 It is not possible to be precise about the default oc-validity 853 applied by a client because it depends upon the server behaviour and 854 the network connectivity. However, unlike the proportional loss-based 855 method of [RFC7339] which needs to be updated more frequently 856 because, for the same rejection probability, the admitted rate is 857 proportional to the arrival rate (which is in general changing), 858 there is less risk with leaving control on for longer and more risk 859 with terminating it prematurely. 861 Therefore it is recommended that the client SHOULD use a default 862 value of 10 seconds rather than the 500ms of [RFC7339] and [RFC7415]. 864 8.2. oc-seq values 866 During normal operation the oc-seq value is increased by a server 867 according to section 4.4 of [RFC7339]. We clarify this process, and 868 add further recommendations under failover conditions. 870 The oc-seq value MUST be increased when a control update (i.e. a re- 871 evaluation of the oc value) has been performed by the server, even if 872 this results in the same oc value. This is necessary to cause the oc- 873 validity timer to be restarted, as per section 5.4 of [RFC7339]. The 874 oc-seq SHOULD NOT be increased when there has not been a control 875 update because this would cause the unnecessary overhead of 876 restarting/extending the oc-validity timer and re-applying the same 877 received oc value of rate, in effect for every request received by 878 the target. 880 The oc-seq value after failover depends upon whether control state is 881 shared between active and standby servers. 883 8.2.1. Control state is shared 885 Control updates of the standby are straightforwardly managed by 886 increasing oc-seq from the value before failover. 888 8.2.2. Control state is not shared 890 The value of the oc-seq parameter sent in responses MUST be set lower 891 than the value sent before failover, during the period of 892 stabilisation when the newly activated target is not in an overload 893 state (oc-validity=0 sent). This is required to ensure that the 894 responses do not terminate any already active control at the sources. 896 If the oc-seq value is derived from the current time, then this MAY 897 be achieved by deriving the oc-seq of the activated standby from the 898 following expression which gives a time before the standby becomes 899 activated (on restart or failover): 901 (activation time) - (maximum configured server oc-validity value) 903 A consequence of this approach, together with the setting of 904 sufficiently long oc-validity timer (as per section 8.1), is that, 905 if overload control of the server before failover was active, then 906 the standby is less likely to enter an overloaded state for a period 907 after failover. However it is likely to go into overload when the oc- 908 validity duration timers expire at the sources, and to ensure that oc 909 values are effective at sources the oc-seq value must then be derived 910 in the normal way. I.e. the server MUST revert to its normal oc-seq 911 derivation according to the current time at the start of overload 912 control following activation of the standby, when oc-validity > 0 for 913 the first time. 915 In summary, if oc-seq is derived from time, then the only changes to 916 its value will be when control updates are made or when (or before) 917 the server becomes active. 919 8.3. Relationship of source restrictor to a target and its standby 921 A source applying control identifies an overloaded target by its IP 922 address and port number. Thus if a target server and its standby 924 o share a common address/port then a single restrictor at the source 925 will necessarily be associated with both the target and its 926 standby. 928 o do not share a common address/port then there will be an 929 independent restrictor associated with each. However if they share 930 overload state then the new restrictor allocated on failover will 931 be quickly assigned the control state of the failed target. 933 Note that there is no SIP mechanism defined by which a source can 934 discover which of the above address configurations is the case. 936 Consequently a target MUST ensure that source rate control persists 937 during failover of a target to its standby in one (or more) of the 938 following ways: 940 o Share a common IP address and port number with its standby and 941 setting the oc-seq values (section 8.2.2); 943 o Share overload control state with its standby (section 8.2.1); 945 o Use another mechanism that has been agreed between sources and the 946 target server. If server and standby have distinct IP addresses 947 this MAY be done by the source associating a single restrictor 948 with both addresses. 950 9. Example - including failover 952 The example generalises the example in Section 4 of [RFC7415] with 953 multiple client sources s1,s2,...,s8 sending requests to an active 954 downstream target server T1, which has a standby T2. Overload control 955 activates for T1 which later fails whilst overload is ongoing so that 956 T2 takes over. This example assumes that T1 and T2 have the same IP 957 address/port but they do not share control state, which is one of the 958 cases in section 8.3. 960 INVITE sips:user@example.com SIP/2.0 961 Via: SIP/2.0/TLS s7.example.net; 962 branch=z9hG4bKs714400.3; 963 oc;oc-algo="nxrate,rate,loss" 964 ... 965 SIP/2.0 100 Trying 966 Via: SIP/2.0/TLS s7.example.net 967 branch=z9hG4bKs714400.3;received=192.0.2.117; 968 oc=0;oc-algo="nxrate";oc-validity=0; 969 oc-seq=1546214400.5 971 The first message above is sent by s7 to T1. This message is a SIP 972 request; because s7 supports overload control, it inserts the "oc" 973 parameter in the topmost Via header field that it created. s7 974 supports three overload control algorithms: "nxrate", "loss", "rate". 976 The second message, a SIP response, shows the topmost Via header 977 field amended by T2 according to this specification and sent to s7. 978 Because T2 also supports the non-exempt rate overload control method, 979 it chooses this nxrate-based scheme and sends that back to s7 in the 980 "oc-algo" parameter. It uses oc-validity=0 to indicate no overload 981 control. In this example, "oc=0", but "oc" could be any value as 982 "oc" is ignored when "oc-validity=0". Assume for this example that 983 oc-seq is a time in seconds with precision 0.1 sec. 985 At some later time, T1 starts to experience overload. Just before 986 the next response is about to be returned, to s3, the maximum rate 987 admissible from s3 is 15 non-exempt requests per second. The time 988 between target control updates is 3 seconds and suppose that prior 989 design and validation has shown that stabilisation of failover from 990 T1 to T2 takes at most 4 seconds. Therefore T1 returns the following 991 SIP message indicating S3 should send SIP requests at a rate less 992 than or equal to 15 non-exempt SIP requests per second and (as per 993 section 8.1) for a duration chosen between 2x3+4=10 and 3x3+4=13 994 seconds (note oc-validity is in ms): 996 SIP/2.0 180 Ringing 997 Via: SIP/2.0/TLS s3.example.net; 998 branch=z9hG4bKs314460.1;received=192.0.2.113; 999 oc=15;oc-algo="nxrate";oc-validity=12765; 1000 oc-seq=1546214460.4 1001 ... 1003 Just after this response has been sent the server T1 fails and no 1004 longer responds to requests, which causes T2 (which has the same IP 1005 address/port) to takeover. Suppose T2 starts responding 0.5 sec later 1006 and after receiving an INVITE from s8 it returns the following 1007 indicating that overload control should be inactive because it had no 1008 prior load and it does not shared control state with T1 and therefore 1009 is not aware that T1 was in overload: 1011 SIP/2.0 100 Trying 1012 Via: SIP/2.0/TLS s8.example.net; 1013 branch=z9hG4bKs814460.2;received=192.0.2.118; 1014 oc=0;oc-algo="nxrate";oc-validity=0; 1015 oc-seq=1546214447.9 1017 Because T2 is activating it has taken the actual time 1546214460.9 1018 and reduced it by 13 secs to derive the oc-seq value according to 1019 section 8.2.2. Consequently the rate control at source s3 (and 1020 similarly for other sources s1,...,s8) will not be terminated even 1021 though it has received oc-validity=0 because the oc-seq value is 1022 lower than the last value received. T2 is now receiving requests at 1023 approximately the same rate as T1 was. 7.1 seconds after activating, 1024 T2 determines that it needs to activate control and so it sets oc-seq 1025 according to the actual time and chooses another non-zero value of 1026 oc-validity in its configured range: 1028 SIP/2.0 200 OK 1029 Via: SIP/2.0/TLS s1.example.net; 1030 branch=z9hG4bKs114467.2;received=192.0.2.111; 1031 oc=0;oc-algo="nxrate";oc-validity=10763; 1032 oc-seq=1546214468.0 1034 It is returning this to s1 knowing that it cannot have already 1035 received a higher oc-seq value (in the recent past). 1037 10. Syntax 1039 This specification extends the existing definition of the Via header 1040 field parameters of [RFC7339] as follows: 1042 algo-list =/ "nxrate" 1044 11. Backwards compatibility 1046 As highlighted in section 10.2 of [RFC7339], a new overload control 1047 protocol needs to be able to be gradually introduced into a network 1048 and function properly if only a subset of the nodes support it. 1050 This scheme can co-exist in a network where nodes support either 1051 [RFC7339], or [RFC7415], or neither. The use of the new oc-algo token 1052 "nxrate" together with the control algorithm type negotiation of 1053 section 5.1 of [RFC7339] enables any client or server to determine 1054 (dynamically) whether or not each neighbouring node supports this 1055 scheme. If a node does so as a server, then the method of section 1056 6.1. enables allocation of a proxy source restrictor at the target 1057 for each non-compliant source. In terms of request priority 1058 differentiation, rejection response, etc, the arriving traffic is 1059 managed in the same way at the target as if at a source. The cost of 1060 rejection is also accounted for, so as to bound the total workload 1061 (resource utilisation) in such a way that the rate of requests 1062 admitted from a non-compliant source decreases as the arrival rate 1063 increases. Since the arrival rate from such a source may be 1064 unlimited, ultimately discard of some requests, i.e. throwing them 1065 away without returning an explicit response, will be necessary. In 1066 this way compliant sources are favoured over non-compliant or non- 1067 conforming sources. 1069 12. Security considerations 1071 This mechanism does not introduce any security concerns beyond the 1072 general overload control security issues discussed in section 11 of 1073 [RFC7339]. 1075 13. IANA considerations 1077 This specification uses the Via header parameters defined in 1078 [RFC7339] and registered with IANA in the "Header Field Parameter and 1079 Parameter Values" sub-registry, appearing as follows, with the new 1080 value for oc-algo defined in section 10: 1082 Header Parameter Predefined 1083 Field Name Values Reference 1084 _______________________________________________________ 1086 Via oc Yes [RFC7339] 1087 Via oc-validity Yes [RFC7339] 1088 Via oc-seq Yes [RFC7339] 1089 Via oc-algo Yes [RFC7339][RFC7415] 1091 14. References 1093 14.1. Normative References 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", RFC2119, March 1997. 1098 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1099 A., Peterson, J., Sparks, R., Handley, and E. Schooler, 1100 "SIP: Session Initiation Protocol", RFC3261, June 2002. 1102 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 1103 Priority for the Session Initiation Protocol (SIP)", 1104 RFC4412, June 2002. 1106 [RFC7339] Gurbani, V., Ed., Hilt, V., and H. Schulzrinne, "Session 1107 Initiation Protocol (SIP) Overload Control", RFC7339, 1108 September 2014. 1110 [RFC7415] Noel, E., and P. Williams, "Session Initiation Protocol 1111 (SIP) Rate Control", RFC7415, February 2015. 1113 14.2. Informative References 1115 [RFC5390] Rosenberg, J., "Requirements for Management of Overload in 1116 the Session Initiation Protocol", RFC5390, December 2008. 1118 15. Acknowledgments 1120 Thanks are due to the following people for their contribution to and 1121 review of material included in this specification: Mark Ashworth, 1122 Chris Bovis, Ken Hatt, Adrian Moss, Nick Ireland, Tim Pierrepont, 1123 Martin Simmonds, Paul Theobald, Nigel Weinronk, Jonathan Welton, and 1124 other members of the NICC SIP Overload Control Task Group. 1126 This document was prepared using 2-Word-v2.0.template.dot. 1128 Appendix A. RFC5390 requirements 1130 Appendix B of [RFC7339] lists each of the requirements from [RFC5390] 1131 and assesses whether each is fulfilled. The subset of those 1132 requirements that this specification meets more effectively or more 1133 completely is listed below. 1135 REQ 4: The mechanism must be capable of dealing with elements that do 1136 not support it so that a network can consist of a mix of elements 1137 that do and don't support it. In other words, the mechanism should 1138 not work only in environments where all elements support it. It is 1139 reasonable to assume that it works better in such environments, of 1140 course. Ideally, there should be incremental improvements in overall 1141 network throughput as increasing numbers of elements in the network 1142 support the mechanism. 1144 Met as follows: The issue of how a target server should 1145 treat traffic that it receives from sources that do not support 1146 overload control is discussed in section 5.10.2 of [RFC7339], but 1147 no solution is provided. This specification provides a simple 1148 but effective scheme in section 6.1. See also REQ 20. 1150 REQ 5: The mechanism should not assume that it will only be deployed 1151 in environments with completely trusted elements. It should seek to 1152 operate as effectively as possible in environments where other 1153 elements are malicious; this includes preventing malicious elements 1154 from obtaining more than a fair share of service. 1156 Met as follows: The scheme described here in section 6.1 not 1157 only controls traffic from sources that are non-compliant, but 1158 also those that declare themselves to be compliant by means of 1159 the protocol parameters but (perhaps maliciously) do not restrict 1160 the request rate accordingly. 1162 REQ 13: The mechanism must not dictate a specific algorithm for 1163 prioritizing the processing of work within a proxy during times of 1164 overload. It must permit a proxy to prioritize requests based on any 1165 local policy so that certain ones (such as a call for emergency 1166 services or a call with a specific value of the Resource-Priority 1167 header field ([RFC4412]) are given preferential treatment, such as 1168 not being dropped, being given additional retransmission, or being 1169 processed ahead of others. 1171 Met as follows: A modified view of this requirement is taken 1172 here, i.e. that the requests should be divided into two subsets - 1173 those that are exempt from control, and those that are not. The 1174 exempt requests are defined (section 4.1) and therefore common 1175 for clients and servers. Recommendations are given for how to 1176 assign priority levels of non-exempt requests (section 4.2), 1177 together with default values (section 4.2.2), but this does not 1178 preclude the use of different choices. 1180 REQ 17: The overload mechanism must not provide an avenue for 1181 malicious attack, including DoS and DDoS attacks. 1183 Met as follows: As per REQ 5, a malicious attack from 1184 non-conforming sources with high traffic rates is controlled 1185 according to section 6.1. The issues associated with using 1186 insecure communications are the same as presented in [RFC7339]. 1188 REQ 20: In a mixed environment of elements that do and do not 1189 implement the overload mechanism, no disproportionate benefit shall 1190 accrue to the users or operators of the elements that do not 1191 implement the mechanism. 1193 Met as follows: Objective 2 (section 7.2) requires that rates 1194 are allocated precisely over source elements, including those 1195 that are non-compliant, and the enhanced rate control algorithm 1196 (section 6.1) ensures that, in terms of admitted traffic, for a 1197 non-compliant source element there is a disadvantage that becomes 1198 greater the more traffic it sends. 1200 Author's Address 1202 Philip Williams 1203 NICC Standards 1204 BT Technology 1205 Adastral Park 1206 Ipswich IP5 7RE 1207 England 1209 Email: phil.m.williams@bt.com