ALTO M. Stiemerling, Ed.
Internet-Draft NEC Europe Ltd.
Intended status: Informational S. Kiesel, Ed.
Expires: April 24, 2014 University of Stuttgart
S. Previdi
Cisco
M. Scharf
Alcatel-Lucent Bell Labs
October 21, 2013
ALTO Deployment Considerations
draft-ietf-alto-deployments-08
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, which are able to provide 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 CDNs, security considerations, recommendations for
network administrators, and also guidance for application designers
using ALTO.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Stiemerling, et al. Expires April 24, 2014 [Page 1]
Internet-Draft Deployment Considerations October 2013
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Considerations . . . . . . . . . . . . . . . . . . . 4
2.1. ALTO Entities . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Baseline Scenario . . . . . . . . . . . . . . . . . . 4
2.1.2. Placement of ALTO Entities . . . . . . . . . . . . . 4
2.2. Classification of Deployment Scenarios . . . . . . . . . 6
2.2.1. Deployment Degrees of Freedom . . . . . . . . . . . . 6
2.2.2. Information Exposure Models . . . . . . . . . . . . . 7
2.2.3. More Advanced Deployments . . . . . . . . . . . . . . 7
3. Deployment Considerations by ISPs . . . . . . . . . . . . . . 9
3.1. Objectives for the Guidance to Applications . . . . . . . 9
3.1.1. General Objectives for Traffic Optimization . . . . . 9
3.1.2. Inter-Network Traffic Localization . . . . . . . . . 10
3.1.3. Intra-Network Traffic Localization . . . . . . . . . 11
3.1.4. Network Off-Loading . . . . . . . . . . . . . . . . . 13
3.1.5. Application Tuning . . . . . . . . . . . . . . . . . 14
3.2. Provisioning of ALTO Maps . . . . . . . . . . . . . . . . 14
3.2.1. Data Sources . . . . . . . . . . . . . . . . . . . . 14
3.2.2. Privacy Requirements . . . . . . . . . . . . . . . . 14
3.2.3. Map Partitioning and Grouping . . . . . . . . . . . . 15
3.2.4. Rating Criteria and/or Cost Calculation . . . . . . . 15
3.3. Known Limitations of ALTO . . . . . . . . . . . . . . . . 18
3.3.1. Limitations of Map-based Approaches . . . . . . . . . 18
3.3.2. Limitiations of Non-Map-based Approaches . . . . . . 20
3.4. Map Examples for Different Types of ISPs . . . . . . . . 20
3.4.1. Small ISP with Single Internet Uplink . . . . . . . . 20
3.4.2. ISP with Several Fixed Access Networks . . . . . . . 22
3.4.3. ISP with Fixed and Mobile Network . . . . . . . . . . 24
3.5. Deployment Experiences . . . . . . . . . . . . . . . . . 25
4. Using ALTO for P2P Traffic Optimization . . . . . . . . . . . 25
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 26
4.1.2. Applicability of ALTO . . . . . . . . . . . . . . . . 29
Stiemerling, et al. Expires April 24, 2014 [Page 2]
Internet-Draft Deployment Considerations October 2013
4.2. Deployment Recommendations . . . . . . . . . . . . . . . 29
4.2.1. ALTO Services . . . . . . . . . . . . . . . . . . . . 29
4.2.2. Guidance Considerations . . . . . . . . . . . . . . . 29
5. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 33
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1. Usage Scenario . . . . . . . . . . . . . . . . . . . 33
5.1.2. Applicability of ALTO . . . . . . . . . . . . . . . . 33
5.2. Deployment Recommendations . . . . . . . . . . . . . . . 34
5.2.1. ALTO Services . . . . . . . . . . . . . . . . . . . . 34
5.2.2. Guidance Considerations . . . . . . . . . . . . . . . 35
6. Other Use Cases . . . . . . . . . . . . . . . . . . . . . . . 36
6.1. Monitoring Data Reporting . . . . . . . . . . . . . . . . 36
6.2. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 36
6.3. In-Network Caching . . . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7.1. Information Leakage from the ALTO Server . . . . . . . . 37
7.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . 38
7.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . 38
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Appendix: Monitoring ALTO . . . . . . . . . . . . . 41
A.1. Monitoring Metrics Definition . . . . . . . . . . . . . . 41
A.2. Monitoring Data Sources . . . . . . . . . . . . . . . . . 42
A.3. Monitoring Structure . . . . . . . . . . . . . . . . . . 42
Appendix B. Appendix: API between ALTO Client and Application . 43
Appendix C. Contributors List and Acknowledgments . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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,
which are able to provide a desired resource. The basic ideas and
problem space of ALTO is described in [RFC5693] and the set of
requirements is discussed in [RFC6708].
However, there are no considerations about what operational issues
are to be expected once ALTO will be deployed. This includes, but is
not limited to, location of the ALTO server, imposed load to the ALTO
server, or from whom the queries are performed.
Stiemerling, et al. Expires April 24, 2014 [Page 3]
Internet-Draft Deployment Considerations October 2013
Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org.
2. General Considerations
2.1. ALTO Entities
2.1.1. Baseline Scenario
The ALTO protocol [I-D.ietf-alto-protocol] is a client/server
protocol, operating between a number of ALTO clients and an ALTO
server, as sketched in Figure 1.
+----------+
| ALTO |
| Server |
+----------+
^
_.-----|------.
,-'' | `--.
,' | `.
( Network | )
`. | ,'
`--. | _.-'
`------|-----''
v
+----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client |
+----------+ +----------+ +----------+
Figure 1: Baseline Deployment Scenario of the ALTO Protocol
2.1.2. Placement of ALTO Entities
The ALTO server and ALTO clients can be situated at various entities
in a network deployment. The first differentiation is whether the
ALTO client is located on the actual host that runs the application,
as shown in Figure 2, or if the ALTO client is located on a resource
directory, as shown in Figure 3.
+-----+
=====| |**
==== +-----+ *
==== * *
==== * *
+-----+ +------+===== +-----+ *
| |.....| |======================| | *
Stiemerling, et al. Expires April 24, 2014 [Page 4]
Internet-Draft Deployment Considerations October 2013
+-----+ +------+===== +-----+ *
Source of ALTO ==== * *
topological service ==== * *
information ==== +-----+ *
=====| |**
+-----+
Legend:
=== ALTO client 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 applications that do not use
a resouce directory. An example would be a peer-to-peer file sharing
application that does not use a tracker, such as edonkey.
+-----+
**| |**
** +-----+ *
** * *
** * *
+-----+ +------+ +-----+** +-----+ *
| |.....| |=====| |**********| | *
+-----+ +------+ +-----+** +-----+ *
Source of ALTO Resource ** * *
topological service directory ** * *
information ** +-----+ *
**| |**
+-----+
Legend:
=== ALTO client 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 peer-to-peer filesharing. Both deployment
scenarios may differ in the number of ALTO clients that access an
ALTO service: If ALTO clients are implemented in a resource
directory, ALTO servers 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.
Stiemerling, et al. Expires April 24, 2014 [Page 5]
Internet-Draft Deployment Considerations October 2013
Using ALTO in CDNs may be similar to a resource directory
[I-D.jenkins-alto-cdn-use-cases]. The ALTO server can also be
queried by CDN entities to get a guidance about where the a
particular client accessing data in the CDN is exactly located in the
ISP's network, as discussed in Section 5.
2.2. Classification of Deployment Scenarios
2.2.1. Deployment Degrees of Freedom
ALTO is a general-purpose solution and it is intended to be used by a
wide range of applications. This 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 ISP's domain, or
if the clients and the ALTO server are managed/owned/located in
different domains.
ALTO deployments can be differentiated e.g. according to the
following aspects:
1. Applicable trust model: The deployment of ALTO can differ
depending on whether ALTO client and ALTO server are operated
within the same organization and/or network, or not. This
affects a lot 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. Size of 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 only offer guidance 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.
Stiemerling, et al. Expires April 24, 2014 [Page 6]
Internet-Draft Deployment Considerations October 2013
The following sections enumerate different classes of use cases for
ALTO, and they discuss the deployment implications of each of them.
However, 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 Models
An ALTO server stores information about preferences (e.g., a list of
preferred autonomous systems, IP ranges, etc) and ALTO clients can
retrieve these preferences. There are basically two different
approaches on where the preferences are actually processed:
1. The ALTO server has a list of preferences and clients can
retrieve this list via the ALTO protocol. This preference list
can partially be updated by the server. The actual processing of
the data is done on the client and thus there is no data of the
client's operation revealed to the ALTO server .
2. The ALTO server has a list of preferences or preferences
calculated during runtime and the ALTO client is sending
information of its operation (e.g., a list of IP addresses) to
the server. The server is using this operational information to
determine its preferences and returns these preferences (e.g., a
sorted list of the IP addresses) back to the ALTO client.
Approach 1 has the advantage (seen from the client) that all
operational information stays within the client and is not revealed
to the provider of the server. On the other hand, approach 1
requires that the provider of the ALTO server, i.e., the network
operator, reveals information about its network structure (e.g., AS
numbers, IP ranges, topology information in general) to the ALTO
client. The ALTO protocol supports this scheme by the Network and
Cost Map Service.
Approach 2 has the advantage (seen from the operator) that all
operational information stays with the ALTO server and is not
revealed to the ALTO client. On the other hand, approach 2 requires
that the clients send their operational information to the server.
This approach is realized by the ALTO Endpoint Cost Service (ECS).
Both approaches have their pros and cons, as detailed in Section 3.3.
2.2.3. More Advanced Deployments
Stiemerling, et al. Expires April 24, 2014 [Page 7]
Internet-Draft Deployment Considerations October 2013
From an ALTO client's perspective, there are two fundamental ways to
use ALTO:
1. Single server: An ALTO client only obtains guidance from a single
ALTO server instance, e.g., an ALTO server that is offered by the
network service provider of the corresponding access network.
This ALTO server can be discovered e.g. by ALTO server discovery
[I-D.ietf-alto-server-discovery].
2. Multiple servers: An ALTO client is aware of more than one ALTO
server. This scenario is mostly identical to the former one if
all those servers provide the same guidance (e.g., load
balancing). Yet, an ALTO client can also decide to access
multiple servers providing different guidance, possibly from
different operators. In that case, it may be difficult for an
ALTO client to compare the guidance from different servers. How
to discover multiple servers is an open issue.
There are also different options regarding the guidance offered by an
ALTO server:
1. Authorative 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 my
communicate by other means. This approach is not further
discussed in this document.
An assumption of the ALTO solution is that ISP operate ALTO servers
independently, irrespectively of other ISPs. This may true for most
envisioned deployments of ALTO but there are certain deployments that
may have different settings. Figure 4 shows such setting with a
university network that is connected to two upstream providers. ISP2
is the national research network and ISP1 is a commercial upstream
provider to this university network. The university, as well as
ISP1, are operating their own ALTO server. The ALTO clients, located
on the peers will contact the ALTO server located at the university.
+-----------+
| ISP1 |
| ALTO |
| Server |
+----------=+
Stiemerling, et al. Expires April 24, 2014 [Page 8]
Internet-Draft Deployment Considerations October 2013
,-------= ,------.
,-' =`-. ,-' `-.
/ Upstream= \ / Upstream \
( ISP1 = ) ( ISP2 )
\ = / \ /
`-. =,-' `-. ,-'
`---+---= `+------'
| = |
| =======================
|,-------------. | =
,-+ `-+ +-----------+
,' University `. |University |
( Network ) | ALTO |
`. =======================| Server |
`-= +-' +-----------+
=`+------------'|
= | |
+--------+-+ +-+--------+
| Peer1 | | PeerN |
+----------+ +----------+
Figure 4: Cascaded ALTO Server
In this setting all "destinations" useful for the peers within ISP2
are free-of-charge for the peers located in the university network
(i.e., they are preferred in the rating of the ALTO server).
However, all traffic that is not towards ISP2 will be handled by the
ISP1 upstream provider. Therefore, the ALTO server at the university
has also to include the guidance given by the ISP1 ALTO server in its
replies to the ALTO clients. This is an example for cascaded ALTO
servers.
3. Deployment Considerations by ISPs
3.1. Objectives for the Guidance to Applications
3.1.1. General Objectives for Traffic Optimization
The Internet is a large network consisting of many networks
worldwide. These networks are built by network operators or Internet
Service Providers (named ISP in this memo), and these networks
provide network connectivity to access networks, such as cable
networks, xDSL networks, 3G/4G mobile networks, etc. Some of these
networks are also built by universities or big organizations. These
network providers need to manage, to control and to audit the
traffic. Thus, it's important for ISPs to understand the requirement
of optimizing traffic, and how to deploy ALTO service in these
manageability and controllability networks.
Stiemerling, et al. Expires April 24, 2014 [Page 9]
Internet-Draft Deployment Considerations October 2013
The objective of ALTO is to give guidance to applications on what IP
addresses or IP prefixes are to be preferred according to the
operator of the ALTO server. The ALTO protocol gives means to let
the ALTO server operator express its preference, whatever this
preference is.
ALTO enables ISPs to perform traffic engineering by influencing
application resource selections. This traffic engineering can have
different objectives:
1. Inter-network traffic localization: ALTO can help to reduce
inter-domain traffic. The networks of ISPs are connected through
peering points. From a business view, the inter-network
settlement is needed for exchanging traffic between these
networks. These peering agreements can be costly. To reduce
these costs, a simple objective is to decrease the traffic
exchange across the peering points and thus keep the traffic in
the own network or Autonomous System (AS) as far as possible.
2. Intra-network traffic localization: In case of large ISPs, the
network may be grouped into several networks, domains, or
Autonomous Systems (ASs). The core network includes one or
several backbone networks, which are connected to multiple
aggregation, metro, and access networks. If traffic can be
limited to access networks, this decreases the usage of backbone
and thus helps to save resources and costs.
3. Network off-loading: Compared to fixed networks, mobile networks
have some special characteristics, including smaller link
bandwidth, high cost, limited radio frequency resource, and
limited terminal battery. In mobile networks, the usage of
wireless link should be decreased as far as possible and be used
efficiently. For example, in the case of a P2P service, the
hosts in fixed networks should avoid retrieving data from hosts
in the mobile networks, and hosts in mobile networks should
prefer the data retrieval from hosts in fixed networks.
4. Application tuning: ALTO is also a powerful tool to optimize the
performance of applications that depend on the network and
perform resource selection decisions.
In the following, these objectives are explained in more detail with
deployment examples.
3.1.2. Inter-Network Traffic Localization
ALTO guidance can be used to keep traffic local in a network. An
ALTO server can let applications prefer other hosts within the same
Stiemerling, et al. Expires April 24, 2014 [Page 10]
Internet-Draft Deployment Considerations October 2013
network operator's network instead of randomly connecting to other
hosts that are located in another operator's network. Here, a
network operator would always express its preference for hosts in its
own network, while hosts located outside its own network are to be
avoided (i.e., they are undesired to be considered by the
applications). Figure 5 shows such a scenario where hosts prefer
hosts in the same network (e.g., Host 1 and Host 2 in ISP1 and Host 3
and Host 4 in ISP2).
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 ########|ALTO Client|
/ \ / # \ +-----------+
/ ISP X \ | # | +-----------+
/ \ \ ########| Host 2 |
; +----------------------------|ALTO Client|
| | | `-. ,-' +-----------+
| | | `-------'
| | | ,-------. +-----------+
: | ; ,-' `########| Host 3 |
\ | / / ISP 2 # \ |ALTO Client|
\ | / / # \ +-----------+
\ +---------+ # | +-----------+
`-. ,-' \ | ########| Host 4 |
`---' \ +------------------|ALTO Client|
`-. ,-' +-----------+
`-------'
Legend:
### preferred "connections"
--- non-preferred "connections"
Figure 5: ALTO Traffic Network Localization
TBD: Describes limits of this approach (e.g., traffic localization
guidance is of less use if the peers cannot upload); describe how
maps would look like.
3.1.3. Intra-Network Traffic Localization
Stiemerling, et al. Expires April 24, 2014 [Page 11]
Internet-Draft Deployment Considerations October 2013
The above sections described the results of the ALTO guidance on an
inter-network level. However, ALTO can also be used for intra-
network localization. In this case, ALTO provides guidance which
internal hosts are to be preferred inside a single network or, e.g.,
one AS. Figure 6 shows such a scenario where Host 1 and Host 2 are
located in Net 2 of ISP1 and connect via a low capacity link to the
core (Net 1) of the same ISP1. If Host 1 and Host 2 exchange their
data with remote hosts, they would probably congest the bottleneck
link.
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 #########|ALTO Client|
/ \ / Net 2 # \ +-----------+
/ ISP 1 \ | ######### | +-----------+
/ Net 1 \ \ # / | Host 2 |
; ###; \ # ##########|ALTO Client|
| X~~~~~~~~~~~~X#######,-' +-----------+
| ### | ^ `-------'
| | |
: ; |
\ / Bottleneck
\ /
\ /
`-. ,-'
`---'
Legend:
### peer "connections"
~~~ bottleneck link
Figure 6: Without Intra-Network ALTO Traffic Localization
The operator can guide the hosts in such a situation to try first
local hosts in the same network islands, avoiding or at least
lowering the effect on the bottleneck link, as shown in Figure 7.
,-------. +-----------+
,---. ,-' `-. | Peer 1 |
,-' `-. / ISP 1 #########|ALTO Client|
/ \ / Net 2 # \ +-----------+
/ ISP 1 \ | # | +-----------+
/ Net 1 \ \ #########| Peer 2 |
; ; \ ##########|ALTO Client|
| #~~~~~~~~~~~########,-' +-----------+
| ### | ^ `-------'
| | |
: ; |
\ / Bottleneck
Stiemerling, et al. Expires April 24, 2014 [Page 12]
Internet-Draft Deployment Considerations October 2013
\ /
\ /
`-. ,-'
`---'
Legend:
### peer "connections"
~~~ bottleneck link
Figure 7: With Intra-Network ALTO Traffic Localization
3.1.4. Network Off-Loading
Another scenario is off-loading traffic from networks. This use of
ALTO can be beneficial in particular in mobile broadband networks.
The network operator may have the desire to guide hosts in its own
network to use hosts in remote networks. One reason can be that the
wireless network is not made for the load cause by, e.g., peer-to-
peer applications, and the operator has the need that peers fetch
their data from remote peers in other parts of the Internet.
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 +-------|ALTO Client|
/ \ / | \ +-----------+
/ ISP X \ | | | +-----------+
/ \ \ +-------| Host 2 |
; #-###########################|ALTO Client|
| # | `-. ,-' +-----------+
| # | `-------'
| # | ,-------. +-----------+
: # ; ,-' `+-------| Host 3 |
\ # / / ISP 2 | \ |ALTO Client|
\ # / / | \ +-----------+
\ ########### | | +-----------+
`-. ,-' \ # +-------| Host 4 |
`---' \ ###################|ALTO Client|
`-. ,-' +-----------+
`-------'
Legend:
=== preferred "connections"
--- non-preferred "connections"
Figure 8: ALTO Traffic Network De-Localization
Figure 8 shows the result of such a guidance process where Host 2
prefers a connection with Host 4 instead of Host 1, as shown in
Figure 5.
Stiemerling, et al. Expires April 24, 2014 [Page 13]
Internet-Draft Deployment Considerations October 2013
TBD: Limits of this approach in general and with respect to p2p.
describe how maps would look like.
3.1.5. Application Tuning
ALTO can also provide guidance to optimize the application-level
topology of networked applications, e.g., by exposing network
performance information. Applications can often run own measurements
to determine network performance, e.g., by active delay measurements
or bandwidth probing, but such measurements result in overhead and
complexity. Accessing an ALTO server can be a simpler alternative.
In addition, an ALTO server may also expose network information that
applications cannot easily measure or reverse-engineer.
3.2. Provisioning of ALTO Maps
3.2.1. Data Sources
TBD: This section will describe how ALTO maps in the protocol can be
populated before using them. The maps can significantly differ
depending on the use case, the network architecture, and the trust
relationship between ALTO server and ALTO client, etc.
The ALTO server builds an ALTO-specific network topology that
represents the network as it should be understood and utilized by the
application. Besides the security requirements that consist of not
delivering any confidential or critical information about the
infrastructure, there are efficiency requirements in terms of what
aspects of the network are visible and required by the given use case
and/or application.
The ALTO server builds topology (for either Map and ECS services)
based on multiple sources that may include routing protocols, network
policies, state and performance information, geo-location, etc. The
network topology information is controlled and managed by the ALTO
server. In all cases, the ALTO topology will not contain any details
that would endanger the network integrity and security, e.g., there
will be no leaking of OSPF/ISIS/BGP databases to ALTO clients.
3.2.2. Privacy Requirements
Providing ALTO guidance results in a win-win situation both for
network providers and users of the ALTO information. Applications
possibly get a better performance, while the the network provider has
means to optimize the traffic engineering and thus its costs.
Still, ISPs may have other important requirements when deploying
ALTO: In particular, an ISP may not be willing to expose sensitive
Stiemerling, et al. Expires April 24, 2014 [Page 14]
Internet-Draft Deployment Considerations October 2013
operational details of its network. The topology abstraction of ALTO
enables an ISP to expose the network topology at a desired
granularity only.
With the ALTO Endpoint Cost Service, the ALTO client does not to have
to implement any specific algorithm or mechanism in order to
retrieve, maintain and process network topology information (of any
kind). The complexity of the network topology (computation,
maintenance and distribution) is kept in the ALTO server and ECS is
delivered on demand. This allows the ALTO server to enhance and
modify the way the topology information sources are used and
combined. This simplifies the enforcement of privacy policies of the
ISP.
The ALTO Network Map and Cost Map service expose an abstracted view
on the ISP network topology. Therefore, in this case care is needed
when constructing those maps, as further discussed in Section 3.2.3.
3.2.3. Map Partitioning and Grouping
Host group descriptors are used in the ALTO client protocol to
describe the location of a host in the network topology. These
identifiers are called Partition ID (PID) and e.g. expand to a set of
IP address ranges (CIDR).
An automated ALTO implementation may use dynamic algorithms to
aggregate network topology. However, it is often desirable to have a
mechanism through which the network operator can control the level
and details of network aggregation based on a set of requirements and
constraints.
IP/MPLS networks make use of a common mechanism to aggregate and
group prefixes that is called BGP Communities. BGP is the protocol
all ISP networks use in order to exchange information about their
prefix reachability. BGP Community is an attribute used to tag a
prefix to group prefixes based on mostly any criteria (as an example,
most ISP networks originate BGP prefixes with communities identifying
the Point of Presence (PoP) where the prefix has been originated).
The ALTO server may leverage the BGP information that is available in
the SP network layer and compute group of prefixes. By policy, the
ALTO server operator may decide an arbitrary cost defined between
groups. Alternatively, there are algorithms that allows a dynamic
computation of cost between groups.
3.2.4. Rating Criteria and/or Cost Calculation
Stiemerling, et al. Expires April 24, 2014 [Page 15]
Internet-Draft Deployment Considerations October 2013
Rating criteria are used in the ALTO client protocol to express
topology- or connectivity-related properties, which are evaluated in
order to generate the ALTO guidance. The ALTO client protocol
specification defines a basic set of rating criteria, which have to
be supported by all implementations, and an extension procedure for
adding new criteria.
The following list gives an overview on further rating criteria that
have been proposed or which are in use by ALTO-related prototype
implementations. This list is not intended as normative text.
Instead, the only purpose of the following list is to document the
rating criteria that have been proposed so far, and to solicit
further feedback and discussion.
Distance-related rating criteria:
o Relative topological distance: relative means that a larger
numerical value means greater distance, but it is up to the ALTO
service how to compute the values, and the ALTO client will not be
informed about the nature of the information. One way of
generating this kind of information MAY be counting AS hops, but
when querying this parameter, the ALTO client MUST NOT assume that
the numbers actually are AS hops.
o Absolute topological distance, expressed in the number of
traversed autonomous systems (AS).
o Absolute topological distance, expressed in the number of router
hops (i.e., how much the TTL value of an IP packet will be
decreased during transit).
o Absolute physical distance, based on knowledge of the approximate
geolocation (continent, country) of an IP address.
Charging-related rating criteria:
o Traffic volume caps, in case the Internet access of the resource
consumer is not charged by "flat rate". For each candidate
resource provider, the ALTO service could indicate the amount of
data that may be transferred from/to this resource provider until
a given point in time, and how much of this amount has already
been consumed. Furthermore, it would have to be indicated how
excess traffic would be handled (e.g., blocked, throttled, or
charged separately at an indicated price). The interaction of
several applications running on a host, out of which some use this
criterion while others don't, as well as the evaluation of this
criterion in resource directories, which issue ALTO queries on
behalf of other peers, are for further study.
Stiemerling, et al. Expires April 24, 2014 [Page 16]
Internet-Draft Deployment Considerations October 2013
Performance-related rating criteria:
o The minimum achievable throughput between the resource consumer
and the candidate resource provider, which is considered useful by
the application (only in ALTO queries), or
o An arbitrary upper bound for the throughput from/to the candidate
resource provider (only in ALTO responses). This may be, but is
not necessarily the provisioned access bandwidth of the candidate
resource provider.
o The maximum round-trip time (RTT) between resource consumer and
the candidate resource provider, which is acceptable for the
application for useful communication with the candidate resource
provider (only in ALTO queries), or
o An arbitrary lower bound for the RTT between resource consumer and
the candidate resource provider (only in ALTO responses). This
may be, for example, based on measurements of the propagation
delay in a completely unloaded network.
These rating criteria are subject to the remarks below:
The ALTO client MUST be aware, that with high probability, the actual
performance values differ significantly from these upper and lower
bounds. In particular, an ALTO client MUST NOT consider the "upper
bound for throughput" parameter as a permission to send data at the
indicated rate without using congestion control mechanisms.
The discrepancies are due to various reasons, including, but not
limited to the facts that
o the ALTO service is not an admission control system
o the ALTO service may not know the instantaneous congestion status
of the network
o the ALTO service may not know all link bandwidths, i.e., where the
bottleneck really is, and there may be shared bottlenecks
o the ALTO service may not know whether the candidate peer itself is
overloaded
o the ALTO service may not know whether the candidate peer throttles
the bandwidth it devotes for the considered application
Stiemerling, et al. Expires April 24, 2014 [Page 17]
Internet-Draft Deployment Considerations October 2013
o the ALTO service may not know whether the candidate peer will
throttle the data it sends to us (e.g., because of some fairness
algorithm, such as tit-for-tat)
Because of these inaccuracies and the lack of complete, instantaneous
state information, which are inherent to the ALTO service, the
application must use other mechanisms (such as passive measurements
on actual data transmissions) to assess the currently achievable
throughput, and it MUST use appropriate congestion control mechanisms
in order to avoid a congestion collapse. Nevertheless, these rating
criteria may provide a useful shortcut for quickly excluding
candidate resource providers from such probing, if it is known in
advance that connectivity is in any case worse than what is
considered the minimum useful value by the respective application.
Rating criteria that SHOULD NOT be defined for and used by the ALTO
service include:
o Performance metrics that are closely related to the instantaneous
congestion status. The definition of alternate approaches for
congestion control is explicitly out of the scope of ALTO.
Instead, other appropriate means, such as using TCP based
transport, have to be used to avoid congestion.
3.3. Known Limitations of ALTO
This section describes some known limitations of ALTO in general or
specific mechanisms in ALTO.
3.3.1. Limitations of Map-based Approaches
The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses
so-called network maps. The network map approach uses host group
descriptors that group one or multiple subnetworks (i.e., IP
prefixes) to a single aggregate. A set of IP prefixes is called
partition and the associated Host Group Descriptor is called
Partition ID (PID). The "costs" between the various partition IDs is
stored in a second map, the cost map. Map-based approaches lower the
signaling load on the server as maps have to be retrieved only if
they change.
Stiemerling, et al. Expires April 24, 2014 [Page 18]
Internet-Draft Deployment Considerations October 2013
One main assumption for map-based approaches is that the information
provided in these maps is static for a longer period of time, where
this period of time refers to days, but not hours or even minutes.
This assumption is fine as long as the network operator does not
change any parameter, e.g., routing within the network and to the
upstream peers, IP address assignment stays stable (and thus the
mapping to the partitions). However, there are several cases where
this assumption is not valid, as:
1. ISPs reallocate IP subnets from time to time;
2. ISPs reallocate IP subnets on short notice;
3. IP prefix blocks may be assigned to a router that serves a
variety of access networks;
4. Network costs between IP prefixes may change depending on the
ISP's routing and traffic engineering.
For 1): ISPs reallocate IPv4 subnets within their infrastructure from
time to time, partly to ensure the efficient usage of IPv4 addresses
(a scarce resource), and partly to enable efficient route tables
within their network routers. The frequency of these "renumbering
events" depend on the growth in number of subscribers and the
availability of address space within the ISP. As a result, a
subscriber's household device could retain an IPv4 address for as
short as a few minutes, or for months at a time or even longer.
Some folks have suggested that ISPs providing ALTO services could
sub-divide their subscribers' devices into different IPv4 subnets (or
certain IPv4 address ranges) based on the purchased service tier, as
well as based on the location in the network topology. The problem
is that this sub-allocation of IPv4 subnets tends to decrease the
efficiency of IPv4 address allocation. A growing ISP that needs to
maintain high efficiency of IPv4 address utilization may be reluctant
to jeopardize their future acquisition of IPv4 address space.
However, this is not an issue for map-based approaches if changes are
applied in the order of days.
For 2): ISPs can use techniques that allow the reallocation of IP
prefixes on very short notice, i.e., within minutes. An IP prefix
that has no IP address assignment to a host anymore can be
reallocated to areas where there is currently a high demand for IP
addresses.
For 3): In DSL-based access networks, IP prefixes are assigned to
DSLAMs which are the first IP-hop in the access-network between the
Stiemerling, et al. Expires April 24, 2014 [Page 19]
Internet-Draft Deployment Considerations October 2013
CPE and the Internet. The access-network between CPE and DSLAM
(called aggregation network) can have varying characteristics (and
thus associated costs), but still using the same IP prefix. For
instance one IP addresses IP11 out of a IP prefix IP1 can be assigned
to a VDSL (e.g., 2 MBit/s uplink) access line while the subsequent IP
address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s
uplink). These IP addresses are assigned on a first come first
served basis, i.e., the a single IP address out of the same IP prefix
can change its associated costs quite fast. This may not be an issue
with respect to the used upstream provider (thus the cross ISP
traffic) but depending on the capacity of the aggregation-network
this may raise to an issue.
For 4): The routing and traffic engineering inside an ISP network, as
well as the peering with other autonomous systems, can change
dynamically and affect the information exposed by an ALTO server. As
a result, cost map and possibly also network maps can change.
3.3.2. Limitiations of Non-Map-based Approaches
The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses,
amongst others mechanism, a mechanism called Endpoint Cost Service
(ECS). ALTO clients can ask guidance for specific IP addresses to
the ALTO server. However, asking for IP addresses, asking with long
lists of IP addresses, and asking quite frequently may overload the
ALTO server. The server has to rank each received IP address, which
causes load at the server. This may be amplified by the fact that
not only a single ALTO client is asking for guidance, but a larger
number of them. The results of the ECS are also more difficult to
cache than ALTO maps.
Caching of IP addresses at the ALTO client or the usage of the H12
approach [I-D.kiesel-alto-h12] in conjunction with caching may lower
the query load on the ALTO server.
3.4. Map Examples for Different Types of ISPs
3.4.1. Small ISP with Single Internet Uplink
Stiemerling, et al. Expires April 24, 2014 [Page 20]
Internet-Draft Deployment Considerations October 2013
For a small ISP, the inter-domain traffic optimizing problem is how
to decrease the traffic exchanged with other ISPs, because of high
settlement costs. By using the ALTO service to optimize traffic, a
small ISP can define two "optimization areas": one is its own
network; the other one consists of all other network destinations.
The cost map can be defined as follows: the cost of link between
clients of inner ISP's networks is lower than between clients of
outer ISP's networks and clients of inner ISP's network. As a
result, a host with ALTO client inside the network of this ISP will
prefer retrieving data from hosts connected to the same ISP.
An example is given in Figure 9. It is assumed that ISP A is a small
ISP only having one access network. As operator of the ALTO service,
ISP A can define its network to be one optimization area, named as
PID1, and define other networks to be the other optimization area,
named as PID2. C1 is denoted as the cost inside the network of ISP
A. C2 is denoted as the cost from PID2 to PID1, and C3 from PID1 to
PID2. For the sake of simplifity, in the following C2=C3 is assumed.
In order to keep traffic local inside ISP A, it makes sense to
define: C1<C2
-----------
//// \\\\
// \\
// \\ /-----------\
| +---------+ | //// \\\\
| | ALTO | ISP A | C2 | Other Networks |
| | Service | PID 1 <----------- PID 2
| +---------+ C1 | | |
| | \\\\ ////
\\ // \-----------/
\\ //
\\\\ ////
-----------
Figure 9: Example ALTO deployment in small ISPs
A simplified extract of the corresponding ALTO network and cost maps
is listed in Figure 10 and Figure 11, assuming that the network of
ISP A has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25.
In this example, the cost values C1 and C2 can be set to any number
C1<C2.
HTTP/1.1 200 OK
...
Content-Type: application/alto-networkmap+json
{
Stiemerling, et al. Expires April 24, 2014 [Page 21]
Internet-Draft Deployment Considerations October 2013
...
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
Figure 10: Example ALTO network map
HTTP/1.1 200 OK
...
Content-Type: application/alto-costmap+json
{
...
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": C1, "PID2": C2 },
"PID2": { "PID1": C2, "PID2": 0 },
}
}
Figure 11: Example ALTO cost map
3.4.2. ISP with Several Fixed Access Networks
For a large ISP with a fixed network comprising several access
networks and a core network, the traffic optimizing problems will
include (1) using the backbone network efficiently, (2) adjusting the
traffic balance in different access networks according to traffic
conditions and management policies, and (3) achieving a reduction of
settlement costs with other ISPs.
Stiemerling, et al. Expires April 24, 2014 [Page 22]
Internet-Draft Deployment Considerations October 2013
Such a large ISP deploying an ALTO service may want to optimize its
traffic according to the network topology of its access networks.
For example, each access network could be defined to be one
optimization area, i.e., traffic should be kept locally withing that
area if possible. Then the costs between those access networks can
be defined according to a corresponding traffic optimizing
requirement by this ISP. One example setup is further described
below and also shown in Figure 12.
In this example, ISP A has one backbone network and three access
networks, named as AN A, AN B, and AN C. A P2P application is used in
this example. For the traffic optimization, the first requirement is
to decrease the P2P traffic on the backbone network inside the
Autonomous System of ISP A; and the second requirement is to decrease
the P2P traffic to other ISPs, i.e., other Autonomous Systems. The
second requirement can be assumed to have priority over the first
one. Also, we assume that the settlement rate with ISP B is lower
than with other ISPs. Then ISP A can deploy an ALTO service to meet
these traffic optimization requirements. In the following, we will
give an example of an ALTO setting and configuration according to
these requirements.
In inner network of ISP A, we can define each access network to be
one optimization area, and assign one PID to each access network,
such as PID 1, PID 2, and PID 3. Because of different peerings with
different outer ISPs, we define ISP B to be one optimization area,
and we assign PID 4 to it. We define all other networks to be one
optimization area and assign PID 5 to it.
We assign costs (C1, C2, C3, C4, C5, C6, C7, C8) as shown in Figure
12. Cost C1 is denoted as the link cost in inner AN A (PID 1), and
C2 and C3 are defined accordingly. C4 is denoted as the link cost
from PID 1 to PID 2, and C5 is the correspinding cost from PID 3,
which is assumed to have a similar value. C6 is the cost between PID
1 and PID 3. For simplicity, we assume symmetrical costs between the
AN this example. C7 is denoted as the link cost from the ISP B to
ISP A. C8 is the link cost from other networks to ISP A.
According to previous discussion of the first requirement and the
second requirement, the relationship of these costs will be defined
as: (C1, C2, C3) < (C4, C5, C6) < (C7) < (C8)
+------------------------------------+ +----------------+
| ISP A +---------------+ | | |
| | Backbone | | C7 | ISP B |
| +--+ Network +---+ |<--------+ PID 4 |
| | +-------+-------+ | | | |
| | | | | | |
Stiemerling, et al. Expires April 24, 2014 [Page 23]
Internet-Draft Deployment Considerations October 2013
| | | | | +----------------+
| +---+--+ +--+---+ +-+----+ |
| |AN A | C4 |AN B | C5 |AN C | |
| |PID 1 +<-->|PID 2 |<--->+PID 3 | |
| |C1 | |C2 | |C3 | | +----------------+
| +---+--+ +------+ +-+----+ | | |
| | | | C8 | Other Networks |
| +----------------------+ |<--------+ PID 5 |
| C6 | | |
| | | |
+------------------------------------+ +----------------+
Figure 12: ALTO deployment in large ISPs with layered fixed network
structures
3.4.3. ISP with Fixed and Mobile Network
An ISP with both mobile network and fixed network my focus on
optimizing the mobile traffic by keeping traffic in the fixed network
as far as possible, because wireless bandwidth is a scarce resource
and traffic is costly in mobile network. In such a case, the main
requirement of traffic optimization could be decreasing the usage of
radio resources in the mobile network. An ALTO service can be
deployed to meet these needs.
Figure 13 shows an example: ISP A operates one mobile network, which
is connected to a backbone network. The ISP also runs two fixed
access networks AN A and AN B, which are also connected to the
backbone network. In this network structure, the mobile network can
be defined as one optimization area, and PID 1 can be assigned to it.
Access networks AN A and B can also be defined as optimization areas,
and PID 2 and PID 3 can be assigned, respectively. The cost values
are then defined as shown in Figure 13.
To decrease the usage of wireless link, the relationship of these
costs can be defined as follows:
From view of mobile network: C4 < C1. This means that clients in
mobile network requiring data resource from other clients will prefer
clients in AN A to clients in the mobile network. This policy can
decrease the usage of wireless link and power consumption in
terminals.
From view of AN A: C2 < C6, C5 = maximum cost. This means that
clients in other optimization area will avoid retrieving data from
the mobile network.
Stiemerling, et al. Expires April 24, 2014 [Page 24]
Internet-Draft Deployment Considerations October 2013
+-----------------------------------------------------------------+
| |
| ISP A +-------------+ |
| +--------+ ALTO +---------+ |
| | | Service | | |
| | +------+------+ | |
| | | | |
| | | | |
| | | | |
| +-------+-------+ | C6 +--------+------+ |
| | AN A |<--------------| AN B | |
| | PID 2 | C7 | | PID 3 | |
| | C2 |-------------->| C3 | |
| +---------------+ | +---------------+ |
| ^ | | | ^ |
| | | | | | |
| | |C4 | | | |
| C5 | | | | | |
| | | +--------+---------+ | | |
| | +-->| Mobile Network |<---+ | |
| | | PID 1 | | |
| +------- | C1 |----------+ |
| +------------------+ |
+-----------------------------------------------------------------+
Figure 13: ALTO deployment in ISPs with mobile network
3.5. Deployment Experiences
The examples in the previous section are simple and do not consider
specific requirements inside access networks, uch as different link
types. Deploying an ALTO service in real network will have to
require further network conditions and requirements. One real
example is described in greater detail in reference
[I-D.lee-alto-chinatelecom-trial].
Also, experiments have been conducted with ALTO-like deployments in
Internet Service Provider (ISP) networks. For instance, NTT
performed tests with their HINT server implementation and dummy nodes
to gain insight on how an ALTO-like service influence peer-to-peer
systems [I-D.kamei-p2p-experiments-japan]. The results of an early
experiment conducted in the Comcast network are documented in
[RFC5632].
4. Using ALTO for P2P Traffic Optimization
Stiemerling, et al. Expires April 24, 2014 [Page 25]
Internet-Draft Deployment Considerations October 2013
4.1. Overview
4.1.1. Usage Scenario
The scope of this section is the interaction of peer-to-peer
applications that use a centralized resource directory ("tracker"),
with the ALTO service. In this scenario, the resource consumer
("peer") asks the resource directory for a list of candidate resource
providers, which can provide the desired resource.
For efficiency reasons (i.e., message size), usually only a subset of
all resource providers known to the resource directory will be
returned to the resource consumer. Some or all of these resource
providers, plus further resource providers learned by other means
such as direct communication between peers, will be contacted by the
resource consumer for accessing the resource. The purpose of ALTO is
giving guidance on this peer selection, which is supposed to yield
better-than-random results. The tracker response as well as the ALTO
guidance are most beneficial in the initial phase after the resource
consumer has decided to access a resource, as long as only few
resource providers are known. Later, when the resource consumer has
already exchanged some data with other peers and measured the
transmission speed, the relative importance of ALTO may dwindle.
,-------.
,---. ,-' `-. +-----------+
,-' `-. / ISP 1 \ | Peer 1 |*****
/ \ / +-------------+ \ | | *
/ ISP X \ +=====>+ ALTO Server | )+-----------+ *
/ \ = \ +-------------+ / +-----------+ *
; +-----------+ : = \ / | Peer 2 | *
| | Tracker |<====+ `-. ,-' | |*****
| |ALTO Client|<====+ `-------' +-----------+ **
| +-----------+ | = ,-------. **
: * ; = ,-' `-. +-----------+ **
\ * / = / ISP 2 \ | Peer 3 | **
\ * / = / +-------------+ \ | |*****
\ * / +=====>| ALTO Server | )+-----------+ ***
`-. * ,-' \ +-------------+ / +-----------+ ***
`-*-' \ / | Peer 4 |*****
* `-. ,-' | | ****
* `-------' +-----------+ ****
* ****
* ****
***********************************************<******
Legend:
=== ALTO client protocol
*** Application protocol
Stiemerling, et al. Expires April 24, 2014 [Page 26]
Internet-Draft Deployment Considerations October 2013
Figure 14: Global tracker accessing ALTO server at various ISPs
Figure 14 depicts a tracker-based system, in which the tracker embeds
the ALTO client. The tracker itself is hosted and operated by an
entity different than the ISP hosting and operating the ALTO server.
A tracker outside the network of the ISP is the typical use case.
For instance, a tracker like Pirate Bay can serve Bittorrent peers
world-wide. Initially, the tracker has to look-up the ALTO server in
charge for each peer where it receives a ALTO query for. Therefore,
the ALTO server has to discover the handling ALTO server, as
described in [I-D.ietf-alto-server-discovery]. However, the peers do
not have any way to query the server themselves. This setting allows
giving the peers a better selection of candidate peers for their
operation at an initial time, but does not consider peers learned
through direct peer-to-peer knowledge exchange. This is called peer
exchange (PEX) in bittorent, for instance.
,-------. +-----------+
,---. ,-' `-. +==>| Peer 1 |*****
,-' `-. / ISP 1 \ = |ALTO Client| *
/ \ / +-------------+<=+ +-----------+ *
/ ISP X \ | + ALTO Server |<=+ +-----------+ *
/ \ \ +-------------+ /= | Peer 2 | *
; +---------+ : \ / +==>|ALTO Client|*****
| | Global | | `-. ,-' +-----------+ **
| | Tracker | | `-------' **
| +---------+ | ,-------. +-----------+ **
: * ; ,-' `-. +==>| Peer 3 | **
\ * / / ISP 2 \ = |ALTO Client|*****
\ * / / +-------------+<=+ +-----------+ ***
\ * / | | ALTO Server |<=+ +-----------+ ***
`-. * ,-' \ +-------------+ /= | Peer 4 |*****
`-*-' \ / +==>|ALTO Client| ****
* `-. ,-' +-----------+ ****
* `-------' ****
* ****
***********************************************<****
Legend:
=== ALTO client protocol
*** Application protocol
Figure 15: Global Tracker - Local ALTO Servers
The scenario in Figure 15 lets the peers directly communicate with
their ISP's ALTO server (i.e., ALTO client embedded in the peers),
giving thus the peers the most control on which information they
query for, as they can integrate information received from trackers
and through direct peer-to-peer knowledge exchange.
Stiemerling, et al. Expires April 24, 2014 [Page 27]
Internet-Draft Deployment Considerations October 2013
,-------. +-----------+
,---. ,-' ISP 1 `-. ***>| Peer 1 |
,-' `-. /+-------------+\ * | |
/ \ / + Tracker |<** +-----------+
/ ISP X \ | +-----===-----+<** +-----------+
/ \ \ +-----===-----+ /* | Peer 2 |
; +---------+ : \+ ALTO Server |/ ***>| |
| | Global | | +-------------+ +-----------+
| | Tracker | | `-------'
| +---------+ | +-----------+
: ^ ; ,-------. | Peer 3 |
\ * / ,-' ISP 2 `-. ***>| |
\ * / /+-------------+\ * +-----------+
\ * / / + Tracker |<** +-----------+
`-. *,-' | +-----===-----+ | | Peer 4 |<*
`---* \ +-----===-----+ / | | *
* \+ ALTO Server |/ +-----------+ *
* +-------------+ *
* `-------' *
***********************************************
Legend:
=== ALTO client protocol
*** Application protocol
Figure 16: P4P approach with local tracker and local ALTO server
There are some attempts to let ISP's to deploy their own trackers, as
shown in Figure 16. In this case, the client has no chance to get
guidance from the ALTO server, other than talking to the ISP's
tracker. However, the peers would have still chance the contact
other trackers, deployed by entities other than the peer's ISP.
Figure 16 and Figure 14 ostensibly take peers the possibility to
directly query the ALTO server, if the communication with the ALTO
server is not permitted for any reason. However, considering the
plethora of different applications of ALTO, e.g., multiple tracker
and non-tracker based P2P systems and or applications searching for
relays, it seems to be beneficial for all participants to let the
peers directly query the ALTO server. The peers are also the single
point having all operational knowledge to decide whether to use the
ALTO guidance and how to use the ALTO guidance. This is a preference
for the scenario depicted in Figure Figure 15.
Stiemerling, et al. Expires April 24, 2014 [Page 28]
Internet-Draft Deployment Considerations October 2013
4.1.2. Applicability of ALTO
TODO
4.2. Deployment Recommendations
4.2.1. ALTO Services
In case of peer-to-peer networks, there is basically a dilemma which
ALTO service to use: The Cost Map Service is seen as the only working
solution by peer-to-peer software vendors and the Endpoint Cost
Service is seen as the only working by the network operators. But
neither the software vendors nor the operators seem to willing to
change their position. However, there is the need to get both sides
on board, to come to a solution. For other use cases of ALTO, in
particular in more controlled environments, both approaches might be
feasible and it is more an engineering tradeoff whether to use a map-
based or query-based ALTO service.
4.2.2. Guidance Considerations
The ALTO protocol specification [I-D.ietf-alto-protocol] details how
an ALTO client can query an ALTO server for guiding information and
receive the corresponding replies. However, in the considered
scenario of a tracker-based P2P application, there are two
fundamentally different possibilities where to place the ALTO client:
1. ALTO client in the resource consumer ("peer")
2. ALTO client in the resource directory ("tracker")
In the following, both scenarios are compared in order to explain the
need for third-party ALTO queries.
In the first scenario (see Figure 18), the resource consumer queries
the resource directory for the desired resource (F1). The resource
directory returns a list of potential resource providers without
considering ALTO (F2). It is then the duty of the resource consumer
to invoke ALTO (F3/F4), in order to solicit guidance regarding this
list.
In the second scenario (see Figure 20), the resource directory has an
embedded ALTO client, which we will refer to as RDAC in this
document. After receiving a query for a given resource (F1) the
resource directory invokes the RDAC to evaluate all resource
providers it knows (F2/F3). Then it returns a, possibly shortened,
list containing the "best" resource providers to the resource
consumer (F4).
Stiemerling, et al. Expires April 24, 2014 [Page 29]
Internet-Draft Deployment Considerations October 2013
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : k good :
: | | +--------+ : P2P App. : +--------+ peers +------+ :
: | N | | random | : Protocol : | ALTO- |------>| data | :
: | known |====>| pre- |*************>| biased | | ex- | :
: | peers, | | selec- | : transmit : | peer |------>| cha- | :
: | M good | | tion | : n peer : | select | n-k | nge | :
: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :
:...........................: :.....^.....................:
|
| ALTO
| client protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
Figure 17: Tracker-based P2P Application with random peer
preselection
Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| F2 Tracker reply | |
|<======================| |
| F3 ALTO client protocol query |
|---------------------------------------------->|
| F4 ALTO client protocol reply |
|<----------------------------------------------|
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
Figure 18: Basic message sequence chart for resource consumer-
initiated ALTO query
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : :
: | | +--------+ : P2P App. : k good peers & +------+ :
: | N | | ALTO- | : Protocol : n-k bad peers | data | :
Stiemerling, et al. Expires April 24, 2014 [Page 30]
Internet-Draft Deployment Considerations October 2013
: | known |====>| biased |******************************>| ex- | :
: | peers, | | peer | : transmit : | cha- | :
: | M good | | select | : n peer : | nge | :
: +-______-+ +--------+ : IDs : +------+ :
:.....................^.....: :...........................:
|
| ALTO
| client protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
Figure 19: Tracker-based P2P Application with ALTO client in tracker
Peer Tracker w. RDAC ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| | F2 ALTO cli. p. query |
| |---------------------->|
| | F3 ALTO cli. p. reply |
| |<----------------------|
| F4 Tracker reply | |
|<======================| |
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
Figure 20: Basic message sequence chart for third-party ALTO query
Note: the message sequences depicted in Figure 18 and Figure 20 may
occur both in the target-aware and the target-independent query mode
(c.f. [RFC6708]). In the target-independent query mode no message
exchange with the ALTO server might be needed after the tracker
query, because the candidate resource providers could be evaluated
using a locally cached "map", which has been retrieved from the ALTO
server some time ago.
The problem with the first approach is, that while the resource
directory might know thousands of peers taking part in a swarm, the
list returned to the resource consumer is usually shortened for
efficiency reasons. Therefore, the "best" (in the sense of ALTO)
potential resource providers might not be contained in that list
anymore, even before ALTO can consider them.
Stiemerling, et al. Expires April 24, 2014 [Page 31]
Internet-Draft Deployment Considerations October 2013
For illustration, consider a simple model of a swarm, in which all
peers fall into one of only two categories: assume that there are
"good" ("good" in the sense of ALTO's better-than-random peer
selection, based on an arbitrary desired rating criterion) and "bad'
peers only. Having more different categories makes the maths more
complex but does not change anything to the basic outcome of this
analysis. Assume that the swarm has a total number of N peers, out
of which are M "good" and N-M "bad" peers, which are all known to the
tracker. A new peer wants to join the swarm and therefore asks the
tracker for a list of peers.
If, according to the first approach, the tracker randomly picks n
peers from the N known peers, the result can be described with the
hypergeometric distribution. The probability that the tracker reply
contains exactly k "good" peers (and n-k "bad" peers) is:
/ m \ / N - m \
\ k / \ n - k /
P(X=k) = ---------------------
/ N \
\ n /
/ n \ n!
with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1
k! (n-k)!
The probability that the reply contains at most k "good" peers is:
P(X<=k)=P(X=0)+P(X=1)+..+P(X=k).
For example, consider a swarm with N=10,000 peers known to the
tracker, out of which M=100 are "good" peers. If the tracker
randomly selects n=100 peers, the formula yields for the reply:
P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approx. 36%
this list does not contain a single "good" peer, and with 99%
probability there are only four or less of the "good" peers on the
list. Processing this list with the guiding ALTO information will
ensure that the few favorable peers are ranked to the top of the
list; however, the benefit is rather limited as the number of
favorable peers in the list is just too small.
Much better traffic optimization could be achieved if the tracker
would evaluate all known peers using ALTO, and return a list of 100
peers afterwards. This list would then include a significantly
higher fraction of "good" peers. (Note, that if the tracker returned
Stiemerling, et al. Expires April 24, 2014 [Page 32]
Internet-Draft Deployment Considerations October 2013
"good" peers only, there might be a risk that the swarm might
disconnect and split into several disjunct partitions. However,
finding the right mix of ALTO-biased and random peer selection is out
of the scope of this document.)
Therefore, from an overall optimization perspective, the second
scenario with the ALTO client embedded in the resource directory is
advantageous, because it is ensured that the addresses of the "best"
resource providers are actually delivered to the resource consumer.
An architectural implication of this insight is that the ALTO server
discovery procedures must support third-party discovery. That is, as
the tracker issues ALTO queries on behalf of the peer which contacted
the tracker, the tracker must be able to discover an ALTO server that
can give guidance suitable for that respective peer.
5. Using ALTO for CDNs
5.1. Overview
5.1.1. Usage Scenario
This section discuss the usage of ALTO for Content Delivery Networks
(CDNs) [I-D.jenkins-alto-cdn-use-cases]. CDNs are used to bring a
service (e.g., a web page, videos, etc) closer to the location of the
user - where close refers to shorten the distance between the client
and the server in the IP topology. CDNs use several techniques to
decide which server is closest to a client requesting a service. One
common way to do so, is relying on the DNS system, but there are many
other ways, see [RFC3568].
The general issue for CDNs, independent of DNS or HTTP Redirect based
approaches (see, for instance, [I-D.penno-alto-cdn]), is that the CDN
logic has to match the client's IP address with the closest CDN
cache. This matching is not trivial, for instance, in DNS based
approaches, where the IP address of the DNS original requester is
unknown (see [I-D.vandergaast-edns-client-ip] for a discussion of
this and a solution approach).
5.1.2. Applicability of ALTO
TODO: Rewording required
When a user request a given content, the CDN locates the content in
one or more caches and executes a selection algorithms in order to
redirect the user to the 'best' cache. In order to achieve that, the
CDN issues an ECS request with the endpoint address (IPv4/IPv6) of
the user (content requester) and the set of endpoint addresses of the
content caches (content targets). The ALTO server, receives the
Stiemerling, et al. Expires April 24, 2014 [Page 33]
Internet-Draft Deployment Considerations October 2013
request and ranks the list of content targets addresses based on
their distance from the content requester. By default, according to
[I-D.ietf-alto-protocol], the distance represents the routing cost as
computed by the routing layer (OSPF, ISIS, BGP) and may take into
consideration other routing criteria such as MPLS-VPN (MP-BGP) and
MPLS-TE (RSVP), policy and state and performance information in
addition to other information sources (policy, geo-location, state
and performance).
Once the ALTO server computed the distance it replies with the ranked
list of content target addresses. The list being ranked by distance,
the CDN is capable of integrating the rankings into its selection
process (that will also incorporate other criteria) and redirect the
user accordingly.
The Request Router may request the Endpoint service from the ALTO
client.
Specifically, the Request Router requests the Endpoint Cost Service
in order to rank/rate the content locations (i.e., IP addresses of
CDN nodes) based on their distance/cost (by default the Endpoint Cost
Service operates based on Routing Distance) from/to the user address.
Once the Request Router obtained from the ALTO Server the ranked list
of locations (for the specific user) it can incorporate this
information into its selection mechanisms in order to point the user
to the most appropriate location.
A Request Router that uses the Endpoint Cost Service may query the
ALTO Server for rankings of CDN Node IP addresses for each
interesting host and cache the results for later usage.
Maps Services and ECS deliver similar ALTO service by allowing the
CDN to optimize internal selection mechanisms. Both services deliver
similar level of security, confidentiality of layer-specific
information (i.e.: application and network) however, Maps and ECS
differ in the way the ALTO service is delivered and address a
different set of requirements in terms of topology information and
network operations.
5.2. Deployment Recommendations
5.2.1. ALTO Services
When ALTO server receives an ECS request, it may not have the most
appropriate topology information in order to accurately determine the
ranking. In such case, the ALTO server, may want to adopt the
following strategies:
Stiemerling, et al. Expires April 24, 2014 [Page 34]
Internet-Draft Deployment Considerations October 2013
o Reply with available information (best effort).
o Redirect the request to another ALTO server presumed to have
better topology information (redirection).
o Doing both (best effort and redirection). In this case, the reply
message contains both the rankings and the indication of another
ALTO server where more accurate rankings may be delivered.
The decision process that is used to determine if redirection is
necessary (and which mode to use) is out of the scope of this
document. As an example, an ALTO server may decide to redirect any
request having addresses that are located into a remote Autonomous
System. In such case the redirection message includes the ALTO
server to be used and that resides in the remote AS. Redirection
implies communication between ALTO servers so to be able to signal
their identity, location and type of visibility (AS number).
5.2.2. Guidance Considerations
Each reply sent back by the ALTO server to the ALTO client running in
the CDN has a validity in time so that the CDN can cache the results
in order to re-use it and hence reducing the number of transactions
between CDN and ALTO server. The ALTO server may indicate in the
reply message how long the content of the message is to be considered
reliable and insert a lifetime value that will be used by the CDN in
order to cache (and then flush or refresh) the entry.
An ALTO server implementation may want to keep state about ALTO
clients so to inform and signal to these clients when a major network
event happened so to clear the ALTO cache in the client. In a CDN/
ALTO interworking architecture where there's a few CDN component
interacting with the ALTO server there are no scalability issues in
maintaining state about clients in the ALTO server.
ALTO server ranks addresses based on topology information it acquires
from the network. The different methods and algorithms through which
the ALTO server computes topology information and rankings is out of
the scope of this document. However, and in the case the rankings
are based on routing (IP/MPLS) topology, it is obvious that network
events may impact the ranking computation. The scope of the ECS
service delivered to a CDN is not to maintain the CDN aware of any
possible network topology changes since, due to redundancy of current
networks, most of the network events happening in the infrastructure
will have limited impact on the CDN. However, catastrophic events
such as main trunks failures or backbone partition will have to take
into account by the ALTO server so to redirect traffic away from the
failure impacted area.
Stiemerling, et al. Expires April 24, 2014 [Page 35]
Internet-Draft Deployment Considerations October 2013
6. Other Use Cases
This section briefly surveys and references other use cases that have
been suggested for ALTO.
6.1. Monitoring Data Reporting
TODO
6.2. Virtual Private Networks (VPNs)
TODO
6.3. In-Network Caching
Deployment of intra-domain P2P caches has been proposed for a
cooperations between the network operator and the P2P service
providers, e.g., to reduce the bandwith consumption in access
networks [I-D.deng-alto-p2pcache].
+--------------+ +------+
| ISP 1 network+----------------+Peer 1|
+-----+--------+ +------+
|
+--------+------------------------------------------------------+
| | ISP 2 network |
| +---------+ |
| |L1 Cache | |
| +-----+---+ |
| +--------------------+----------------------+ |
| | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | AN1 | | AN2 | | AN3 | |
| | +---------+ | | +----------+ | | | |
| | |L2 Cache | | | |L2 Cache | | | | |
| | +---------+ | | +----------+ | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | |
| +--------------------+ | |
| | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | SUB-AN11 | | SUB-AN12 | | SUB-AN31 | |
| | +---------+ | | | | | |
| | |L3 Cache | | | | | | |
| | +---------+ | | | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | | |
+--------+--------------------+----------------------+----------+
Stiemerling, et al. Expires April 24, 2014 [Page 36]
Internet-Draft Deployment Considerations October 2013
| | |
+---+---+ +---+---+ |
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|Peer2| |Peer3| |Peer4| |Peer5| |Peer6|
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 21: General architecture of intra-ISP caches
Figure 21 depics the overall architecture of a potential P2P cache
deployments inside an ISP 2 with various access network types. As
shown in the figure, P2P caches may be deployed at various levels,
including the interworking gateway linking with other ISPs, internal
access network gateways linking with different types of accessing
networks (e.g. WLAN, cellular and wired), and even within an
accessing network at the entries of individual WLAN sub-networks.
Moreover, depending on the network context and the operator's policy,
each cache can be a Forwarding Cache or a Bidirectional Cache
[I-D.deng-alto-p2pcache].
In such a cache architecture, the locations of caches could be used
as dividers of different PIDs to guide intra-ISP network abstraction
and mark costs among them according to the location and type of
relevant caches.
Further details and deployment considerations can be found in
[I-D.deng-alto-p2pcache].
7. Security Considerations
The ALTO protocol itself as well as the ALTO client and server raise
new security issues beyond the ones mentioned in
[I-D.ietf-alto-protocol] and issues related to message transport over
the Internet. For instance, Denial of Service (DoS) is of interest
for the ALTO server and also for the ALTO client. A server can get
overloaded if too many TCP requests hit the server, or if the query
load of the server surpasses the maximum computing capacity. An ALTO
client can get overloaded if the responses from the sever are, either
intentionally or due to an implementation mistake, too large to be
handled by that particular client.
This section is solely giving a first shot on security issues related
to ALTO deployments.
7.1. Information Leakage from the ALTO Server
The ALTO server will be provisioned with information about the owning
ISP's network and very likely also with information about neighboring
Stiemerling, et al. Expires April 24, 2014 [Page 37]
Internet-Draft Deployment Considerations October 2013
ISPs. This information (e.g., network topology, business relations,
etc.) is considered to be confidential to the ISP and must not be
revealed.
The ALTO server will naturally reveal parts of that information in
small doses to peers, as the guidance given will depend on the above
mentioned information. This is seen beneficial for both parties,
i.e., the ISP's and the peer's. However, there is the chance that one
or multiple peers are querying an ALTO server with the goal to gather
information about network topology or any other data considered
confidential or at least sensitive. It is unclear whether this is a
real technical security risk or whether this is more a perceived
security risk.
7.2. ALTO Server Access
Depending on the use case of ALTO, several access restrictions to an
ALTO server may or may not apply.
For peer-to-peer applications, a potential deployment scenario is
that an ALTO server is solely accessible by peers from the ISP
network (as shown in Figure 15). For instance, the source IP address
can be used to grant only access from that ISP network to the server.
This will "limit" the number of peers able to attack the server to
the user's of the ISP (however, including botnet computers).
If the ALTO server has to be accessible by parties not located in the
ISP's network (see Figure Figure 14), e.g., by a third-party tracker
or by a CDN system outside the ISP's network, the access restrictions
have to be looser. In the extreme case, i.e., no access
restrictions, each and every host in the Internet can access the ALTO
server. This might no be the intention of the ISP, as the server is
not only subject to more possible attacks, but also on the load
imposed to the server, i.e., possibly more ALTO clients to serve and
thus more work load.
There are also use cases where the access to the ALTO server has to
be much more strictly controlled, i. e., where an authentication and
authorization of the ALTO client to the server may be needed. For
instance, in case of CDN optimization the provider of an ALTO service
as well as potential users are possibly well-known. Only CDN
entities may need ALTO access; access to the ALTO servers by
residential users may neither be necessary nor be desired.
7.3. Faking ALTO Guidance
Stiemerling, et al. Expires April 24, 2014 [Page 38]
Internet-Draft Deployment Considerations October 2013
It has not yet been investigated how a faked or wrong ALTO guidance
by an ALTO server can impact the operation of the network and also
the peers.
Here is a list of examples how the ALTO guidance could be faked and
what possible consequences may arise:
Sorting An attacker could change to sorting order of the ALTO
guidance (given that the order is of importance, otherwise the
ranking mechanism is of interest), i.e., declaring peers located
outside the ISP as peers to be preferred. This will not pose a
big risk to the network or peers, as it would mimic the "regular"
peer operation without traffic localization, apart from the
communication/processing overhead for ALTO. However, it could
mean that ALTO is reaching the opposite goal of shuffling more
data across ISP boundaries, incurring more costs for the ISP.
Preference of a single peer A single IP address (thus a peer) could
be marked as to be preferred all over other peers. This peer can
be located within the local ISP or also in other parts of the
Internet (e.g., a web server). This could lead to the case that
quite a number of peers to trying to contact this IP address,
possibly causing a Denial of Service (DoS) attack.
8. Conclusion
This document discusses how the ALTO protocol can be deployed in
different use cases and provides corresponding guidance and
recommendations to network administrators and application developers.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms", RFC
3568, July 2003.
9.2. Informative References
[I-D.deng-alto-p2pcache]
Lingli, D., Chen, W., Yi, Q., and Y. Zhang,
"Considerations for ALTO with network-deployed P2P
caches", draft-deng-alto-p2pcache-02 (work in progress),
July 2013.
Stiemerling, et al. Expires April 24, 2014 [Page 39]
Internet-Draft Deployment Considerations October 2013
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
ietf-alto-protocol-20 (work in progress), October 2013.
[I-D.ietf-alto-server-discovery]
Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
S. Yongchao, "ALTO Server Discovery", draft-ietf-alto-
server-discovery-10 (work in progress), September 2013.
[I-D.jenkins-alto-cdn-use-cases]
Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
S. Previdi, "Use Cases for ALTO within CDNs", draft-
jenkins-alto-cdn-use-cases-03 (work in progress), June
2012.
[I-D.kamei-p2p-experiments-japan]
Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO-
Like Activities and Experiments in P2P Network Experiment
Council", draft-kamei-p2p-experiments-japan-09 (work in
progress), October 2012.
[I-D.kiesel-alto-h12]
Kiesel, S. and M. Stiemerling, "ALTO H12", draft-kiesel-
alto-h12-02 (work in progress), March 2010.
[I-D.lee-alto-chinatelecom-trial]
Li, K. and G. Jian, "ALTO and DECADE service trial within
China Telecom", draft-lee-alto-chinatelecom-trial-04 (work
in progress), March 2012.
[I-D.penno-alto-cdn]
Penno, R., Medved, J., Alimi, R., Yang, R., and S.
Previdi, "ALTO and Content Delivery Networks", draft-
penno-alto-cdn-03 (work in progress), March 2011.
[I-D.vandergaast-edns-client-ip]
Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
"Client IP information in DNS requests", draft-
vandergaast-edns-client-ip-01 (work in progress), May
2010.
[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
Y. Yang, "Comcast's ISP Experiences in a Proactive Network
Provider Participation for P2P (P4P) Technical Trial", RFC
5632, September 2009.
Stiemerling, et al. Expires April 24, 2014 [Page 40]
Internet-Draft Deployment Considerations October 2013
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October
2009.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", RFC 6708, September 2012.
Appendix A. Appendix: Monitoring ALTO
In addition to providing configuration, an ISP providing ALTO may
want to deploy a monitoring infrastructure to assess the benefits of
ALTO and adjust its ALTO configuration according to the results of
the monitoring.
To construct an effective monitoring infrastructure, the ISP should
(1) define the performance metrics to be monitored; (2) and identify
and deploy data sources to collect data to compute the performance
metrics. We discuss both below.
[Editor's note: Is there a relationship to the IPPM working group at
the IETF?]
A.1. Monitoring Metrics Definition
o Inter-domain ALTO-Integrated Application Traffic (Network metric):
This metric includes total cross domain traffic generated by
applications that utilize ALTO guidance. This metric evaluates
the impacts of ALTO on the inbound and outbound traffic of a
domain.
o Total Inter-domain Traffic (Network metric): This is similar to
the preceding but focuses on all of the traffic, ALTO aware or
not. One possibility is that some of the reduction of interdomain
traffic by ALTO aware applications may (XXX missing words?). This
metric is always used with the preceding and the following
metrics.
o Intra-domain ALTO-Integrated Application Traffic (Network metric).
(XXX description missing)
o Network hop count (Network metric): This metric provides the
average number of hops that traffic traverses inside a domain.
ALTO may reduce not only traffic volume but also the hops. The
metric can also indirectly reflect some application performance
(e.g., latency).
Stiemerling, et al. Expires April 24, 2014 [Page 41]
Internet-Draft Deployment Considerations October 2013
o Application download rate (Application metric): This metric
measures application performance directly. Download means inbound
traffic to one user. Global average means the average value of
all users' download rates in one or more domains.
o Application Client type audit(Application metric): this metric
gives the audit of client types in ALTO service. The current
types include fixed network client and mobile network client.
A.2. Monitoring Data Sources
The preceding metrics are derived from data sources. We identify
three data sources.
1. Application Log Server: Many application systems deploy Log
Servers to collect data.
2. P2P Clients: Some P2P applications may not have Log Servers.
When available, P2P client logs can provide data. This is for
P2P application
3. OAM: Many ISPs deploy OAM systems to monitor IP layer traffic.
An OAM provides traffic monitoring of every network device in its
management area. It provides data such as link physical
bandwidth and traffic volumes.
A.3. Monitoring Structure
As discussed in the preceding section, some data sources are from ISP
while some others are from application. When there is a
collaboration agreement between the ISP and an application, there can
be an integrated monitoring system as shown in the figure below. In
particular, an application developer may deploy Monitor Clients to
communicate with Monitor Server of the ISP to transmit raw data from
the Log Server or P2P clients of the application to the ISP.
+------------------------------------------------+
| |
| New Entities +--------------------------------------+
| | Service Provider |
| | (P2P/CDN Operator etc)|
| +-----------+ | +-----------+ | |
| |ALTO Server|-------------|ALTO Client| | |
| +-----------+ | +-----------+ | |
| | | +----------+ |
| | | |Log Server| |
| | | +----------+ |
| +--------------+ | +--------------+ | +----------+ |
Stiemerling, et al. Expires April 24, 2014 [Page 42]
Internet-Draft Deployment Considerations October 2013
| |Monitor Server|----------|Monitor Client| | |P2P Client| |
| +--------------+ | +--------------+ | +----------+ |
| | | | |
| +--------|--------+ +--------------------------------------+
+-|--------|--------|----------------------------+
| | |
| | |
| +---+ |
| |OAM| |
| +---+ |
| ISP |
-----------------
Figure 22: Monitoring Structure
Appendix B. Appendix: API between ALTO Client and Application
This section gives some informational guidance on how the interface
between the actual application using the ALTO guidance and the ALTO
client can look like.
This is still TBD.
Appendix C. Contributors List and Acknowledgments
This memo is the result of contributions made by several people, such
as:
o Xianghue Sun, Lee Kai, and Richard Yang contributed text on ISP
deployment requirements and monitoring.
o Stefano Previdi contributed parts of the Section 5 on "Using ALTO
for CDNs".
o Rich Woundy contributed text to Section 3.3.
o Lingli Deng, Wei Chen, Qiuchao Yi, Yan Zhang contributed
Section 6.3.
o Thomas-Rolf Banniza carefully reviewed the document.
Martin Stiemerling is partially supported by the CHANGE project (
http://www.change-project.eu), a research project supported by the
European Commission under its 7th Framework Program (contract no.
257422). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the CHANGE project or the European Commission.
Stiemerling, et al. Expires April 24, 2014 [Page 43]
Internet-Draft Deployment Considerations October 2013
Authors' Addresses
Martin Stiemerling (editor)
NEC Laboratories Europe
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 113
Fax: +49 6221 4342 155
Email: martin.stiemerling@neclab.eu
URI: http://ietf.stiemerling.org
Sebastian Kiesel (editor)
University of Stuttgart, Computing Center
Allmandring 30
Stuttgart 70550
Germany
Email: ietf-alto@skiesel.de
Stefano Previdi
Cisco Systems, Inc.
Via Del Serafico 200
Rome 00191
Italy
Email: sprevidi@cisco.com
Michael Scharf
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: michael.scharf@alcatel-lucent.com
Stiemerling, et al. Expires April 24, 2014 [Page 44]
