idnits 2.17.1 draft-asveren-dispatch-http-overload-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 31 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2018) is 2205 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: 'RFC8224' is mentioned on line 72, but not defined == Unused Reference: 'RFC2119' is defined on line 273, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH T. Asveren 3 Internet-Draft Ribbon 4 Intended status: Standards Track April 13, 2018 5 Expires: October 15, 2018 7 HTTP Overload Control Mechanism 8 draft-asveren-dispatch-http-overload-control-00 10 Abstract 12 This document specifies a generic overload control mechanism for 13 HTTP/HTTPS applications. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on October 15, 2018. 32 Copyright Notice 34 Copyright (c) 2018 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 (https://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. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 51 3. Overload Control Mechanism . . . . . . . . . . . . . . . . . 3 52 3.1. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2. Capability Negotiation . . . . . . . . . . . . . . . . . 3 54 3.3. Overload-Control Header . . . . . . . . . . . . . . . . . 4 55 3.4. Procedures at the Client . . . . . . . . . . . . . . . . 4 56 3.5. Procedures at the Server . . . . . . . . . . . . . . . . 5 57 3.6. Procedures at the Proxy . . . . . . . . . . . . . . . . . 5 58 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 8. Appendix A: Example Message Flow . . . . . . . . . . . . . . 6 63 9. Informative References . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Overview 68 HTTP is used between clients and servers for request/response based 69 interaction in the context of many different applications. Some of 70 these applications have tight timing requirements for receiving a 71 response. For example, a signing request done toward a Signing 72 Server in the context of STIR RFC 8224 [RFC8224] usually is 73 associated with a real time session setup procedure which needs to 74 complete in a given time frame. For such applications it is 75 imperative to consider the actual load on a server to meet the timing 76 requirements. Current HTTP overload control relies on using 503 with 77 a Retry-After header indicating for how long no request should be 78 sent to a server. This, although sufficient for certain 79 applications, does not always provide satisfactory results as it 80 allows only binary control of the load following a step function 81 pattern. TCP congestion window does not address this issue either as 82 it does not allow an application direct control and is impacted by 83 network conditions like latency, jitter, packet loss. Therefor there 84 is a need for a mechanism which can address the overload control 85 needs of HTTP applications in general for which existing mechanisms 86 are not sufficient. Similar phenomena is observed for other 87 protocols as well. For example, for SIP the issue is addressed by 88 defining a specific mechanism in RFC 7339 [RFC7339]. Therefore This 89 document specifies a generic overload control mechanism for HTTP/ 90 HTTPS applications. 92 The notion of applying different drop probabilities for separate 93 categories is supported as well. A category is an abstract construct 94 as far as this specification is concerned. It pertains to different 95 policy characteristics and is meaningful in the context of an 96 application. It, for example, may refer to different priority levels 97 for requests, e.g. regular, emergency, government agency. 99 2. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119. 105 3. Overload Control Mechanism 107 3.1. Algorithm 109 The overload control algorithm described in this document relies on 110 the concept of dropping a request with a certain probability on the 111 client which otherwise would bee sent to a particular server. 113 This approach is favored considering that neither the number of 114 clients sending requests to a server nor the volume of requests from 115 a client is known a priori at a given point in time and can change 116 dynamically. This dynamic nature makes any alternative approach 117 which would utilize a quota based control on a per client basis 118 unviable. An efficient solution should act in a as fair as possible 119 way on the aggregate of requests received by a server from all 120 clients. 122 3.2. Capability Negotiation 124 A client supporting this specification SHOULD add a Pragma header to 125 a request for which overload control is applicable with the value 126 "overload-control". A client MAY choose to send this Pragma header 127 only for the first or some requests to the server. 129 Example: 130 Pragma: overload-control 132 A server supporting this specification MUST interpret presence of the 133 Pragma header with the value "overload-control" as an indication that 134 client supports this specification and SHOULD follow server related 135 semantics defined in this specification. Receipt of a single such 136 request SHOULD be interpreted as the client supporting the overload 137 control mechanism. 139 A server not supporting this specification ignores a Pragma header 140 with the value "overload-control". 142 A server MAY assume that a client supports this specification even if 143 no Pragma header with the value "overload-control" is received. 145 3.3. Overload-Control Header 147 A new entity header named "Overload-Control" is defined and used in 148 HTTP responses. 150 It is used to carry information about drop probability for messages 151 in a specified category. 153 TBD: A parameter indicating validity time will be added. 155 Example: 156 Overload-Control: oc=1, odp=30; oc=2, odp=45; oc, odp=60 158 o Drop category1 requests with a probability of 30% 160 o Drop category2 requests with a probability of 45% 162 o Drop category3 requests with a probability of 60% 164 Drop probability indicated by an Overload-Control header without a 165 category parameter applies to all categories. 167 3.4. Procedures at the Client 169 A client supporting this specification SHOULD drop a request which 170 would be sent to a server based on the probability value received in 171 Overload-Control header received in the latest response. This SHOULD 172 be done as follows: 174 Create a local table for all categories. All categories initial drop 175 probability is "0". 177 When an Overload-Control header is received: 179 o Update the drop percentage for the category in the local table. 181 o Drop a request based on the probability value for its category in 182 the local table. 184 A client MUST interpret and honor a Retry-After header according to 185 existing HTTP standard even if it supports and uses overload conytol 186 mechanism specified in this document. 188 3.5. Procedures at the Server 190 A server supporting this specification SHOULD determine its own 191 overload state. How this is done is implementation dependent and not 192 subject to standardization in the context of this document. 194 A server SHOULD add an Overload-Control header indicating the 195 category and the drop probability of requests to a response if its 196 overload state changes. The mapping between actual overload state 197 and drop probability is implementation dependent. 199 3.6. Procedures at the Proxy 201 There is no specific functionality required from a Proxy in the 202 context of this specification. Proxies will transparently pass 203 Pragma headers in requests and Overload-Control headers in responses. 205 4. Formal Syntax 207 The syntax of the Overload-Control header is described as follows: 209 Overload-Control = "Overload-Control" HCOLON 1*(*(overload-category)1(overload-drop-probability)) 210 overload-category = "oc COMMA" EQUAL overload-category-value 211 overload-category-value = 1*ALPHA 212 overload-drop-probability = "odp" EQUAL overload-drop-probability-value 213 overload-drop-probability-value = 1DIGIT/2DIGIT/"100" 215 5. IANA Considerations 217 Overload-Control is defined as an "entity" header and does not need 218 to be registered in IANA "Permanent Header Field Names" Registry 219 List. 221 TBD: May change based on input from experts 223 6. Security Considerations 225 HTTPS SHOULD be used between client and server if overload control 226 mechanism is used. This is needed to prevent attackers to change the 227 drop probability used by clients to a value other than the one 228 intended by the server. 230 7. Acknowledgements 231 8. Appendix A: Example Message Flow 233 Client-1 Client-2 Server 234 | | | 235 Sends all requests | | 236 | | | 237 | | | 238 |-------Request(category1)--------------->| 239 | | | 240 | | | 241 |<------Response--------------------------| 242 | | | 243 | | | 244 | | Overload condition changes 245 | | It is decided to drop 246 | | 50% of category1 requests 247 | | | 248 | | | 249 |-------Request-------------------------->| 250 | | | 251 |<-Response(Overload-Control: oc=1;odp=50)| 252 | | | 253 Drops category1 requests | | 254 with a 50% probability | | 255 Sends all category2 requests | 256 | | | 257 | | | 258 | Sends all requests | 259 | | | 260 | |--Request--------------->| 261 | | | 262 | |<-Response(Overload-Control: oc=1;odp=50) 263 | | | 264 | Drops category1 requests | 265 | with a 50% probability | 266 | Sends all category2 requests | 267 | | | 268 | | | 269 | | | 271 9. Informative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 [RFC7339] Gurbani, V., Ed., Hilt, V., and H. Schulzrinne, "Session 279 Initiation Protocol (SIP) Overload Control", RFC 7339, 280 DOI 10.17487/RFC7339, September 2014, 281 . 283 Author's Address 285 Tolga Asveren 286 Ribbon Communications 287 Freehold, NJ 07728 288 USA 290 Email: tasveren@rbbn.com