One document matched: draft-ietf-alto-deployments-08.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-08"
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 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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <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 title="General Considerations">
<section title="ALTO Entities">
<section anchor="sec.general_deployment" title="Baseline Scenario">
<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>
<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 edonkey.</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 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
<xref target="sec.p2p_cons"></xref>.</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, as discussed
in <xref target="sec.cdn_cons"></xref>.</t>
</section>
</section>
<section anchor="sec.alto_apps" title="Classification of Deployment Scenarios">
<section anchor="sec.alto_classification" title="Deployment Degrees of Freedom">
<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>ALTO deployments can be differentiated e.g. according to
the following aspects:</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</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 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 <xref
target="RFC6708"/>).</t>
</section>
<section title="Information Exposure Models">
<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. There
are basically two different approaches on where the
preferences are actually processed:</t>
<t><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 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 .</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 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.</t>
<t>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).</t>
<t>Both approaches have their pros and cons, as detailed in
<xref target="risks"></xref>.</t>
</section>
<section title="More Advanced Deployments">
<t>From an ALTO client's perspective, there are two fundamental
ways to use ALTO:</t>
<t><list style="numbers">
<t>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 <xref
target="I-D.ietf-alto-server-discovery"></xref>.</t>
<t>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.</t>
</list></t>
<t>There are also different options regarding the guidance
offered by an ALTO server:</t>
<t><list style="numbers">
<t>Authorative servers: An ALTO server instance can provide
guidance for all destinations for all kinds of ALTO
clients.</t>
<t>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.</t>
<t>Inter-server synchronization: Different ALTO servers
my communicate by other means. This approach is not further
discussed in this document.</t>
</list></t>
<!--<section anchor="advanced" title="Cascading ALTO Servers">-->
<t>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. <xref target="fig-alto-proxy"></xref> 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.</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 is an example for
cascaded ALTO servers.</t>
<!--</section>-->
</section>
</section>
</section>
<section anchor="sec.ISP_deployment_req_general" title="Deployment Considerations by ISPs">
<section anchor="sec.guidance" title="Objectives for the Guidance to Applications">
<!--<section anchor="sec.ISP_deployment" title="Motivation for Traffic Optimization">-->
<section anchor="sec.ISP_deployment_req" title="General Objectives for Traffic Optimization">
<t>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.</t>
<t>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.</t>
<t>ALTO enables ISPs to perform traffic engineering by
influencing application resource selections. This traffic
engineering can have different objectives:</t>
<t><list style='numbers'>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Application tuning: ALTO is also a powerful tool to
optimize the performance of applications that depend on
the network and perform resource selection decisions.</t>
</list></t>
<t>In the following, these objectives are explained in more
detail with deployment examples.</t>
</section>
<section title="Inter-Network Traffic Localization">
<!--<section title="Keeping Traffic Local in a Network">-->
<t>ALTO guidance can be used to keep traffic local in a
network. An ALTO server can 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 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). <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="Intra-Network Traffic Localization">
<!--<section title="Objective: 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 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. <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. If Host 1 and Host 2 exchange their data
with remote hosts, they would probably congest 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>
</section>
<section title="Network Off-Loading">
<!--<section title="Objective: Off-Loading Traffic from Network"> -->
<t>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.</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></t>
<t><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="Application Tuning">
<t>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.</t>
</section>
</section>
<section title="Provisioning of ALTO Maps">
<section title="Data Sources">
<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>
<!-- ALTO Topology Vs Network Topology -->
<t>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.</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. 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.</t>
</section>
<section anchor="sec.ISP_deployment_req_other" title="Privacy 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>
<t>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.</t>
<t>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 <xref
target="host_group_descriptors"/>.</t>
</section>
<section anchor="host_group_descriptors" title="Map Partitioning and Grouping">
<t>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).</t>
<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.</t>
<t>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).</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 defined between groups. Alternatively, there
are algorithms that allows a dynamic computation of cost
between groups.</t>
</section>
<section anchor="rating_criteria" title="Rating Criteria and/or Cost Calculation">
<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.</t>
<t>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.</t>
<!--<section anchor="rating_criteria_distance"
title="Distance-related Rating Criteria">-->
<t>Distance-related rating criteria:</t>
<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>Charging-related rating criteria:</t>
<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>Performance-related rating criteria:</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>These rating criteria are subject to the remarks below:</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="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 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.</t>
<t>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:</t>
<t><list style="numbers">
<t>ISPs reallocate IP subnets from time to time;</t>
<t>ISPs reallocate IP 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.</t>
<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>
<t>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 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.</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
(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.</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>
<section anchor="sec.ISP_deployment2" title="Map Examples for Different Types of ISPs">
<section title="Small ISP with Single Internet Uplink">
<t>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.</t>
<t>An example is given in <xref
target="fig.small_ISPs3"/>. 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</t>
<figure anchor="fig.small_ISPs3"
title="Example ALTO deployment in small ISPs">
<artwork><![CDATA[
-----------
//// \\\\
// \\
// \\ /-----------\
| +---------+ | //// \\\\
| | ALTO | ISP A | C2 | Other Networks |
| | Service | PID 1 <----------- PID 2
| +---------+ C1 | | |
| | \\\\ ////
\\ // \-----------/
\\ //
\\\\ ////
-----------
]]></artwork>
</figure>
<t>A simplified extract of the corresponding ALTO network
and cost maps is listed in <xref
target="fig.small_ISP_network_map"/> and <xref
target="fig.small_ISP_cost_map"/>, 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.</t>
<figure anchor="fig.small_ISP_network_map"
title="Example ALTO network map">
<artwork><![CDATA[
HTTP/1.1 200 OK
...
Content-Type: application/alto-networkmap+json
{
...
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
]]></artwork>
</figure>
<figure anchor="fig.small_ISP_cost_map"
title="Example ALTO cost map">
<artwork><![CDATA[
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 },
}
}
]]></artwork>
</figure>
</section>
<section title="ISP with Several Fixed Access Networks">
<t>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.</t>
<t>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 <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 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.</t>
<t>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.</t>
<t>We assign costs (C1, C2, C3, C4, C5, C6, C7, C8) as shown
in <xref target="fig.large_ISPs"/>. 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.</t>
<t>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)</t>
<figure anchor="fig.large_ISPs"
title="ALTO deployment in large ISPs with layered fixed network structures">
<artwork><![CDATA[
+------------------------------------+ +----------------+
| ISP A +---------------+ | | |
| | Backbone | | C7 | ISP B |
| +--+ Network +---+ |<--------+ PID 4 |
| | +-------+-------+ | | | |
| | | | | | |
| | | | | +----------------+
| +---+--+ +--+---+ +-+----+ |
| |AN A | C4 |AN B | C5 |AN C | |
| |PID 1 +<-->|PID 2 |<--->+PID 3 | |
| |C1 | |C2 | |C3 | | +----------------+
| +---+--+ +------+ +-+----+ | | |
| | | | C8 | Other Networks |
| +----------------------+ |<--------+ PID 5 |
| C6 | | |
| | | |
+------------------------------------+ +----------------+
]]></artwork>
</figure>
</section>
<section title="ISP with Fixed and Mobile Network">
<t>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.</t>
<t><xref target="fig.mobile_ISPs2"/> 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 <xref target="fig.mobile_ISPs2"/>.</t>
<t>To decrease the usage of wireless link, the relationship
of these costs can be defined as follows:</t>
<t>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.</t>
<t>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.</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 anchor="sec.alto_p2p_expectations" title="Deployment Experiences">
<t>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 <xref
target="I-D.lee-alto-chinatelecom-trial"></xref>.</t>
<t>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 <xref
target="I-D.kamei-p2p-experiments-japan"></xref>. The results
of an early experiment conducted in the Comcast network are
documented in <xref target="RFC5632"></xref>.</t>
</section>
</section>
<section anchor="sec.p2p_cons" title="Using ALTO for P2P Traffic Optimization">
<section title="Overview">
<section title="Usage Scenario">
<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>
<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, 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 <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 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.</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></t>
<t>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>
<section title="Applicability of ALTO">
<t>TODO</t>
</section>
</section>
<section title="Deployment Recommendations">
<section title="ALTO Services">
<t>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.</t>
</section>
<section anchor="sec.alto_in_tracker_p2p" title="Guidance Considerations">
<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 that respective peer.</t>
</section>
</section>
</section>
<section anchor="sec.cdn_cons" title="Using ALTO for CDNs">
<section title="Overview">
<section title="Usage Scenario">
<t>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>
<section title="Applicability of ALTO">
<t>TODO: Rewording required</t>
<!-- 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>
<!-- Request Routing using the Endpoint Cost Service -->
<t>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>
</section>
<section title="Deployment Recommendations">
<section title="ALTO Services">
<!-- 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:</t>
<t><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="Guidance Considerations">
<!--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>
<!-- 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>
</section>
<section title="Other Use Cases">
<t>This section briefly surveys and references other use cases that have been suggested for ALTO.</t>
<section title="Monitoring Data Reporting">
<t>TODO</t>
</section>
<section title="Virtual Private Networks (VPNs)">
<t>TODO</t>
</section>
<section anchor="sec.p2pcache" title="In-Network Caching">
<t>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 <xref
target="I-D.deng-alto-p2pcache"></xref>.</t>
<t><figure anchor="fig.p2pcache"
title="General architecture of intra-ISP caches">
<artwork><![CDATA[
+--------------+ +------+
| 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 | | | | | | |
| | +---------+ | | | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | | |
+--------+--------------------+----------------------+----------+
| | |
+---+---+ +---+---+ |
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|Peer2| |Peer3| |Peer4| |Peer5| |Peer6|
+-----+ +-----+ +-----+ +-----+ +-----+
]]></artwork>
</figure></t>
<t><xref target="fig.p2pcache"/> 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 <xref
target="I-D.deng-alto-p2pcache"></xref>.</t>
<t>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.</t>
<t>Further details and deployment considerations can be found
in <xref target="I-D.deng-alto-p2pcache"></xref>.</t>
</section>
</section>
<section title="Security Considerations">
<t>The ALTO protocol itself as well as the ALTO client and
server raise new security issues beyond the ones 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 considered 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 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.</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:</t>
<t><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 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.</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"?>
<?rfc include="reference.I-D.deng-alto-p2pcache"?>
</references>
<section anchor="sec.monitoring" title="Appendix: 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 anchor="AC_API" title="Appendix: API between ALTO Client and Application">
<t>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.</t>
<t>This is still TBD.</t>
</section>
<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 text
on ISP deployment requirements and monitoring.</t>
<t>Stefano Previdi contributed parts of the <xref
target="sec.cdn_cons"/> on "Using ALTO for CDNs".</t>
<t>Rich Woundy contributed text to <xref
target="risks"/>.</t>
<t>Lingli Deng, Wei Chen, Qiuchao Yi, Yan Zhang contributed
<xref target="sec.p2pcache"/>.</t>
<t>Thomas-Rolf Banniza carefully reviewed the document.</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 02:56:30 |