idnits 2.17.1 draft-liu-dyncast-reqs-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([DYNCAST-PS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 133: '... o MUST provide a discovery and map...' RFC 2119 keyword, line 175: '... o MUST maintain "instance affinity...' RFC 2119 keyword, line 176: '...the packets from the same flow MUST go...' RFC 2119 keyword, line 193: '... o MUST agree on the service-specif...' RFC 2119 keyword, line 197: '... o MAY obfuscate the specific seman...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2021) is 1164 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-liu-dyncast-ps-usecases-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dyncast P. Liu 3 Internet-Draft China Mobile 4 Intended status: Informational P. Willis 5 Expires: August 15, 2021 BT 6 D. Trossen 7 Huawei 8 February 15, 2021 10 Dynamic-Anycast (Dyncast) Requirements 11 draft-liu-dyncast-reqs-00 13 Abstract 15 This draft provides requirements for an architecture addressing the 16 problems outlined in the use case and problem statement draft for 17 Dyncast [DYNCAST-PS]. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 22, 2021. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 2 55 3. Desirable System Characteristics and Requirements . . . . . . 3 56 3.1. Anycast-based Service Addressing Methodology . . . . . . . 3 57 3.2. Instance Affinity . . . . . . . . . . . . . . . . . . . . 3 58 3.3. Encoding Metrics . . . . . . . . . . . . . . . . . . . . . 4 59 3.4. Signaling Metrics . . . . . . . . . . . . . . . . . . . . 5 60 3.5. Using Metrics in Routing Decisions . . . . . . . . . . . . 5 61 3.6. Supporting Service Dynamism . . . . . . . . . . . . . . . 6 62 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Informative References . . . . . . . . . . . . . . . . . . . . 7 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Computing service instances instantiated at multiple geographical 72 edge sites are used to better realize an edge computing service in 73 edge computing use cases, as shown in [DYNCAST-PS]. To optimally 74 deliver the service request to the most appropriate service instance 75 is the fundamental requirement in such deployments. As shown in 76 [DYNCAST-PS], choosing the most appropriate service instance should 77 take both, the computing resources available and the network path 78 quality, into consideration. "Optimal" here additionally means the 79 architecture and overall mechanism should be efficient, support high 80 dynamism, while maintaining instance affinity, as shown in [DYNCAST- 81 PS]. 83 This draft provides the requirements to realize the potential dynamic 84 anycast architecture by alleviating the problems of existing 85 solutions outlined in [DYNCAST-PS]. 87 2. Definition of Terms 89 Service: A service represents a defined endpoint of functionality 90 encoded according to the specification for said service. 92 Service instance: One service can have several instances running on 93 different nodes. Service instance is a running environment (e.g., 94 a node) that makes the functionality of a service available. 96 Service identifier: Used to uniquely identify a service, at the same 97 time identifying the whole set of service instances that each 98 represent the same service behaviour, no matter where those 99 service instances are running. 101 Anycast: An addressing and packet sending methodology that assign an 102 "anycast" identifier for one or more service instances to which 103 requests to an "anycast" identifier could be routed, following 104 the definition in [RFC4786] as anycast being "the practice of 105 making a particular Service Address available in multiple, 106 discrete, autonomous locations, such that datagrams sent are 107 routed to one of several available locations". 109 Dyncast: Dynamic Anycast, taking the dynamic nature of computing 110 resource metrics into account to steer an anycast-like decision 111 in sending an incoming service request. 113 3. Desirable System Characteristics and Requirements 115 In the following, we outline the desirable characteristics of a 116 system to overcome the observed problems in [dyncast-ps] for the 117 realization of the use cases described in that document. 119 3.1. Anycast-based Service Addressing Methodology 121 A unique service identifier is used by all the service instances for 122 a specific service no matter which edge it attaches to. An anycast 123 like addressing and routing methodology among multiple edges makes 124 sure the data packet can potentially reach any of the edges with the 125 service instance attached. At the same time, each service instance 126 has its own unicast address to be used by the attaching edge to 127 access the service.Since a client will use the service identifier as 128 the destination addressing, mapping of the service identifier to the 129 unicast address will need to happen in-band, considering the metrics 130 for selection to make this selection service-specific. From an 131 addressing perspective, a desirable system 133 o MUST provide a discovery and mapping methodology for the in-band 134 mapping of the service identifier (an anycast address) to a 135 specific unicast address. 137 3.2. Instance Affinity 139 A routing relation between a client and a service exists not at the 140 packet but at the service request level in the sense that one or more 141 service requests, possibly consisting of one or many more routing- 142 level packets, must be ensured to be sent to said service.Each 143 service may be provided by one or more service instances, each 144 providing equivalent service functionality to their respective 145 clients, while those service instances may be deployed at different 146 locations in the network. With that, the routing problem becomes one 147 between the client and a selected service instance for at least the 148 duration of the service-level request, but possibly more than just 149 one request. 151 This relationship between the client and the chosen service instance 152 is described as "instance affinity" in the following, where the 153 "affinity" spans across the aforementioned one or more service 154 requests. This impacts the routing decision to be taken in that the 155 normal packet level communication, i.e., each packet is forwarded 156 individually based on the forwarding table at the time, will need 157 extending with the notion of instance affinity since otherwise 158 individual packets may be sent to different places when the network 159 status changes, possibly segmenting individual requests and breaking 160 service-level semantics. 162 The nature of this affinity is highly dependent on the nature of the 163 specific service. The minimal affinity of a single request represents 164 a stateless service, where each service request may be responded to 165 without any state being held at the service instance for fulfilling 166 the request. Providing any necessary information/state in-band as 167 part of the service request, e.g., in the form of a multi-form body 168 in an HTTP request or through the URL provided as part of the 169 request, is one way to achieve such stateless nature. Alternatively, 170 the affinity to a particular service instance may span more than one 171 request, as in our VR example in [DYNCAST-PS], where previous client 172 input is needed to render subsequent frames. Therefore, a desirable 173 system 175 o MUST maintain "instance affinity" which MAY span one or more 176 service requests, i.e., all the packets from the same flow MUST go 177 to the same service instance. 179 3.3. Encoding Metrics 181 As outlined in the scenarios in [DYNCAST-PS], metrics can have many 182 different semantics, particularly if considered to be service- 183 specific. Even the notion of a "computing load" metric may be 184 computed in many different ways. What is crucial, however, is the 185 representation and encoding of that metric when being conveyed to the 186 routing fabric in order for the routing elements to act upon those 187 metrics. Such representation may entail information on the semantics 188 of the metric or it may be purely one or more semantic-free numerals. 189 Agreement of the chosen representation among all service and network 190 elements participating in the service-specific routing decision is 191 important. Specifically, a desirable system 193 o MUST agree on the service-specific metrics and their 194 representation between service elements in the participating edges 195 in the network and network elements acting upon them. 197 o MAY obfuscate the specific semantic of the metric to preserve 198 privacy of the service provider information towards the network 199 provider. 201 o MAY include routing protocol metrics 203 3.4. Signaling Metrics 205 The aforementioned representation of metrics needs conveyance to the 206 network elements that will need to act upon them. Depending on the 207 service-specific decision logic, one or more metrics will need to be 208 conveyed. Problems to be addressed here may be that of loop avoidance 209 of any advertisement of metrics as well as the frequency of such 210 conveyance and therefore the overall load that the signaling may add 211 to the overall network traffic. While existing routing protocols may 212 serve as a baseline for signaling metrics, other means to convey the 213 metrics can equally be realized. Specifically, a desirable system 215 o MUST provide mechanisms to signal the metrics for using in routing 216 decisions 218 o MUST realize means for rate control for signaling of metrics 220 o MUST implement mechanisms for loop avoidance in signaling metrics, 221 when necessary 223 3.5. Using Metrics in Routing Decisions 225 Metrics being conveyed, as outlined in Section 3.4, in the agreed 226 manner, as outlined in Section 3.3, will ultimately need suitable 227 action in the routers of the network. Routing decisions can be 228 manifold, possibly including (i) min or max over all metrics, (ii) 229 extending previous action with a random or first choice when more 230 than one min/max entry found, (iii) weighted round robin of all 231 entries, among others. It is important for the proper work of the 232 service-specific routing decision, that it is understood to both 233 network and service provider, which action (out of a possible set of 234 supported actions) is to be used for a particular set of metrics. 235 Specifically, a desirable system 237 o MUST specify a default action to be taken, if more than one action 238 possible 240 o SHOULD enable other alternative actions to be taken. 242 o Any solution MUST provide appropriate signaling of the desired 243 action to the router. For this, the action MAY be signaled in 244 combination with signaling the metric (see Section 3.4). 246 o Any solution SHOULD allow associating the desired action to a 247 specific service identifier. 249 3.6. Supporting Service Dynamism 251 Network cost in the current routing system usually does not change 252 very frequently. However, computing load and service-specific metrics 253 in general can be highly dynamic, e.g., changing rapidly with the 254 number of sessions, CPU/GPU utilization and memory space. It has to 255 be determined at what interval or events such information needs to be 256 distributed among edges. More frequent distribution of more accurate 257 synchronization may result in more overhead in terms of signaling. 259 Choosing the least path cost is the most common rule in routing. 260 However, the logic does not work well when routing should be aware of 261 service-specific metrics. Choosing the least computing load may 262 result in oscillation. The least loaded edge can quickly be flooded 263 by the huge number of new computing demands and soon become 264 overloaded with tidal effects possibly following. 266 Generally, a single instance may have very dynamic resource 267 availability over time in order to serve service requests. This 268 availability may be affected by computing resource capability and 269 load, network path quality, and others. The balancing mechanisms 270 should adapt to the service dynamism quickly and seamlessly. With 271 this, the relationship between a single client and the set of 272 possible service instances may possibly be very dynamic in that one 273 request that is being dispatched to instance A may be followed by a 274 request that is being dispatched to instance B and so on, generally 275 within the notion of the service-specific service affinity discussed 276 before in Section 3.2. With this in mind, a desirable system 278 o MUST support the dynamics of metrics changing on, e.g., a per flow 279 basis, without violating the metrics defined in the selection of 280 the specific service instance, while taking into account the 281 requirements for the signaling of metrics and routing decision 282 (see Section 3.4 and 3.5). 284 4. Conclusion 285 This document presents high-level requirements for solutions to 286 Dyncast, where the architecture should address how to distribute the 287 resource information and how to assure instance affinity in an 288 anycast based service addressing environment, while realizing 289 appropriate routing actions to satisfy the metrics provided. 291 5. Security Considerations 293 TBD 295 6. IANA Considerations 297 No IANA action is required so far. 299 7. Informative References 301 [DYNCAST-PS] P. Liu, P. Willis, D. Trossen, "Dynamic-Anycast 302 (Dyncast) Use Cases and Problem Statement", draft-liu-dyncast-ps- 303 usecases-01 (work in progress), February 2021. 305 [RFC4786] J. Abley, K. Lingqvist, "Operation of Anycast Services", 306 RFC4786, December 2006, https://tools.ietf.org/html/rfc4786 308 Acknowledgements 310 The author would like to thank Yizhou Li, Luigi IANNONE and Geng 311 Liang for their valuable suggestions to this document. 313 Authors' Addresses 315 Peng Liu 316 China Mobile 317 Email: liupengyjy@chinamobile.com 319 Peter Willis 320 BT 321 Email: peter.j.willis@bt.com 323 Dirk Trossen 324 Huawei 325 Email: dirk.trossen@huawei.com