Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7971

Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Pages: 77
Informational
Part 1 of 4 – Pages 1 to 14
None   None   Next

Top   ToC   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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   RFC7971 - 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 page on part 2)

Next Section