One document matched: draft-ietf-alto-deployments-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-alto-deployments-07"
ipr="trust200902">
<front>
<title abbrev="Deployment Considerations">ALTO Deployment
Considerations</title>
<author fullname="Martin Stiemerling" initials="M." surname="Stiemerling" role="editor">
<organization abbrev="NEC Europe Ltd.">NEC Laboratories
Europe</organization>
<address>
<postal>
<street>Kurfuerstenanlage 36</street>
<code>69115</code>
<city>Heidelberg</city>
<country>Germany</country>
</postal>
<phone>+49 6221 4342 113</phone>
<facsimile>+49 6221 4342 155</facsimile>
<email>martin.stiemerling@neclab.eu</email>
<uri>http://ietf.stiemerling.org</uri>
</address>
</author>
<author fullname="Sebastian Kiesel" initials="S" surname="Kiesel" role="editor">
<organization abbrev="University of Stuttgart">University of Stuttgart,
Computing Center</organization>
<address>
<postal>
<street>Allmandring 30</street>
<city>Stuttgart</city>
<code>70550</code>
<country>Germany</country>
</postal>
<email>ietf-alto@skiesel.de</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization abbrev="Cisco"> Cisco Systems, Inc. </organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<code>00191</code>
<city>Rome</city>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Michael Scharf" initials="M." surname="Scharf">
<organization abbrev="Alcatel-Lucent Bell Labs">Alcatel-Lucent Bell Labs</organization>
<address>
<postal>
<street>Lorenzstrasse 10</street>
<code>70435</code>
<city>Stuttgart</city>
<country>Germany</country>
</postal>
<email>michael.scharf@alcatel-lucent.com</email>
</address>
</author>
<date year="2013" />
<area>APP</area>
<workgroup>ALTO</workgroup>
<keyword>ALTO</keyword>
<keyword>ALTO Deployment Considerations</keyword>
<abstract>
<t>Many Internet applications are used to access resources, such
as pieces of information or server processes, which 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 these
applications, which have to select one or several hosts from a
set of candidates that 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Many Internet applications are used to access resources, such as
pieces of information or server processes, which are available in
several equivalent replicas on different hosts. This includes, but is
not limited to, peer-to-peer file sharing applications and Content
Delivery Networks (CDNs). The goal of Application-Layer Traffic
Optimization (ALTO) is to provide guidance to applications, which have
to select one or several hosts from a set of candidates that are able
to provide a desired resource. The basic ideas of ALTO are described in
the problem space of ALTO is described in <xref target="RFC5693"></xref>
and the set of requirements is discussed in <xref
target="RFC6708"></xref>.</t>
<t>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.</t>
<t>Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org.</t>
</section>
<section anchor="sec.general_deployment" title="General Considerations">
<t>The ALTO protocol <xref
target="I-D.ietf-alto-protocol"></xref> is a client/server
protocol, operating between a number of ALTO clients and an ALTO
server, as sketched in <xref target="fig.overview"></xref>.</t>
<t><figure anchor="fig.overview"
title="Baseline Deployment Scenario of the ALTO Protocol">
<artwork><![CDATA[ +----------+
| ALTO |
| Server |
+----------+
^
_.-----|------.
,-'' | `--.
,' | `.
( Network | )
`. | ,'
`--. | _.-'
`------|-----''
v
+----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client |
+----------+ +----------+ +----------+
]]></artwork>
</figure></t>
<section anchor="sec.general_overview" title="Placement of ALTO Entities">
<t>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 <xref
target="fig.tracker_less"></xref>, or if the ALTO client is
located on a resource directory, as shown in <xref
target="fig.tracker"></xref>.</t>
<t><figure anchor="fig.tracker_less"
title="Overview of protocol interaction between ALTO elements without a resource directory">
<artwork><![CDATA[ +-----+
=====| |**
==== +-----+ *
==== * *
==== * *
+-----+ +------+===== +-----+ *
| |.....| |======================| | *
+-----+ +------+===== +-----+ *
Source of ALTO ==== * *
topological service ==== * *
information ==== +-----+ *
=====| |**
+-----+
Legend:
=== ALTO client protocol
*** Application protocol
... Provisioning protocol]]></artwork>
</figure></t>
<t><xref target="fig.tracker_less"></xref> 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 edonky.</t>
<t><figure anchor="fig.tracker"
title="Overview of protocol interaction between ALTO elements with a resource directory">
<artwork><![CDATA[ +-----+
**| |**
** +-----+ *
** * *
** * *
+-----+ +------+ +-----+** +-----+ *
| |.....| |=====| |**********| | *
+-----+ +------+ +-----+** +-----+ *
Source of ALTO Resource ** * *
topological service directory ** * *
information ** +-----+ *
**| |**
+-----+
Legend:
=== ALTO client protocol
*** Application protocol
... Provisioning protocol]]></artwork>
</figure></t>
<t>In <xref target="fig.tracker"></xref>, a use case with a
resource directory is illustrated, e.g., a tracker in
peer-to-peer filesharing. Both deployment scenarios differ in
the number of ALTO clients that access an ALTO service: If
ALTO clients are implemented in a resource directory, ALTO
servers are accessed by a limited and less dynamic set of
clients, whereas in the general case any host in the Internet
could be an ALTO client.</t>
<t>Using ALTO in CDNs may be similar to a resource directory
<xref
target="I-D.jenkins-alto-cdn-use-cases"></xref>. 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.</t>
</section>
<section anchor="sec.alto_apps" title="Relationship between ALTO and Applications">
<t>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.</t>
<t>High-level differences between different ALTO deployments are:</t>
<t><list style="numbers">
<t>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 changes
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.</t>
<t>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
a lot from the public Internet.</t>
<t>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 costomized maps.</t>
</list></t>
<t>The following sections enumerate different classes of use
cases for ALTO, and they discuss the deployment implications
of each of them.</t>
<t>However, it must be empasized 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 situation (see also <xref
target="RFC6708"/>).</t>
</section>
<section anchor="sec.guidance" title="Provided Guidance">
<t>ALTO gives 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 only the means to let
the ALTO server operator to express is preference, whatever
this preference is.</t>
<section title="Keeping Traffic Local in Network">
<t>ALTO guidance can be used to let applications prefer
other hosts within the same 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 to prefer 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). <xref target="fig.network_local"></xref>
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). </t>
<t><figure anchor="fig.network_local"
title="ALTO Traffic Network Localization">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. | 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"
]]></artwork>
</figure></t>
<t>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.</t>
</section>
<section title="Off-Loading Traffic from Network">
<t>Another scenario where the use of ALTO can be beneficial is 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.
</t>
<t><figure anchor="fig.network_de_local"
title="ALTO Traffic Network De-Localization">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. | 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"
]]></artwork>
</figure><xref target="fig.network_de_local"></xref> shows the
result of such a guidance process where Host 2 prefers a connection
with Host 4 instead of Host 1, as shown in <xref
target="fig.network_local"></xref>.</t>
<t>TBD: Limits of this approach in general and with respect to p2p.
describe how maps would look like.</t>
</section>
<section title="Intra-Network Localization/Bottleneck Off-Loading">
<t>The above sections described the results of the ALTO guidance on
an inter-network level. However, ALTO can also be used to guide
hosts on which internal hosts are to be preferred. For instance, to
guide hosts on a remote network side to prefer to connect to each
other, instead of crossing a bottleneck link, a backhaul link to
connect the side to the network core. <xref
target="fig.no_intra_network_local"></xref> 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. Host 1 and
Host 2 would both exchange their data with remote hosts, probably
clogging the bottleneck link.</t>
<t><figure anchor="fig.no_intra_network_local"
title="Without Intra-Network ALTO Traffic Localization">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 #########|ALTO Client|
/ \ / Net 2 # \ +-----------+
/ ISP 1 \ | ######### | +-----------+
/ Net 1 \ \ # / | Host 2 |
; ###; \ # ##########|ALTO Client|
| X~~~~~~~~~~~~X#######,-' +-----------+
| ### | ^ `-------'
| | |
: ; |
\ / Bottleneck
\ /
\ /
`-. ,-'
`---'
Legend:
### peer "connections"
~~~ bottleneck link
]]></artwork>
</figure></t>
<t>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 <xref
target="fig.intra_network_local"></xref>.</t>
<t><figure anchor="fig.intra_network_local"
title="With Intra-Network ALTO Traffic Localization">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. | Peer 1 |
,-' `-. / ISP 1 #########|ALTO Client|
/ \ / Net 2 # \ +-----------+
/ ISP 1 \ | # | +-----------+
/ Net 1 \ \ #########| Peer 2 |
; ; \ ##########|ALTO Client|
| #~~~~~~~~~~~########,-' +-----------+
| ### | ^ `-------'
| | |
: ; |
\ / Bottleneck
\ /
\ /
`-. ,-'
`---'
Legend:
### peer "connections"
~~~ bottleneck link
]]></artwork>
</figure></t>
<t>TBD: describe how maps would look like.</t>
</section>
</section>
<section title="Provisiong ALTO Maps">
<t>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.</t>
</section>
</section>
<section anchor="sec.ISP_deployment" title="Deployment Considerations by ISPs">
<t>The Internet is a large network constituted of multiple
networks worldwide. Numerous of these networks are built by telecom
operators or network operators (named ISP in this memo), and these networks
provide network connectivity, such as cable
networks, 3G and so on. As well as some of networks are built by universities
or big organizations themselves, and these networks are used to provide
connectivity for research and work. The essence of Internet is its
connectivity and sharing capability. However, ISPs emphasize network's
manageability and controllability, because ISPs provide public network
access service for most person and families, they 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.
</t>
<section anchor="sec.ISP_deployment_req_general" title="Requirement by ISPs">
<section anchor="sec.ISP_deployment_req" title="Requirement for Traffic Optimization">
<t>ALTO enables ISPs to perform traffic engineering by
influencing application resouce selections. This can help
to reduce inter-domain traffic. The networks of ISPs are
connected to each other through peering points. From view
of business mode, the inter-network settlement is needed
in traffic exchanging between these ISP's networks. The
current settlement can be costly. So to save these cost,
the simple and basic method is to decrease the traffic
exchange across the peering points and keep the traffic in
own network area.</t>
<t>For some large ISPs, their whole network is grouped
into several network domains. 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.</t>
<t>Compared to fixed networks, mobile networks have some
special charactistics, including small link bandwidth,
high cost, limited radio frequency resource, and terminal
battery. In mobile network, the usage of wireless link
should be decreased as far as possible and be
high-efficient. For example, in the case of a P2P service,
the hosts in the fixed network should avoid to retrieve
data from hosts in the mobile networks, and hosts in the
mobile networks should prefer the data retrieval from the
hosts in the fixed networks.</t>
</section>
<section anchor="sec.ISP_deployment_req_other" title="Other Requirements">
<t>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.</t>
<t>Still, ISPs may have other important requirements when
deploying ALTO: In particular, an ISP may not be willing
to expose sensitive operational details of its
network. The topology abstraction of ALTO enables an ISP
to expose the network topology at a desired granularity
only.</t>
</section>
</section>
<section anchor="sec.ISP_deployment2" title="Considerations for Different Types of ISPs">
<section title="Very small ISPs with simple Network Structure">
<t>
For very small ISPs, the traffic optimizing problem they focus is that how to decrease
the traffic exchanging with other ISPs, because of high settlement costs. To use the ALTO
service to optimize traffic, small ISPs can define two optimization areas: one
is their own network; the other is all outer networks connected with their network.
The cost map can be defined like this: the cost of link between clients of inner
ISP's networks is lower than from clients of outer ISP's networks to clients of
inner ISP's networks. So the client of this ISP will prefer to require data from
the clients in the same ISP with high priority.
</t>
<t>One example is given as below in <xref target="fig.small_ISPs3"/>. ISP A is one small ISP, only having one access
network. In ALTO service deploying, we can define ISP A 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 link cost in inner ISP A. C2 is denoted as the link cost
from PID2 to PID1. We define the cost map as:
</t>
<t>C1<C2 </t>
<figure anchor="fig.small_ISPs3"
title="ALTO deployment in small ISPs">
<artwork><![CDATA[
-----------
//// \\\\
// \\
// \\ /-----------\
| +---------+ | //// \\\\
| | ALTO | ISP A | C2 | Other Networks |
| | Service | PID 1 <----------- PID 2
| +---------+ C1 | | |
| | \\\\ ////
\\ // \-----------/
\\ //
\\\\ ////
-----------
]]></artwork>
</figure>
</section>
<section title="Large ISPs with a Fixed Network">
<t>For large ISPs with fixed network, the traffic
optimizing problems they focus will include that: using backbone
network by high-efficiency, adjusting traffic balance in different
access networks according to traffic conditions and management
policies, and considering settlement cost with other ISPs. So in
ALTO service deploying to this kind of large ISP, first the
optimization area can be defined according to real network
condition. For example, each access network can be defined to
be one optimization area. Then cost can be defined according to
the optimizing requirement by ISPs. There is one example described
below and also shown in <xref target="fig.large_ISPs"/>.
</t>
<t>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 of backbone network
in inner ISP A; and the second requirement is to decrease the P2P
traffic to outer ISPs. Always, the second requirement is prior to
the first one. Also, we assume that the settlement rate with ISP B
is lower than with other ISPs. Then ISP A can deploy ALTO service
to meet the need of traffic optimization. We will give the detail
example of ALTO service definition and configuration according to
requirements above.
</t>
<t>In inner network of ISP A, we can define each access network to
be one optimization area, and assign one PID to every access network,
such as PID1, PID2, and PID 3. Because of different settlement with
different outer ISPs, we define ISP B to be one optimization area,
and assign PID 4 to it, as well as define all other networks to be
one optimization area and PID 5.
</t>
<t>We assign cost names (C1, C2, C3, C4, C5, C6, C7) as the figure
below. C1 is denoted as the link cost in inner AN A, the same as C2
and C3. C4 is denoted as the link cost from PID 1 to PID 2, the same
as C5. C6 is denoted as the link cost from the ISP B to ISP A. C7 is
denoted as the link cost from other networks to ISP A.
</t>
<t> According to discussion of the first requirement and the second
requirement above, the relationship of these costs will be defined as:
(C1, C2, C3) < (C4, C5) < (C6) < (C7)
</t>
<t>This is one very simple example above, in which we do not consider
the different link type of access network. In deploying ALTO service
in real network, we must consider more real network conditions and
requirements. One real example is described in greater detail in
<xref target="I-D.lee-alto-chinatelecom-trial"></xref>.
</t>
<figure anchor="fig.large_ISPs" title="ALTO deployment in large ISPs with layered
fixed network structures">
<artwork><![CDATA[
+------------------------------------+ +----------------+
| ISP A +---------------+ | | |
| | Backbone | | C6 | ISP B |
| +--+ Network +---+ |<--------+ PID 4 |
| | +-------+-------+ | | | |
| | | | | | |
| | | | | +----------------+
| +---+--+ +--+---+ +-+----+ |
| |AN A | C4 |AN B | C5 |AN C | |
| |PID 1 +--->|PID 2 |<----+PID 3 | |
| |C1 | |C2 | |C3 | | +----------------+
| +---+--+ +---+--+ +-+----+ | | |
| | C7 | Other Networks |
| |<--------+ PID 5 |
| | | |
| | | |
+------------------------------------+ +----------------+
]]></artwork>
</figure>
</section>
<section title="ISPs with Mobile Network">
<t>For ISPs with mobile network and fixed network, the traffic
optimizing problems they focus will be optimizing the mobile traffic,
except problems on last hop section. Wireless radio frequency resource
is scarce and costly in mobile network. The requirement of traffic
optimization in mobile network is mainly decreasing the usage of radio
resource. The ALTO service can be deployed to meet these needs.
</t>
<t>For example in one ISP A as below in <xref target="fig.mobile_ISPs2"/>,
there is one mobile network
is connected to backbone network. In this kind of network structure,
mobile network can be defined as one optimization area, and assigned
PID 1. We also define other PID and cost as figure below.
</t>
<t>To decrease the usage of wireless link, the relationship of these
costs will be defined to:
</t>
<t>From view of mobile network:(C4 < C1). This means that, the
clients in mobile network requiring data resource from clients of
the other access networks is prior to clients of mobile network.
This policy can decrease the usage of wireless link and power
consumption in terminal.
</t>
<t>From view of AN A:(C2 < C6, C5 = maximum cost). This means that,
to other optimization area, requiring data from mobile network should
be avoided.
</t>
<figure anchor="fig.mobile_ISPs2" title="ALTO deployment in ISPs with mobile network">
<artwork><![CDATA[
+-----------------------------------------------------------------+
| |
| ISP A +-------------+ |
| +--------+ ALTO +---------+ |
| | | Service | | |
| | +------+------+ | |
| | | | |
| | | | |
| | | | |
| +-------+-------+ | C6 +--------+------+ |
| | AN A |<-------------- AN B | |
| | PID 2 | C7 | | PID 3 | |
| | C2 -------------->| C3 | |
| +---------------+ | +---------------+ |
| ^ | | | ^ |
| | | | | | |
| | |C4 | | | |
| C5 | | | | | |
| | | +--------+---------+ | | |
| | +-->| Mobile Network |<---+ | |
| | | PID 1 | | |
| +------- | C1 |----------+ |
| +------------------+ |
+-----------------------------------------------------------------+
]]></artwork>
</figure>
</section>
</section>
</section>
<section anchor="sec.p2p_cons" title="Using ALTO for P2P">
<figure anchor="fig.global_tracker"
title="Global tracker accessing ALTO server at various ISPs">
<artwork><![CDATA[ ,-------.
,---. ,-' `-. +-----------+
,-' `-. / 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
]]></artwork>
</figure>
<t><xref target="fig.global_tracker"></xref> depicts a
tracker-based system, where 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 <xref
target="I-D.ietf-alto-server-discovery"></xref>. However, the
peers do not have any way to query the server themselves. This
setting allows to give 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.</t>
<t><figure anchor="fig.localALTOServer"
title="Global Tracker - Local ALTO Servers">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' `-. +==>| 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
]]></artwork>
</figure>The scenario in <xref target="fig.localALTOServer"></xref>
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.</t>
<t><figure anchor="fig-p4p_approach"
title="P4P approach with local tracker and local ALTO server">
<artwork><![CDATA[
,-------. +-----------+
,---. ,-' 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
]]></artwork>
</figure></t>
<t>There are some attempts to let ISP's to deploy their own trackers, as
shown in <xref target="fig-p4p_approach"></xref>. 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.</t>
<t><xref target="fig-p4p_approach"></xref> and <xref
target="fig.global_tracker"></xref> 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 <xref
target="fig.localALTOServer"></xref>.</t>
<section anchor="sec.alto_in_tracker_p2p" title="Using ALTO for Tracker-based Peer-to-Peer Applications">
<t>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.</t>
<t>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.</t>
<t>The ALTO protocol specification
<xref target="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:</t>
<t><list style='numbers'>
<t>ALTO client in the resource consumer ("peer")</t>
<t>ALTO client in the resource directory ("tracker")</t>
</list></t>
<t>In the following, both scenarios are compared in order to
explain the need for third-party ALTO queries.</t>
<t>In the first scenario (see <xref target="fig.rcq"/>),
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.</t>
<t>In the second scenario (see <xref target="fig.3pq"/>),
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).</t>
<t>
<figure anchor="fig.tracker_random_preselect"
title="Tracker-based P2P Application with random peer preselection">
<artwork><![CDATA[
............................. .............................
: 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 |
+-______-+
]]></artwork>
</figure></t>
<t><figure anchor="fig.rcq"
title="Basic message sequence chart for
resource consumer-initiated ALTO query">
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
<t>
<figure anchor="fig.tracker_alto_client"
title="Tracker-based P2P Application with ALTO client in tracker">
<artwork><![CDATA[
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : :
: | | +--------+ : P2P App. : k good peers & +------+ :
: | N | | ALTO- | : Protocol : n-k bad peers | data | :
: | known |====>| biased |******************************>| ex- | :
: | peers, | | peer | : transmit : | cha- | :
: | M good | | select | : n peer : | nge | :
: +-______-+ +--------+ : IDs : +------+ :
:.....................^.....: :...........................:
|
| ALTO
| client protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
]]></artwork>
</figure></t>
<t><figure anchor="fig.3pq"
title="Basic message sequence chart for third-party ALTO query">
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
<t>Note: the message sequences depicted in
<xref target="fig.rcq"/> and <xref target="fig.3pq"/> may occur
both in the target-aware and the target-independent query mode
(c.f. <xref target="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.</t>
<t>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.</t>
<t>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.</t>
<t>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:</t>
<t><figure><artwork><![CDATA[
/ 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)!
]]></artwork></figure></t>
<t>The probability that the reply contains at most k "good"
peers is: P(X<=k)=P(X=0)+P(X=1)+..+P(X=k).</t>
<t>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.</t>
<t>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
"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.) </t>
<t>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 the that respective peer.</t>
</section>
<section anchor="sec.alto_p2p_expectations" title="Expectations of ALTO">
<t>This section hints to some recent experiments conducted with
ALTO-like deployments in Internet Service Provider (ISP) network's.
NTT performed tests with their HINT server implementation and dummy
nodes to gain insight on how an ALTO-like service influence a
peer-to-peer systems <xref
target="I-D.kamei-p2p-experiments-japan"></xref>. The results of an
early experiment conducted in the Comcast network are documented
here<xref target="RFC5632"></xref></t>
</section>
</section>
<section anchor="sec.cdn_cons" title="Using ALTO for CDNs">
<t><xref target="sec.general_deployment"></xref> discussed the
placement and usage of ALTO for P2P systems, but not
beyond. This section discuss the usage of ALTO for Content
Delivery Networks (CDNs) <xref
target="I-D.jenkins-alto-cdn-use-cases"></xref>. 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 <xref target="RFC3568"></xref>.</t>
<t>The general issue for CDNs, independent of DNS or HTTP Redirect based
approaches (see, for instance, <xref
target="I-D.penno-alto-cdn"></xref>), 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 <xref
target="I-D.vandergaast-edns-client-ip"></xref> for a discussion of this
and a solution approach).</t>
<section title="Request Routing using the Endpoint Cost Service">
<t>Alternatively, the Request Router may request the Endpoint service
from the ALTO client.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section title="ALTO Topology Vs Network Topology">
<t>The ALTO server builds a ALTO-specific network topology that
represents the network as it should be understood and utilized by
the
application layer (the CDN). 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 visibility of the network, and which level of granularity,
it
is required by the CDN and more in general by the application layer.
</t>
<t>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. 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).</t>
</section>
<section title="Topology Computation and ECS Delivery">
<t>ECS allows the CDN 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. Thus ECS is used in
order to implement a lightweight integration of ALTO services in
the CDN layer. ECS implies an ALTO and CDN implementation with the
necessary scalability in order to cope with the amount of
transactions that CDN and ALTO server will have to handle (knowing
that the CDN is able to cache ALTO ECS results for further use).
</t>
<t>The ALTO server delivering ECS may integrate various information
sources such as routing topology, policies, state and performance,
geo-location, etc, and deliver the ranking service to the CDN upon
request. The network topology information is controlled, managed
by the ALTO server and the CDN benefits from ranking services in
order to optimize application layer mechanisms used for content
location selection. This allows the ALTO server to enhance and
modify the way the topology information sources are used and
combined without requiring any update in the mechanisms the ECS
is delivered and do not require any update process between ALTO and
the CDN.</t>
</section>
<section title="Ranking Service">
<t>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
request and ranks the list of content targets addresses based on
their distance from the content requester. By default, according to
<xref target="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).</t>
<t>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.</t>
</section>
<section title="Ranking and Network Events">
<t>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.</t>
</section>
<section title="Caching and Lifetime">
<t>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.</t>
<t>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.</t>
</section>
<section title="Redirection">
<t>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:
<list style="symbols">
<t>Reply with available information (best effort).</t>
<t>Redirect the request to another ALTO server presumed to have
better topology information (redirection).</t>
<t>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.</t>
</list>
</t>
<t>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).</t>
</section>
<section title="Groups and Costs">
<t>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 SP networks use in order to exchange information
about their prefix reachability. BGP Community us an attribute used
to tag a prefix so to group prefixes based on mostly any criteria
(as
an example, most SP networks originate BGP prefixes with communities
identifying the Point of Presence (PoP) where the prefix has been
originated).</t>
<t>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 to set between
groups. Alternatively, there are algorithms that allows a dynamic
computation of cost between groups.</t>
</section>
</section>
</section>
<section anchor="sec.advanced" title="Advanced Features">
<section anchor="advanced" title="Cascading ALTO Servers">
<t>The main assumptions of ALTO seems to be each ISP operates its own
ALTO server independently, irrespectively of the ISP's situation. This
may true for most envisioned deployments of ALTO but there are certain
deployments that may have different settings. <xref
target="fig-alto-proxy"></xref> shows such setting, were for example, a
university network is connected to two upstream providers. ISP2 if 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.</t>
<t><figure anchor="fig-alto-proxy" title="Cascaded ALTO Server">
<artwork><![CDATA[
+-----------+
| ISP1 |
| ALTO |
| Server |
+----------=+
,-------= ,------.
,-' =`-. ,-' `-.
/ Upstream= \ / Upstream \
( ISP1 = ) ( ISP2 )
\ = / \ /
`-. =,-' `-. ,-'
`---+---= `+------'
| = |
| =======================
|,-------------. | =
,-+ `-+ +-----------+
,' University `. |University |
( Network ) | ALTO |
`. =======================| Server |
`-= +-' +-----------+
=`+------------'|
= | |
+--------+-+ +-+--------+
| Peer1 | | PeerN |
+----------+ +----------+
]]></artwork>
</figure></t>
<t>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 can be called cascaded ALTO servers.</t>
</section>
<section anchor="sec.v4v6" title="ALTO for IPv4 and IPv6">
<t>TBD</t>
</section>
<section anchor="sec.monitoring" title="Monitoring ALTO">
<t>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.</t>
<t>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.</t>
<t>[Editor's note: Is there a relationship to the IPPM working group
at the IETF?]</t>
<section title="Monitoring Metrics Definition">
<t><list style='symbols'>
<t>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.</t>
<t>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.</t>
<t>Intra-domain ALTO-Integrated Application Traffic (Network metric).
(XXX description missing)</t>
<t>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).</t>
<t>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.</t>
<t>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.</t></list>
</t>
</section>
<section title="Monitoring Data Sources">
<t>The preceding metrics are derived from data sources. We identify three data
sources.</t>
<t><list style='numbers'>
<t>Application Log Server: Many application systems deploy Log Servers to
collect data.</t>
<t>P2P Clients: Some P2P applications may not have Log Servers. When available,
P2P client logs can provide data. This is for P2P application</t>
<t>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.</t>
</list>
</t>
</section>
<section title="Monitoring Structure">
<t>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.</t>
<t><figure anchor="fig.alto-monitoring" title="Monitoring Structure">
<artwork><![CDATA[
+------------------------------------------------+
| |
| New Entities +--------------------------------------+
| | Service Provider |
| | (P2P/CDN Operator etc)|
| +-----------+ | +-----------+ | |
| |ALTO Server|-------------|ALTO Client| | |
| +-----------+ | +-----------+ | |
| | | +----------+ |
| | | |Log Server| |
| | | +----------+ |
| +--------------+ | +--------------+ | +----------+ |
| |Monitor Server|----------|Monitor Client| | |P2P Client| |
| +--------------+ | +--------------+ | +----------+ |
| | | | |
| +--------|--------+ +--------------------------------------+
+-|--------|--------|----------------------------+
| | |
| | |
| +---+ |
| |OAM| |
| +---+ |
| ISP |
-----------------
]]></artwork>
</figure></t>
</section>
</section>
</section>
<section anchor="risks" title="Known Limitations of ALTO">
<t>This section describes some known limitations of ALTO in general or
specific mechanisms in ALTO.</t>
<section title="Limitations of Map-based Approaches">
<t>The specification of the ALTO protocol <xref
target="I-D.ietf-alto-protocol"></xref> uses, amongst others
mechanism, 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 Host Group Descriptor. A set of IP prefixes is
called partition and the associated Host Group Descriptor is called
partition ID. The "costs" between the various partition IDs is stored
in a second map, the cost map. Map-based approaches are chosen as they
lower the signaling load on the server, as the maps have only to be
retrieved if they are changed.</t>
<t>The 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:</t>
<t><list style="numbers">
<t>ISPs reallocate IPv4 subnets from time to time;</t>
<t>ISPs reallocate IPv4 subnets on short notice;</t>
<t>IP prefix blocks may be assigned to a router that serves
a variety of access networks;</t>
<t>Network costs between IP prefixes may change depending
on the ISP's routing and traffic engineering.</t>
</list></t>
<!-- text below is a copy of Rich Woundy's comment -->
<t>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. <list
style="hanging">
<t>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.</t>
</list> However, this is not an issue for map-based approaches if
changes are applied in the order of days.</t>
<!-- text above is a copy of Rich Woundy's comment -->
<t>For 2): ISPs can use techniques, such as ODAP (XXX) 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 reallocate to areas where there is currently a high
demand for IP addresses.</t>
<t>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
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.</t>
<!-- Below: Michael's comments -->
<t>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.</t>
</section>
<section title="Limitiations of Non-Map-based Approaches">
<t>The specification of the ALTO protocol <xref
target="I-D.ietf-alto-protocol"></xref> uses, amongst others
mechanism, a mechanism called Endpoint Cost Service. 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.</t>
<t>Caching of IP addresses at the ALTO client or the usage of the H12
approach <xref target="I-D.kiesel-alto-h12"></xref> in conjunction
with caching may lower the query load on the ALTO server.</t>
</section>
<section title="General Challenges">
<t>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. However, there are basically two different
approaches on where the preferences are actually processed:<list
style="numbers">
<t>The ALTO server has a list of preferences and clients can
retrieve this list via the ALTO protocol. This preference list can
be partially 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 .</t>
<t>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.</t>
</list></t>
<t>Approach 1 (we call it H1) 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, does
approach 1 require 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.</t>
<t>Approach 2 (we call it H2) 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, does
approach 2 require that the clients send their operational information
to the server.</t>
<t>Both approaches have their pros and cons. In case of
peer-to-peer networks, there is basically a dilemma: Approach
1 is seen as the only working solution by peer-to-peer
software vendors and approach 2 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.</t>
</section>
</section>
<section title="Extensions to the ALTO Protocol">
<t>This section lists possible future extensions to the ALTO
protocol.</t>
<section anchor="host_group_descriptors" title="Host Group
Descriptors">
<t>Host group descriptors are used in the ALTO client protocol
to describe the location of a host in the network topology.
The ALTO client protocol specification defines a basic set of
host group descriptor types, which have to be supported by all
implementations, and an extension procedure for adding new descriptor
types <!--(see <xref target="req_acp_hla"/>)-->.
The following list gives an overview on further host group
descriptor types that have been proposed in the past, 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 descriptor types that have been
proposed so far, and to solicit further feedback and discussion:</t>
<t><list style='symbols'>
<t>Autonomous System (AS) number</t>
<t>Protocol-specific group identifiers, which expand to a set of
IP address ranges (CIDR) and/or AS numbers. In one specific
solution proposal, these are called Partition ID (PID).</t>
</list></t>
</section>
<section anchor="rating_criteria" title="Rating Criteria">
<t>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
<!--(see <xref target="req_acp_rc"/>)-->.
The following list gives an overview on further rating criteria
that have been proposed in the past, 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:</t>
<section anchor="rating_criteria_distance"
title="Distance-related Rating Criteria">
<t><list style='symbols'>
<t>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.</t>
<t>Absolute topological distance, expressed in the number of
traversed autonomous systems (AS).</t>
<t>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).</t>
<t>Absolute physical distance, based on knowledge of the
approximate geolocation (continent, country) of an IP
address.</t>
</list></t>
</section>
<section anchor="rating_criteria_charging"
title="Charging-related Rating Criteria">
<t><list style='symbols'>
<t>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.</t>
</list></t>
</section>
<section anchor="rating_criteria_performance"
title="Performance-related Rating Criteria">
<t>The following rating criteria are subject to the remarks below.</t>
<t><list style='symbols'>
<t>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</t>
<t>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.</t>
<t>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</t>
<t>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. </t>
</list></t>
<t>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.</t>
<t>The discrepancies are due to various reasons, including,
but not limited to the facts that</t>
<t><list style='symbols'>
<t>the ALTO service is not an admission control system</t>
<t>the ALTO service may not know the instantaneous congestion
status of the network</t>
<t>the ALTO service may not know all link bandwidths, i.e.,
where the bottleneck really is, and there may be shared
bottlenecks</t>
<t>the ALTO service may not know whether the candidate peer
itself is overloaded</t>
<t>the ALTO service may not know whether the candidate peer
throttles the bandwidth it devotes for the considered
application</t>
<t>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)</t>
</list></t>
<t>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.</t>
</section>
<section anchor="rating_criteria_inappropriate"
title="Inappropriate Rating Criteria">
<t>Rating criteria that SHOULD NOT be defined for and used by the
ALTO service include:</t>
<t><list style='symbols'>
<t>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.</t>
<!--
<t>The provisioned access bandwidth, e.g. of cable / DSL
customers. This has been proposed several times and questioned,
because of problems with privacy, fears that "premium" customers
with high access bandwidth might attract so much traffic that
their service becomes de-facto worse, etc.</t>
-->
</list></t>
</section>
</section>
</section>
<section anchor="AC_API" title="API between ALTO Client and Application">
<t>This sections gives some informational guidance on how the interface
between the actual application using the ALTO guidance and the ALTO
client can look like.</t>
<t>This is still TBD.</t>
</section>
<section title="Security Considerations">
<t>The ALTO protocol itself, as well as, the ALTO client and server
raise new security issues beyond the one mentioned in <xref
target="I-D.ietf-alto-protocol"></xref> 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.</t>
<t>This section is solely giving a first shot on security issues related
to ALTO deployments.</t>
<section title="Information Leakage from the ALTO Server">
<t>The ALTO server will be provisioned with information about the
owning ISP's network and very likely also with information about
neighboring ISPs. This information (e.g., network topology, business
relations, etc) is consider to be confidential to the ISP and must not
be revealed.</t>
<t>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.</t>
</section>
<section title="ALTO Server Access">
<t>Depending on the use case of ALTO, several access restrictions to
an ALTO server may or may not apply.</t>
<t>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 <xref
target="fig.localALTOServer"></xref>). 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).</t>
<t>If the ALTO server has to be accessible by parties not
located in the ISP's network (see Figure <xref
target="fig.global_tracker"></xref>), e.g., by a third-party
tracker or by a CDN system outside the ISP's network, the
access restrictions have to be more loose. In the extreme
case, i.e., no access restrictions, each and every host in the
Internet can access the ALTO server. This might no 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.</t>
<t>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.</t>
</section>
<section title="Faking ALTO Guidance">
<t>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.</t>
<t>Here is a list of examples how the ALTO guidance could be faked and
what possible consequences may arise: <list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
</section>
</section>
<section title="Conclusion">
<t>This is the first version of the deployment considerations and for
sure the considerations are yet incomplete and imprecise.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3568" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6708" ?>
<?rfc include="reference.I-D.ietf-alto-protocol" ?>
<?rfc include="reference.RFC.5693" ?>
<?rfc include="reference.I-D.ietf-alto-server-discovery"?>
<?rfc include="reference.I-D.vandergaast-edns-client-ip"?>
<?rfc include="reference.I-D.penno-alto-cdn"?>
<?rfc include="reference.I-D.kamei-p2p-experiments-japan"?>
<?rfc include="reference.I-D.kiesel-alto-h12"?>
<?rfc include="reference.RFC.5632"?>
<?rfc include="reference.I-D.lee-alto-chinatelecom-trial"?>
<?rfc include="reference.I-D.jenkins-alto-cdn-use-cases"?>
</references>
<section title="Contributors List and Acknowledgments">
<t>This memo is the result of contributions made by several people,
such as:
<list style="symbols">
<t>Xianghue Sun, Lee Kai, and Richard Yang contributed
<xref target="sec.ISP_deployment"/> and
<xref target="sec.monitoring"/>.</t>
<t>Stefano Previdi contributed Section <xref target="sec.cdn_cons"/>
on "Using ALTO for CDNs". </t>
</list>
</t>
<t> 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.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:22 |