idnits 2.17.1 draft-campbell-dime-load-considerations-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 -- The document date (October 25, 2014) is 3472 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-dime-ovli-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Campbell 3 Internet-Draft Oracle 4 Intended status: Informational October 25, 2014 5 Expires: April 28, 2015 7 Architectural Considerations for Diameter Load Information 8 draft-campbell-dime-load-considerations-00 10 Abstract 12 RFC 7068 describes requirements for Overload Control in Diameter. 13 This includes a requirement to allow Diameter nodes to send "load" 14 information, even when the node is not overloaded. The Diameter 15 Overload Information Conveyance (DOIC) solution describes a mechanism 16 meeting most of the requirements, but does not currently include the 17 ability to send load. This document explores some architectural 18 considerations for a mechanism to send load information. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 28, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Differences between Load and Overload information . . . . . . 3 56 3. How is Load Information Used? . . . . . . . . . . . . . . . . 4 57 4. Piggy-Backing vs a Dedicated Application. . . . . . . . . . . 4 58 5. Which Nodes Exchange Load Information? . . . . . . . . . . . 5 59 6. Scope of Load Information . . . . . . . . . . . . . . . . . . 6 60 7. Load Information Semantics . . . . . . . . . . . . . . . . . 7 61 8. Is Negotiation of Support Needed? . . . . . . . . . . . . . . 7 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 11.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 [RFC7068] describes requirements for Overload Control in Diameter 72 [RFC6733]. At the time of this writing, the DIME working group is 73 working on the Diameter Overload Information Conveyance (DOIC) 74 mechanism. As currently specified, DOIC fulfills some, but not all, 75 of the requirements. 77 In particular, DOIC does not fulfill Req 24, which requires a 78 mechanism where Diameter nodes can indicate their current load, even 79 if they are not currently overloaded. DOIC also does not fulfill Req 80 23, which requires that nodes that diverts traffic away from 81 overloaded nodes be provided with sufficient information to select 82 targets that are most likely to have sufficient capacity. 84 There are several other requirements in RFC 7068 that mention both 85 overload and load information that are only partially fulfilled by 86 DOIC. 88 The DIME working group explicitly chose not to fulfill these 89 requirements in DOIC due to several reasons. A principal reason was 90 that the working group did not agree on a general approach for 91 conveying load information. It chose to progress the rest of DOIC, 92 and defer load information conveyance to a DOIC extension or a 93 separate mechanism. 95 This document describes some high level architectural decisions that 96 the working group will need to consider in order to solve the load- 97 related requirements from RFC 7068. 99 At the time of this writing, there have been several attempts to 100 create mechanisms for conveyance of both load and overload control 101 information that were not adopted by the DIME working group. While 102 these drafts are not expected to progress, they may be instructive 103 when considering these decisions. 105 o [I-D.tschofenig-dime-dlba] proposed a dedicated Diameter 106 application for exchanging load balancing information. 108 o [I-D.roach-dime-overload-ctrl] described a strictly peer-to-peer 109 exchange of both load and overload information in new AVPs piggy- 110 backed on existing Diameter messages. 112 o [I-D.korhonen-dime-ovl] described a dedicated Diameter application 113 for exchanging both load and overload information. 115 2. Differences between Load and Overload information 117 Previous discussions of how to solve the load-related requirements in 118 [RFC7068] have shown that people do not have an agreed-upon concept 119 of how "load" information differs from "overload" information. The 120 two concepts are highly interrelated, and so far the working group 121 has not defined a bright line between what constitutes load 122 information and what constitutes overload information. 124 In the author's opinion, there are two primary differences. First, a 125 Diameter node always has a load. At any given time that load maybe 126 effectively zero, effectively fully loaded, or somewhere in between. 127 In contrast, overload is an exceptional condition. A node only has 128 overload information when it in an overloaded state. Furthermore, 129 the relationship between a node's load level and overload state at 130 any given time may be vague. For example, a node may normally 131 operate at a "fully loaded" level, but still not be considered 132 overloaded. Another node may declare itself to be "overloaded" even 133 though it might not be fully "loaded". 135 Second, Overload information, in the form of a DOIC Overload Report 136 (OLR) [I-D.ietf-dime-ovli] indicates an explicit request for action 137 on the part of the reacting node. That is, the OLR requests that the 138 reacting node reduce the offered load by an indicated amount or to an 139 indicated level. Effectively, DOIC provides a contract between the 140 reporting node and the reacting node. 142 In contrast, load is informational. That is, load information can be 143 considered a hint to the recipient node. That node may use the load 144 information for load balancing purposes, as an input to certain 145 overload abatement techniques, to make inferences about the 146 likelihood that the sending node becomes overloaded in the immediate 147 future, or for other purposes. 149 None of this prevents a Diameter node from deciding to reduce the 150 offered load based on load information. The fundamental difference 151 is that an overload report requires that reduction. 153 3. How is Load Information Used? 155 [RFC7068] contemplates two primary uses for load information. Req 23 156 discusses how load information might be used when performing 157 diversion as an overload abatement technique, as described in 158 [I-D.ietf-dime-ovli]. When a reacting node diverts traffic away from 159 an overloaded node, it needs load information for the other 160 candidates for that traffic in order to effectively load balance the 161 diverted load between potential candidates. Otherwise, diversion has 162 a greater potential to drive other nodes into overload. 164 Req 24 discusses how a Diameter information might be used when no 165 overload condition currently exists. Diameter nodes can use the load 166 information to make decisions to try to avoid overload conditions in 167 the first place. Normal load-balancing falls into this category. A 168 node might also take other proactive steps to reduce offered load 169 based on load information, so that the loaded node never goes into 170 overload in the first place. 172 If the loaded nodes are Diameter servers (or clients in the case of 173 server-to-client transactions), both of these uses are most 174 effectively accomplished by a Diameter node that performs server 175 selection. Typically, server selection is performed by a node (a 176 client or an agent) that is an immediate peer of the server. However 177 a client or proxy that is not an immediate peer to the selected 178 server can enforce server selection by inserting a Destination-Host 179 AVP. 181 4. Piggy-Backing vs a Dedicated Application. 183 [I-D.roach-dime-overload-ctrl] imbeds load and overload information 184 onto messages of existing applications. This is known as a "piggy- 185 back" approach. Such an approach has the advantage of not requiring 186 new messages to carry load information. It has an additional 187 advantage of scaling with load; that is, the more the transaction 188 load, the more opportunities to send load information. 190 DOIC [I-D.ietf-dime-ovli] also uses a piggy-backed approach to send 191 OLRs. Given the potentially tight connection between load and 192 overload information, there may be advantages to maintaining 193 consistency with DOIC. 195 [I-D.tschofenig-dime-dlba] used a dedicated application to carry load 196 information. This application has quasi-subscription semantics, 197 where a client requests updates according to a cadence. The server 198 can send unsolicited updates if the load level changes between 199 updates in the cadence. 201 [I-D.korhonen-dime-ovl] also used a dedicated application, but 202 allowed nodes to send unsolicited reports containing load and 203 overload information. The mechanism has an issue that the sender of 204 load information may not know which other nodes need it. It may be 205 possible to infer that information from the primary Diameter 206 applications. 208 Another potential approach is that of a dedicated Diameter 209 application with a slightly different subscription semantic than that 210 of [I-D.tschofenig-dime-dlba]. In such an application, a node that 211 consumes load information sends a Diameter request to the source of 212 the load information. This request indicates that the consumer 213 wishes to receive load information for some period of time. The load 214 source would send periodic Diameter requests indicating the current 215 load level, until such time that the subscription period expired, or 216 the subscribe explicitly unsubscribed. After the initial 217 notification, the sender would only send updates when the load level 218 changed. 220 5. Which Nodes Exchange Load Information? 222 Previous load related efforts have made different assumptions about 223 which Diameter nodes exchange load information. 225 [I-D.roach-dime-overload-ctrl] operated in a strictly peer-to-peer 226 mode. Each node would only learn the load (and overload) information 227 from its immediate peers. 229 [I-D.korhonen-dime-ovl] and [I-D.tschofenig-dime-dlba] are each 230 effectively any-to-any. That is, they each allowed any node to send 231 load information to any other node that supported the dedicated 232 overload or load application, respectively. 234 In the latter case, load is effectively sent between clients and 235 servers of the dedicated application, but those roles may not match 236 the client and server roles for the "main" Diameter applications in 237 use. For example, a pair of adjacent diameter agents might be 238 "client" and "server" for the dedicated "load" application, 239 effectively creating a peer-to-peer relationship similar to that of 240 [I-D.roach-dime-overload-ctrl]. 242 Each approach has advantages. Since server selection is typically 243 done by immediate peers to the servers, peer-to-peer transmission 244 covers most cases. Additionally, selection of non-terminal nodes is 245 exclusively done on a peer-to-peer basis. If the loaded node is an 246 agent, for example, the load information is only useful to immediate 247 peers. Peer-to-peer transmission is the easiest to negotiation. 248 (See Section 8) 250 Any-to-Any transmission offers more flexibility, and could 251 potentially cover the case where server selection is done by nodes 252 that are not peers to the candidate servers. 254 6. Scope of Load Information 256 The "scope" of load information defines what the load indication 257 applies to. For example, load could apply to a whole Diameter node, 258 or a node could report different load for different application. It 259 might be possible to have a load value for a whole realm, or a group 260 of nodes. 262 [I-D.roach-dime-overload-ctrl] has a very expressive concept of 263 scope, which applies both to load and overload information. It 264 defines the scopes of "Destination-Realm", "Application-ID", 265 "Destination-Host", "Host", "Connection", "Session", and "Session- 266 Group". Scopes can be combined. 268 [I-D.tschofenig-dime-dlba] does not have an explicit concept of 269 scope. Load information describes the load of a server for all 270 Diameter purposes. 272 [I-D.korhonen-dime-ovl] defines several scopes for overload 273 information. However, load information applies to the a whole node. 275 The author's opinion is that the load level of a Diameter node will 276 usually apply to the whole node. Thus, the working group should 277 consider a single "whole node" scope for load information. 278 Alternatively, a "per-connection" scope could simulate "whole node" 279 scope without requiring the recipient to pay attention to whether 280 multiple transport connections terminate at the same peer. 282 7. Load Information Semantics 284 Both [I-D.tschofenig-dime-dlba] and [I-D.korhonen-dime-ovl] define 285 load level to be a range between zero and some maximum value, where 286 zero means no load at all and the max value means fully loaded. The 287 former uses a range of 0-10, while the later uses 0-100 289 [I-D.roach-dime-overload-ctrl] treats load information as a strictly 290 relative weighting factor. The weight is only meaningful when load- 291 balancing across multiple destinations. That is, a maximum load 292 value does not necessarily imply that the node is cannot handle more 293 traffic. The load level scale is zero to 65535. That scale was 294 chosen to match the resolution of the weight field from a DNS SRV 295 record, [RFC2782] 297 8. Is Negotiation of Support Needed? 299 The working group should discuss whether a load conveyance mechanism 300 requires negotiation or declaration of support. Several 301 considerations apply to this discussion. 303 If load information is treated as a hint, it can be safely ignored by 304 nodes that don't understand it. However, security considerations may 305 apply if load information is accidentally leaked across a non- 306 supporting node to a node that is not authorized to receive it. 308 If load information is conveyed using a dedicated Diameter 309 application, the normal mechanisms for negotiation support for 310 Diameter applications apply. However, the Diameter Capabilities 311 Exchange [RFC6733] mechanism is inherently peer-to-peer. If there is 312 an need to convey load information across a node that does not 313 understand the mechanism, the standard Diameter mechanism would 314 involve probing by support by sending load requests and watching for 315 error answers with a result code of DIAMETER_APPLICATION_UNSUPPORTED. 316 If the probe request also includes load information, there is again a 317 potential for leaking load information to unauthorized parties. 319 If load information was treated in a strictly peer-to-peer fashion, 320 there would be no need to probe to see if non-adjacent nodes support 321 the mechanism. However, there would still be a need to control 322 whether a non-supporting node would leak load information. Such a 323 leak could be prevented if adjacent peers declared support, and never 324 sent load information to a peer that did not declare support. 326 A peer-to-peer mechanism would also need a way to make sure that, if 327 load information leaked across a non-supporting node, the receiving 328 node would not mistakenly think the information came from the non- 329 supporting node. This could be mitigated with a mechanism to declare 330 support as in the previous paragraph, or with a mechanism to identify 331 the origin of the load information. In the latter case, the 332 receiving node would treat any load information as invalid if the 333 origin of that information did not match the identity of the peer 334 node. 336 9. Security Considerations 338 Load information may be sensitive information in some cases. 339 Depending on the mechanism. an unauthorized recipient might be able 340 to infer the topology of a Diameter network from load information. 341 Load information might be useful in identifying targets for Denial of 342 Service (DoS) attacks, where a node known to be already heavily 343 loaded might be a tempting target. Load information might also be 344 useful as feedback about the success of an ongoing DoS attack. 346 Any load information conveyance mechanism will need to allow 347 operators to avoid sending load information to nodes that are not 348 authorized to receive it. Since Diameter currently only offers 349 authentication of nodes at the transport level, any solution that 350 sends load information to non-peer nodes might require a transitive- 351 trust model. 353 10. IANA Considerations 355 This document makes no requests of IANA. 357 11. References 359 11.1. Normative References 361 [I-D.ietf-dime-ovli] 362 Korhonen, J., Donovan, S., Campbell, B., and L. Morand, 363 "Diameter Overload Indication Conveyance", draft-ietf- 364 dime-ovli-03 (work in progress), July 2014. 366 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 367 "Diameter Base Protocol", RFC 6733, October 2012. 369 [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control 370 Requirements", RFC 7068, November 2013. 372 11.2. Informative References 374 [I-D.korhonen-dime-ovl] 375 Korhonen, J. and H. Tschofenig, "The Diameter Overload 376 Control Application (DOCA)", draft-korhonen-dime-ovl-01 377 (work in progress), February 2013. 379 [I-D.roach-dime-overload-ctrl] 380 Roach, A. and E. McMurry, "A Mechanism for Diameter 381 Overload Control", draft-roach-dime-overload-ctrl-03 (work 382 in progress), May 2013. 384 [I-D.tschofenig-dime-dlba] 385 Tschofenig, H., "The Diameter Load Balancing Application 386 (DLBA)", draft-tschofenig-dime-dlba-00 (work in progress), 387 July 2013. 389 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 390 specifying the location of services (DNS SRV)", RFC 2782, 391 February 2000. 393 Author's Address 395 Ben Campbell 396 Oracle 397 7460 Warren Parkway # 300 398 Frisco, Texas 75034 399 USA 401 Email: ben@nostrum.com