idnits 2.17.1 draft-chen-alto-survey-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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'SDN' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'VPN' is defined on line 444, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG S. Chen 3 Internet-Draft X. Lin 4 Intended status: Informational Tongji University 5 Expires: January 3, 2019 D. Lachos 6 Unicamp 7 Y. Yang 8 Tongji/Yale University 9 C. Rothenberg 10 Unicamp 11 July 2, 2018 13 ALTO Implementations and Use Cases: A Brief Survey 14 draft-chen-alto-survey-00 16 Abstract 18 This document provides a comprehensive survey of ALTO, including 19 current ALTO implementations and ALTO used in the literature work. 20 This document identifies possible challenges and future opportunities 21 of ALTO. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 3, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. ALTO Background . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Goals and Scope . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Document Organization . . . . . . . . . . . . . . . . . . 3 67 2. ALTO Implementations . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Services Implemented in Projects . . . . . . . . . . . . 3 69 2.2. ALTO in Software Defined Mobile Networks . . . . . . . . 4 70 2.3. Recognized Issues and Future Work . . . . . . . . . . . . 4 71 3. ALTO in Literature/Use Cases . . . . . . . . . . . . . . . . 5 72 3.1. Peer Selection . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.1. Peer Selection in P2P . . . . . . . . . . . . . . . . 6 74 3.1.2. Surrogate Selection in CDN . . . . . . . . . . . . . 6 75 3.1.3. Downstream CDN Selection in CDNI . . . . . . . . . . 6 76 3.1.4. Cache Selection in Hybrid CDN-P2P System . . . . . . 6 77 3.1.5. Mobile Edge Caching . . . . . . . . . . . . . . . . . 7 78 3.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 7 79 3.2.1. Path Selection in MPTS-AR . . . . . . . . . . . . . . 7 80 3.3. Resource Placement . . . . . . . . . . . . . . . . . . . 8 81 3.3.1. Virtualized Service Function Chain Placement . . . . 8 82 3.3.2. Intelligent Virtual Machine Placement . . . . . . . . 8 83 3.3.3. Service Placement in IoT . . . . . . . . . . . . . . 8 84 3.4. Measure Results Interface . . . . . . . . . . . . . . . . 8 85 3.4.1. An Interface to Query on the LMAP measure results . . 8 86 4. Challenges and Research Opportunities . . . . . . . . . . . . 9 87 4.1. Possible New Address Format . . . . . . . . . . . . . . . 9 88 4.2. Mistrust between entities . . . . . . . . . . . . . . . . 9 89 4.3. Bidirectional Network/Application collaboration . . . . . 9 90 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 94 7.2. Informative References . . . . . . . . . . . . . . . . . 10 95 Appendix A. Questionnaire . . . . . . . . . . . . . . . . . . . 10 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 98 1. Introduction 100 1.1. ALTO Background 102 The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] 103 is a client/server protocol operating between an ALTO client and an 104 ALTO server. An ALTO server provides network related information to 105 ALTO clients so that ALTO clients can make better decisions. ALTO is 106 initially proposed to help distributed applications (P2P and client/ 107 server used for file sharing, real-time communication, etc.) to 108 choose a better resource from multiple replicas. Recently, as new 109 use cases like Content Delivery Network (CDN), Software-Define 110 Network (SDN) and Datacenter Network (DCN) in single and multi domain 111 environments emerge to utilize ALTO, they will bring forth new 112 requirements and challenges on ALTO protocol. 114 1.2. Goals and Scope 116 This document aims to provide a comprehensive survey of ALTO, it 117 covers: 1) ALTO implementations in different companies/institutions; 118 2) Application scenarios of ALTO in literature work through a lot of 119 paper reading. With the survey of above topics, we want to explore: 120 1) The system architecture of ALTO implementation and possible issues 121 in realizing the system; 2) Current use cases and future uses cases 122 of ALTO; 3) Possible ALTO extensions to support future use cases. 124 1.3. Document Organization 126 The document is organized as below: 128 In Section 2, we present the survey of ALTO implementation and its 129 results. In Section 3, we collect ALTO use cases in literature work 130 and classified them based on ??? criteria. Finally, based on the 131 ALTO use cases in literature work, we will show possible ALTO 132 extensions and research opportunities of ALTO in Section 4. 134 2. ALTO Implementations 136 2.1. Services Implemented in Projects 138 Abbreviations: 140 o NM: network map 141 o CM: cost map 143 o FM: filtered map 145 o MC: multi-cost 147 o CC: cost calendar 149 o PV: path vector 151 o SDMN: software defined mobile networks 153 2.2. ALTO in Software Defined Mobile Networks 155 ALTO in software defined mobile networks (SDMN) project is a sub- 156 project of Celtic-Plus SIGMONA, and it is implemented by Budapest 157 University of Technology and Economics. 159 As the elasticity and portability of network functions becomes 160 reality, the significance of service endpoint selection increases. 161 ALTO is a standard protocol, which can provide guidance in service 162 endpoint selection. So ALTO is very suitable for this case. 164 This project has implemented network map and cost map, and it 165 introduced two new interfaces namely ALTO client-to-redirect server 166 interface and ALTO network-to-server interface. 168 For cost calculation, this project regarded the number of switches 169 between end hosts as "num-routing" and the average utilization of the 170 path in the last 5 seconds as "num-delay". 172 The ALTO server in this project is standalone, and the ALTO client in 173 this project is embedded into a SDN controller. 175 2.3. Recognized Issues and Future Work 177 Extension of dynamic network and cost map information provision: 179 o From non-SDN network segments 181 o From multiple network controllers (merging information in ALTO 182 server) 184 ALTO protocol applies abstract network and cost maps: 186 o Pros: privacy of topology information 188 o Cons: sometimes not enough fine grained 189 o Rank aggregation: which method should we select 191 o Support of non reactive packet forwarding methods 193 3. ALTO in Literature/Use Cases 195 We make a comprehensive survey of ALTO used in literature work. We 196 collect *** ALTO related papers, study the use cases and we have make 197 an initial classification of use cases. The taxonomy of all the use 198 cases is below. 200 Application-Layer Traffic Optimization 201 | 202 +---> Peer Selection 203 | | 204 | +---> Peer Selection in P2P 205 | | 206 | +---> Surrogate Selection in CDN 207 | | 208 | +---> Cache Selection in Hybrid CDN-P2P System 209 | | 210 | +---> Mobile Edge Caching 211 | 212 +---> Path Selection 213 | | 214 | +---> Path Selection in MPTS-AR 215 | 216 +---> Content Placement 217 | | 218 | +---> Virtualized Service Function Chain Placement 219 | | 220 | +---> Intelligent Virtual Machine Placement 221 | | 222 | +---> Service Placement in IoT 223 | 224 +---> Measurement 226 Figure 1: Taxonomy of ALTO Literature: Version A 228 the use cases are already mentioned in [RFC7971]. In the following 229 sections, we will describe each use cases one by one. Some of the 230 use cases are already mentioned in [RFC7971]. We classified all the 231 related work into 4 categories and will describe each in the 232 following. 234 3.1. Peer Selection 236 3.1.1. Peer Selection in P2P 238 3.1.1.1. Usage Scenario 240 Without little knowledge of the underlying network informtion, users 241 in P2P system retrieve data from a random peer. Such a random peer 242 selection mechanism have some disadvantages: 1. It causes an extra 243 burden in the internet traffic. 2. It reduces the system 244 performance. 246 3.1.2. Surrogate Selection in CDN 248 Content Delivery Networks (CDNs) have been used to deliver some 249 Internet services such as video stream, websites or software updates 250 because they provide numerous benefits including reduced delivery 251 cost for cacheable content, improved QoS for end users and increased 252 robustness of delivery. 254 The primary use case for ALTO in a CDN context is to improve the 255 selection of a surrogate, cache or origin. By providing cost maps 256 and network maps, ALTO can help a CDN to optimize selection of its 257 surrogate, cache or origin. 259 3.1.3. Downstream CDN Selection in CDNI 261 Above section mainly talks about the surrogate selection in the CDN 262 from a single administrative domain. However, some CDNs from 263 different administrative domains may collaborate together to provide 264 a broader coverage area. In such case, an upstream CDN needs to 265 select the best downstream CDN For each content request it intends to 266 redirect. 268 There are two tasks need to be done when an upstream CDN selects a 269 downstream CDN. The first one is which dCDN is willing to accept a 270 delegated request, and the second one is which dCDN is the most 271 proper for redirecting the content request. For the first task, ALTO 272 CDNI FCI Map can be used by uCDN to actively or passively gather 273 dCDNs information such as footprints. For the second task, ALTO cost 274 map can be used by uCDN to select the best surrogate with the 275 smallest cost. 277 3.1.4. Cache Selection in Hybrid CDN-P2P System 279 Hybrid CDN-P2P system propose a two-tier topologies. The first level 280 (CDN-L1) is composed by high capacity servers strategically placed in 281 order to increase network backbone capacity. A second level (CDN-L0) 282 consists of Level-0 Entry Point (L0-EP). These node are equipped 283 with some caching functionalities and placed geographically closer to 284 end users. The L0-EP includes a standard HTTP proxy frontend used to 285 optimally redirect the HTTP GET requests of the users to the best 286 content location in CDN-L0 or CDN-L1. The decision logic module 287 residing in L0-EP considers 3 factors (the availability of the 288 content in the L0-EP local cache, the list of cache nodes that can 289 contribute to retrieve the content and the locality awareness) to 290 make its final decision. 292 The locality information here is provided through ALTO interface from 293 the network monitors. 295 3.1.5. Mobile Edge Caching 297 3.1.5.1. Usage Scenario 299 Mobile Edge Caching is regarded to be possible to reduce the latency 300 for users to retrieve content, thus improving the perveived Quality 301 of Experience. The main technique in mobile edge caching is to equip 302 edge network elements with cache capabilities. Popular contents can 303 be stored at several caching servers at edge. 305 3.1.5.2. Applicability of ALTO 307 In the context of mobile edge caching, the information that a User 308 Equipment (UE) tries to access, such as a document or a video, is 309 referred to a s a Named Data Object (NDO). [MEC] proposes that ALTO 310 can perform like a DNS server. It can be used to discover the 311 caching servers that host the desired resource . To leverage ALTO for 312 resource discovery, ALTO will regard each resource a PID. The IP 313 addresses that a PID contains are the caching servers holding 314 specific NDO. As response to the ALTO query, ALTO server will return 315 a network map with a list of PIDs, each with IP addresses of cache 316 servers. Such discovery mechanism allows the operator to inform the 317 UE about all the cache servers that contain the required NDO in 318 single operation. Second, the UE can use additional ALTO features 319 (such as cost maps) to inquire which cache-server is preferred in 320 terms of data routing costs (i.e., availble bandwidth, network load 321 and others). 323 3.2. Path Selection 325 3.2.1. Path Selection in MPTS-AR 326 3.3. Resource Placement 328 3.3.1. Virtualized Service Function Chain Placement 330 3.3.2. Intelligent Virtual Machine Placement 332 3.3.2.1. Usage Scenario 334 The cloud management system can optimize resource placement by taking 335 into account the network performance as well as the compute and 336 storage resources. 338 3.3.2.2. Applicability of ALTO 340 3.3.2.3. Challenges and Opportunities 342 3.3.3. Service Placement in IoT 344 3.3.3.1. Usage Scenario 346 With the cutting-edge paradigms like Internet of Things and Smart 347 Cities develop, new services have special requirements, one of which 348 is low latency levels. A delayed reply could render to chaos for 349 applications such as eHealth and public safety. One of the solutions 350 is a smart service placement system that facilitates the location of 351 services in the proper position according to specific needs. 352 Locating the services just on wireless hop away from the users is not 353 as simple as it sounds, since the service could be wrongfully placed 354 in a congested location, or even farther from the users, which would 355 lead to a greater latency. Thus, efficient service placement 356 mechanisms are needed in order to take advantage of the current 357 conditions of the network while minimizing the service latency. 359 3.3.3.2. Applicability of ALTO 361 3.3.3.3. Challenges of ALTO/ Opportunities of ALTO 363 3.4. Measure Results Interface 365 3.4.1. An Interface to Query on the LMAP measure results 367 In the context of LMAP, measurement results are made available to the 368 public either at the finest granularity level, or in a very high 369 level human-readable format. ALTO can provide an intermediate way to 370 access large-scale network measurement result, and it can be used to 371 tweak the aggregation-level of measurement results. 373 Controller sends instructions to measurement agent to do the 374 measurement. And then measurement result will be transferred to the 375 collector by report protocol. Just providing finest granularity 376 level or providing a very high level human-readable format are not 377 enough. ALTO can provide an intermediate way to access large-scale 378 network measurement result, and it can be used to tweak the 379 aggregation-level of measurement results. 381 4. Challenges and Research Opportunities 383 4.1. Possible New Address Format 385 Some scenarios may require new address format. 387 4.2. Mistrust between entities 389 Application developers and network operators are natural mistrust, 390 with both parties reluctant to share what they consider sensitive 391 information. 393 4.3. Bidirectional Network/Application collaboration 395 ALTO is originally designed to provide network information to 396 applications so that applications can achieve better performance 397 while the cost of the network can be reduced. Exposing non-critical 398 information from application providers to network providers may 399 potentially bring more benefits. A paper named "Bidirectional 400 Network Collaboration Interface for CDNs and Clouds Services Traffic 401 Optimization" describes this idea, and it proposes the constraint map 402 which provides application needs and constraints to network 403 providers. 405 5. Acknowledgments 407 ... 409 6. Security Considerations 411 This draft is a survey of existing literature on ALTO implementations 412 and use cases, it does not introduce any new security considerations 413 to be taken into account beyond what is already discussed in each 414 paper surveyed. 416 7. References 417 7.1. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, . 424 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 425 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 426 "Application-Layer Traffic Optimization (ALTO) Protocol", 427 RFC 7285, DOI 10.17487/RFC7285, September 2014, 428 . 430 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 431 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 432 Deployment Considerations", RFC 7971, 433 DOI 10.17487/RFC7971, October 2016, . 436 7.2. Informative References 438 [MEC] Poderys, Justas. and Matteo. Artuso, "Caching at the 439 Mobile Edge: A Practical Implementation", 2018. 441 [SDN] Diego, Kreutz. and Ramos. Fernando MV, "Software-defined 442 networking: A comprehensive survey", 2015. 444 [VPN] Scharf, Michael., "Dynamic VPN Optimization by ALTO 445 Guidance", 2013. 447 Appendix A. Questionnaire 448 Company/Organization Name: 449 Project Name: 450 Motivation: 451 System Architecture: 452 What map services that you have implemented: 453 Map Service 454 | 455 +---> Cost Map 456 | 457 +---> Network Map 458 Map Filtering Service 459 Endpoint Cost Service 460 Endpoint Property Service 461 Unified Property Service 462 Multi-cost 463 Cost Calendar 464 Path Vector 466 Four Entites in ALTO Implementation 467 | 468 +---> Source of network informaton 469 | 470 +---> ALTO Server 471 | | 472 | +---> Who oeperates the ALTO server? 473 | | | 474 | | +---> network operator 475 | | | 476 | | +---> third parties 477 | | | 478 | | +---> user communities 479 | | 480 | +---> How ALTO server groups endpoints (PID) 481 | | 482 | +---> How ALTO server calculates costs 483 | 484 +---> ALTO client 485 | | 486 | +---> network management entity 487 | | 488 | +---> peer (endpoint) entity 489 | 490 +---> Information Consumer 492 Main Benefits of Using ALTO (System and Service Performance) 494 Recognized Issues 496 Authors' Addresses 498 Shiwei Dawn Chen 499 Tongji University 500 4800 Cao'an Road 501 Shanghai 201804 502 China 504 Email: dawn_chen_f@hotmail.com 506 X.S. Lin 507 Tongji University 508 4800 Cao'an Road 509 Shanghai 201804 510 China 512 Email: x.shawn.lin@gmail.com 514 Danny Alex Lachos Perez 515 University of Campinas 516 Av. Albert Einstein 400 517 Campinas, Sao Paulo 13083-970 518 Brazil 520 Email: dlachosp@dca.fee.unicamp.br 521 URI: https://intrig.dca.fee.unicamp.br/danny-lachos/ 523 Y. Richard Yang 524 Tongji/Yale University 525 51 Prospect Street 526 New Haven, CT 06511 527 USA 529 Email: yry@cs.yale.edu 531 Christian Esteve Rothenberg 532 University of Campinas 533 Av. Albert Einstein 400 534 Campinas, Sao Paulo 13083-970 535 Brazil 537 Email: chesteve@dca.fee.unicamp.br 538 URI: https://intrig.dca.fee.unicamp.br/christian/