Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7971

Informational
Pages: 77
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ALTO

Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Part 1 of 4, p. 1 to 14
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                    M. Stiemerling
Request for Comments: 7971                          Hochschule Darmstadt
Category: Informational                                        S. Kiesel
ISSN: 2070-1721                                  University of Stuttgart
                                                               M. Scharf
                                                                   Nokia
                                                               H. Seidel
                                                                  BENOCS
                                                              S. Previdi
                                                                   Cisco
                                                            October 2016


Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Abstract

   Many Internet applications are used to access resources such as
   pieces of information or server processes that are available in
   several equivalent replicas on different hosts.  This includes, but
   is not limited to, peer-to-peer file sharing applications.  The goal
   of Application-Layer Traffic Optimization (ALTO) is to provide
   guidance to applications that have to select one or several hosts
   from a set of candidates capable of providing a desired resource.
   This memo discusses deployment-related issues of ALTO.  It addresses
   different use cases of ALTO such as peer-to-peer file sharing and
   Content Delivery Networks (CDNs) and presents corresponding examples.
   The document also includes recommendations for network administrators
   and application designers planning to deploy ALTO, such as
   recommendations on how to generate ALTO map information.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7971.

Top      ToC       Page 2 
Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................4
   2. General Considerations ..........................................4
      2.1. ALTO Entities ..............................................4
           2.1.1. Baseline Scenario ...................................4
           2.1.2. Placement of ALTO Entities ..........................6
      2.2. Classification of Deployment Scenarios .....................8
           2.2.1. Roles in ALTO Deployments ...........................8
           2.2.2. Information Exposure ...............................11
           2.2.3. More-Advanced Deployments ..........................12
   3. Deployment Considerations by ISPs ..............................15
      3.1. Objectives for the Guidance to Applications ...............15
           3.1.1. General Objectives for Traffic Optimization ........15
           3.1.2. Inter-Network Traffic Localization .................16
           3.1.3. Intra-Network Traffic Localization .................17
           3.1.4. Network Offloading .................................18
           3.1.5. Application Tuning .................................19
      3.2. Provisioning of ALTO Topology Data ........................20
           3.2.1. High-Level Process and Requirements ................20
           3.2.2. Data Collection from Data Sources ..................21
           3.2.3. Partitioning and Grouping of IP Address Ranges .....24
           3.2.4. Rating Criteria and/or Cost Calculation ............25
      3.3. ALTO Focus and Scope ......................................29
           3.3.1. Limitations of Using ALTO beyond Design
                  Assumptions ........................................29
           3.3.2. Limitations of Map-Based Services and
                  Potential Solutions ................................30
           3.3.3. Limitations of Non-Map-Based Services and
                  Potential Solutions ................................32
      3.4. Monitoring ALTO ...........................................33
           3.4.1. Impact and Observation on Network Operation ........33
           3.4.2. Measurement of the Impact ..........................33

Top      ToC       Page 3 
           3.4.3. System and Service Performance .....................34
           3.4.4. Monitoring Infrastructures .........................35
      3.5. Abstract Map Examples for Different Types of ISPs .........36
           3.5.1. Small ISP with Single Internet Uplink ..............36
           3.5.2. ISP with Several Fixed-Access Networks .............39
           3.5.3. ISP with Fixed and Mobile Network ..................40
      3.6. Comprehensive Example for Map Calculation .................42
           3.6.1. Example Network ....................................42
           3.6.2. Potential Input Data Processing and Storage ........44
           3.6.3. Calculation of Network Map from the Input Data .....47
           3.6.4. Calculation of Cost Map ............................49
      3.7. Deployment Experiences ....................................50
   4. Using ALTO for P2P Traffic Optimization ........................52
      4.1. Overview ..................................................52
           4.1.1. Usage Scenario .....................................52
           4.1.2. Applicability of ALTO ..............................53
      4.2. Deployment Recommendations ................................55
           4.2.1. ALTO Services ......................................55
           4.2.2. Guidance Considerations ............................56
   5. Using ALTO for CDNs ............................................58
      5.1. Overview ..................................................58
           5.1.1. Usage Scenario .....................................58
           5.1.2. Applicability of ALTO ..............................60
      5.2. Deployment Recommendations ................................62
           5.2.1. ALTO Services ......................................62
           5.2.2. Guidance Considerations ............................63
   6. Other Use Cases ................................................64
      6.1. Application Guidance in Virtual Private Networks (VPNs) ...64
      6.2. In-Network Caching ........................................66
      6.3. Other Application-Based Network Operations ................68
   7. Security Considerations ........................................68
      7.1. ALTO as a Protocol Crossing Trust Boundaries ..............68
      7.2. Information Leakage from the ALTO Server ..................69
      7.3. ALTO Server Access ........................................70
      7.4. Faking ALTO Guidance ......................................71
   8. References .....................................................72
      8.1. Normative References ......................................72
      8.2. Informative References ....................................73
   Acknowledgments ...................................................76
   Authors' Addresses ................................................77

Top      ToC       Page 4 
1.  Introduction

   Many Internet applications are used to access resources such as
   pieces of information or server processes that are available in
   several equivalent replicas on different hosts.  This includes, but
   is not limited to, peer-to-peer (P2P) file sharing applications and
   Content Delivery Networks (CDNs).  The goal of Application-Layer
   Traffic Optimization (ALTO) is to provide guidance to applications
   that have to select one or several hosts from a set of candidates
   capable of providing a desired resource.  The basic ideas and problem
   space of ALTO is described in [RFC5693] and the set of requirements
   is discussed in [RFC6708].  The ALTO protocol is specified in
   [RFC7285].  An ALTO server discovery procedure is defined in
   [RFC7286].

   This document discusses use cases and operational issues that can be
   expected when ALTO gets deployed.  This includes, but is not limited
   to, location of the ALTO server, imposed load to the ALTO server, and
   who initiates the queries.  This document provides guidance on which
   ALTO services to use, and it summarizes known challenges as well as
   deployment experiences, including potential processes to generate
   ALTO network and cost maps.  It thereby complements the management
   considerations in the protocol specification [RFC7285], which are
   independent of any specific use of ALTO.

2.  General Considerations

2.1.  ALTO Entities

2.1.1.  Baseline Scenario

   The ALTO protocol [RFC7285] is a client/server protocol, operating
   between a number of ALTO clients and an ALTO server, as sketched in
   Figure 1.  Below, the baseline deployment scenario for ALTO entities
   is first reviewed independently of the actual use case.  Specific
   examples are then discussed in the remainder of this document.

Top      ToC       Page 5 
                 +----------+
                 |  ALTO    |
                 |  Server  |
                 +----------+
                       ^
                _.-----|------.
            ,-''       |       `--.
          ,'           |           `.
         (     Network |             )
          `.           |           ,'
            `--.       |       _.-'
                `------|-----''
                       v
    +----------+  +----------+   +----------+
    |  ALTO    |  |  ALTO    |...|  ALTO    |
    |  Client  |  |  Client  |   |  Client  |
    +----------+  +----------+   +----------+

   Figure 1: Baseline Deployment Scenario of the ALTO Protocol

   This document uses the terminology introduced in [RFC5693].  In
   particular, the following terms are defined by [RFC5693]:

   o  ALTO Service: Several resource providers may be able to provide
      the same resource.  The ALTO service gives guidance to a resource
      consumer and/or resource directory about which resource
      provider(s) to select in order to optimize the client's
      performance or quality of experience, while improving resource
      consumption in the underlying network infrastructure.

   o  ALTO Server: A logical entity that provides interfaces to satisfy
      the queries about a particular ALTO service.

   o  ALTO Client: The logical entity that sends ALTO queries.
      Depending on the architecture of the application, one may embed it
      in the resource consumer and/or in the resource directory.

   o  Resource Consumer: For P2P applications, a resource consumer is a
      specific peer that needs to access resources.  For client-server
      or hybrid applications, a consumer is a client that needs to
      access resources.

   o  Resource Directory: An entity that is logically separate from the
      resource consumer and that assists the resource consumer to
      identify a set of resource providers.  Some P2P applications refer
      to the resource directory as a P2P tracker.

Top      ToC       Page 6 
   We differentiate between an ALTO Client and a Resource Consumer as
   follows: the resource consumer is specific instance of a software
   ("process") running on a specific host.  It is a client instance of a
   client/server application or a peer of a peer-to-peer application.
   It is the given (constant) endpoint of the data transmissions to be
   optimized using ALTO.  The optimization is done by wisely choosing
   the other ends of these data flows (i.e., the server(s) in a client/
   server application or the peers in a peer-to-peer application), using
   guidance from ALTO and possibly other information.  An ALTO client is
   a piece of software (e.g., a software library) that implements the
   client entity of the ALTO protocol as specified in [RFC7285].  It
   consists of data structures that are suitable for representing ALTO
   queries, replies, network and cost maps, etc.  Furthermore, it has to
   implement an HTTP client and a JSON encoder/decoder, or it has to
   include other software libraries that provide these building blocks.
   In the simplest case, this ALTO client library can be linked (or
   otherwise incorporated) into the resource consumer, in order to
   retrieve information from an ALTO server and thereby satisfy the
   resource consumer's need for guidance.  However, other configurations
   are possible as well, as discussed in Section 2.1.2 and other
   sections of this document.

   According to these definitions, both an ALTO server and an ALTO
   client are logical entities.  A particular ALTO service may be
   offered by more than one ALTO server.  In ALTO deployments, the
   functionality of an ALTO server can therefore be realized by several
   server instances, e.g., by using load balancing between different
   physical servers.  The term ALTO server should not be confused with
   use of a single physical server.

   This document uses the term "Resource Directory" as defined in
   [RFC5693].  This term and its meaning is not to be confused with the
   "Information Resource Directory (IRD)" defined as a part of the ALTO
   protocol [RFC7285], i.e., a list of available information resources
   offered by a specific ALTO service and the URIs at which each can be
   accessed.

2.1.2.  Placement of ALTO Entities

   The ALTO server and ALTO clients may be situated at various places in
   a network topology.  An important differentiation is whether the ALTO
   client is located on the host that is the endpoint of the data
   transmissions to be optimized with ALTO (see Figure 2) or whether the
   ALTO client is located on a resource directory, which assists peers
   or clients in finding other peers or servers, respectively, but does
   not directly take part in the data transmission (see Figure 3).

Top      ToC       Page 7 
                                              +--------------+
                                              |     App      |
                                              +-----------+  |
                                          ===>|ALTO Client|  |****
                                       ===    +-----------+--+   *
                                    ===                    *     *
                                 ===                       *     *
      +-------+     +-------+<===             +--------------+   *
      |       |     |       |                 |     App      |   *
      |       |.....|       |<========        +-----------+  |   *
      |       |     |       |        ========>|ALTO Client|  |   *
      +-------+     +-------+<===             +-----------+--+   *
      Source of       ALTO       ==                        *     *
      topological    Server        ==                      *     *
      information                    ==       +--------------+   *
                                       ==     |     App      |   *
                                         ==   +-----------+  |****
                                           ==>|ALTO Client|  |
                                              +-----------+--+
                                                Application
      Legend:
      === ALTO protocol
      *** Application protocol
      ... Provisioning protocol

     Figure 2: Overview of Protocol Interaction between ALTO Elements
                       without a Resource Directory

   Figure 2 shows the operational model for an ALTO client running at
   endpoints.  An example would be a peer-to-peer file sharing
   application that does not use a tracker, such as edonkey.  In
   addition, ALTO clients at peers could also be used in a similar way
   even if there is a tracker, as further discussed in Section 4.1.2.

Top      ToC       Page 8 
                                                       +-----+
                                                     **| App |****
                                                   **  +-----+   *
                                                 **       *      *
                                               **         *      *
      +-------+     +-------+     +--------------+        *      *
      |       |     |       |     |              |     +-----+   *
      |       |.....|       |     +-----------+  |*****| App |   *
      |       |     |       |<===>|ALTO Client|  |     +-----+   *
      +-------+     +-------+     +-----------+--+        *      *
      Source of       ALTO          Resource   **         *      *
      topological    Server         directory    **       *      *
      information                                  **  +-----+   *
                                                     **| App |****
                                                       +-----+
                                                     Application
      Legend:
      === ALTO protocol
      *** Application protocol
      ... Provisioning protocol

            Figure 3: Overview of Protocol Interaction between
                  ALTO Elements with a Resource Directory

   In Figure 3, a use case with a resource directory is illustrated,
   e.g., a tracker in a peer-to-peer file-sharing application such as
   BitTorrent.  Both deployment scenarios may differ in the number of
   ALTO clients that access an ALTO service.  If an ALTO client is
   implemented in a resource directory, an ALTO server may be accessed
   by a limited and less dynamic set of clients, whereas in the general
   case any host could be an ALTO client.  This use case is further
   detailed in Section 4.

   Using ALTO in CDNs may be similar to a resource directory [CDN-USE].
   The ALTO server can also be queried by CDN entities to get guidance
   about where a particular client accessing data in the CDN is located
   in the Internet Service Provider's network, as discussed in
   Section 5.

2.2.  Classification of Deployment Scenarios

2.2.1.  Roles in ALTO Deployments

   ALTO is a general-purpose protocol and it is intended to be used by a
   wide range of applications.  In different use cases, applications,
   resource directories, etc., can correspond to different
   functionality.  The use cases listed in this document are not meant
   to be comprehensive.  This also implies that there are different

Top      ToC       Page 9 
   possibilities where the ALTO entities are actually located, i.e., if
   the ALTO clients and the ALTO server are in the same Internet Service
   Provider (ISP) domain, or if the clients and the ALTO server are
   managed/owned/located in different domains.

   An ALTO deployment involves four kinds of entities:

   1.  Source of topological information

   2.  ALTO server

   3.  ALTO client

   4.  Resource consumer

   Each of these entities corresponds to a certain role, which results
   in requirements and constraints on the interaction between the
   entities.

   A key design objective of the ALTO service is that each of these four
   roles can be separated, i.e., they can be realized by different
   organizations or disjoint system components.  ALTO is inherently
   designed for use in multi-domain environments.  Most importantly,
   ALTO is designed to enable deployments in which the ALTO server and
   the ALTO client are not located within the same administrative
   domain.

   As explained in [RFC5693], from this follows that at least three
   different kinds of entities can operate an ALTO server:

   1.  Network operators.  Network Service Providers (NSPs) such as ISPs
       may have detailed knowledge of their network topology and
       policies.  In this case, the source of the topology information
       and the provider of the ALTO server may be part of the same
       organization.

   2.  Third parties.  Topology information could also be collected by
       companies or organizations that are distinct from the network
       operators, yet have arranged certain legal agreements with one or
       more network operators, regarding access to their topology
       information and/or doing measurements in their networks.
       Examples of such entities could be CDN operators or companies
       specialized in offering ALTO services on behalf of ISPs.

   3.  User communities.  User communities could run distributed
       measurements for estimating the topology of the Internet.  In
       this case, the topology information may not originate from ISP
       data.

Top      ToC       Page 10 
   Regarding the interaction between ALTO server and client, ALTO
   deployments can be differentiated according to the following aspects:

   1.  Applicable trust model: The deployment of ALTO can differ
       depending on whether or not the ALTO client and ALTO server are
       operated within the same organization and/or network.  This
       affects a number of constraints because the trust model is very
       different.  For instance, as discussed later in this memo, the
       level of detail of maps can depend on who the involved parties
       actually are.

   2.  Composition of the user group: The main use case of ALTO is to
       provide guidance to any Internet application.  However, an
       operator of an ALTO server could also decide to offer guidance
       only to a set of well-known ALTO clients, e.g., after
       authentication and authorization.  In the peer-to-peer
       application use case, this could imply that only selected
       trackers are allowed to access the ALTO server.  The security
       implications of using ALTO in closed groups differ from the
       public Internet.

   3.  Covered destinations: In general, an ALTO server has to be able
       to provide guidance for all potential destinations.  Yet, in
       practice, a given ALTO client may only be interested in a subset
       of destinations, e.g., only in the network cost between a limited
       set of resource providers.  For instance, CDN optimization may
       not need the full ALTO cost maps because traffic between
       individual residential users is not in scope.  This may imply
       that an ALTO server only has to provide the costs that matter for
       a given user, e.g., by customized maps.

   The following sections enumerate different classes of use cases for
   ALTO, and they discuss deployment implications of each of them.  In
   principle, an ALTO server can be operated by any organization, and
   there is no requirement that an ALTO server be deployed and operated
   by an ISP.  Yet, since the ALTO solution is designed for ISPs, most
   examples in this document assume that the operator of an ALTO server
   is a network operator (e.g., an ISP or the network department in a
   large enterprise) that offers ALTO guidance in particular to users of
   this network.

   It must be emphasized that any application using ALTO must also work
   if no ALTO servers can be found or if no responses to ALTO queries
   are received, e.g., due to connectivity problems or overload
   situations (see also [RFC6708]).

Top      ToC       Page 11 
2.2.2.  Information Exposure

   There are basically two different approaches to how an ALTO server
   can provide network information and guidance:

   1.  The ALTO server provides maps that contain provider-defined cost
       values between network location groupings (e.g., sets of IP
       prefixes).  These maps can be retrieved by clients via the ALTO
       protocol, and the actual processing of the map data is done
       inside the client.  Since the maps contain (aggregated) cost
       information for all endpoints, the client does not have to reveal
       any internal operational data, such as the IP addresses of
       candidate resource providers.  The ALTO protocol supports this
       mode of operation by the Network and Cost Map Service.

   2.  The ALTO server provides a query interface that returns costs or
       rankings for explicitly specified endpoints.  This means that the
       query of the ALTO client has to include additional information
       (e.g., a list of IP addresses).  The server then calculates and
       returns costs or rankings for the endpoints specified in the
       request (e.g., a sorted list of the IP addresses).  In ALTO, this
       approach can be realized by the Endpoint Cost Service (ECS) and
       other related services.

   Both approaches have different privacy implications for the server
   and client:

   For the client, approach 1 has the advantage that all operational
   information stays within the client and is not revealed to the
   provider of the server.  However, this service implies that a network
   operator providing an ALTO server has to expose a certain amount of
   information about its network structure (e.g., IP prefixes or
   topology information in general).

   For the operator of a server, approach 2 has the advantage that the
   query responses reveal less topology information to ALTO clients.
   However, it should be noted that collaborating ALTO clients could
   gather more information than expected by aggregating and correlating
   responses to multiple queries sent to the ALTO server (see
   Section 5.2.1, item (3) of [RFC6708]).  Furthermore, this method
   requires that clients send internal operational information to the
   server, such as the IP addresses of hosts also running the
   application.  For clients, such data can be sensitive.

   As a result, both approaches have their pros and cons, as further
   detailed in Section 3.3.

Top      ToC       Page 12 
2.2.3.  More-Advanced Deployments

   From an ALTO client's perspective, there are different ways to use
   ALTO:

   1.  Single-service instance with single-metric guidance: An ALTO
       client only obtains guidance regarding a single metric (e.g.,
       "routingcost") from a single ALTO service, e.g., an ALTO server
       that is offered by the network service provider of the
       corresponding access network.  Corresponding ALTO server
       instances can be discovered, e.g., by ALTO server discovery
       [RFC7286] [XDOM-DISC].  Since the ALTO protocol is an HTTP-based,
       REST-ful (Representational State Transfer) protocol, the operator
       of an ALTO may use well-known techniques for serving large web
       sites, such as load balancers, in order to serve a large number
       of ALTO queries.  The ALTO protocol also supports the use of
       different URIs for different ALTO features and thereby the
       distribution of the service onto several servers.

   2.  Single service instance with multiple metric guidance: An ALTO
       client could also query an ALTO service for different kinds of
       information, e.g., cost maps with different metrics.  The ALTO
       protocol is extensible and permits such operation.  However, ALTO
       does not define how a client shall deal with different forms of
       guidance, and it is up to the client to interpret the received
       information accordingly.

   3.  Multiple service instances: An ALTO client can also decide to
       access multiple ALTO servers providing guidance, possibly from
       different operators or organizations.  Each of these services may
       only offer partial guidance, e.g., for a certain network
       partition.  In that case, it may be difficult for an ALTO client
       to compare the guidance from different services.  Different
       organization may use different methods to determine maps, and
       they may also have different (possibly even contradicting or
       competing) guidance objectives.  How to discover multiple ALTO
       servers and how to deal with conflicting guidance is an open
       issue.

   There are also different options regarding the synchronization of
   guidance offered by an ALTO service:

   1.  Authoritative servers: An ALTO server instance can provide
       guidance for all destinations for all kinds of ALTO clients.

Top      ToC       Page 13 
   2.  Cascaded servers: An ALTO server may itself include an ALTO
       client and query other ALTO servers, e.g., for certain
       destinations.  This results is a cascaded deployment of ALTO
       servers, as further explained below.

   3.  Inter-server synchronization: Different ALTO servers may
       communicate by other means.  This approach is not further
       discussed in this document.

   An assumption of the ALTO design is that ISPs operate ALTO servers
   independently, irrespective of other ISPs.  This may be true for most
   envisioned deployments of ALTO, but there may be certain deployments
   that may have different settings.  Figure 4 shows such a setting with
   a university network that is connected to two upstream providers.
   NREN is a National Research and Education Network, which provides
   cheap high-speed connectivity to specific destinations, e.g., other
   universities.  ISP is a commercial upstream provider from which the
   university buys connectivity to all destinations that cannot be
   reached via the NREN.  The university, as well as ISP, are operating
   their own ALTO server.  The ALTO clients, located on the peers in the
   university network will contact the ALTO server located at the
   university.

Top      ToC       Page 14 
          +-----------+
          |    ISP    |
          |   ALTO    |<==========================++
          |  Server   |                           ||
          +-----------+                           ||
            ,-------.            ,------.         ||
         ,-'         `-.      ,-'         `-.     ||
        /   Commercial  \    /               \    ||
       (    Upstream     )  (       NREN      )   ||
        \   ISP         /    \               /    ||
         `-.         ,-'      `-.         ,-'     ||
            `---+---'            `+------'        ||
                |                 |               ||
                |                 |               ||
                |,-------------.  |               \/
              ,-+               `-+          +-----------+
            ,'      University     `.        |University |
           (        Network          )       |   ALTO    |
            `.                      /        |  Server   |
              `-.               +--'         +-----------+
                 `+------------'|              /\     /\
                  |             |              ||     ||
         +--------+-+         +-+--------+     ||     ||
         |   Peer1  |         |   PeerN  |<====++     ||
         +----------+         +----------+            ||
              /\                                      ||
              ||                                      ||
              ++======================================++

      Legend:
      === ALTO protocol

                Figure 4: Example of a Cascaded ALTO Server

   In this setting, all destinations that can be reached via the NREN
   are preferred in the rating of the university's ALTO server.  In
   contrast, all traffic that is not routed via the NREN will be handled
   by the commercial upstream ISP and is in general less preferred due
   to the associated costs.  Yet, there may be significant differences
   between various destinations reached via the ISP.  Therefore, the
   ALTO server at the university may also include the guidance given by
   the ISP ALTO server in its replies to the ALTO clients.  This is an
   example for cascaded ALTO servers.


Next Section