RFC 7971
Application-Layer Traffic Optimization (ALTO) Deployment Considerations
Pages: 77
Informational
Informational
Part 1 of 4 – Pages 1 to 14
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 ConsiderationsAbstract
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.
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
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
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.
+----------+ | 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.
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).
+--------------+ | 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.
+-----+ **| 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
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.
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]).
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.
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.
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.
+-----------+ | 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)