| ALTO | M. Stiemerling, Ed. |
| Internet-Draft | NEC Europe Ltd. |
| Intended status: Informational | S. Kiesel, Ed. |
| Expires: April 24, 2014 | University of Stuttgart |
| S. Previdi | |
| Cisco | |
| M. Scharf | |
| Alcatel-Lucent Bell Labs | |
| October 21, 2013 |
ALTO Deployment Considerations
draft-ietf-alto-deployments-08
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer (P2P) file sharing applications and Content Delivery Networks (CDNs). The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates, which are able to provide a desired resource. The basic ideas and problem space of ALTO is described in [RFC5693] and the set of requirements is discussed in [RFC6708].
However, there are no considerations about what operational issues are to be expected once ALTO will be deployed. This includes, but is not limited to, location of the ALTO server, imposed load to the ALTO server, or from whom the queries are performed.
Comments and discussions about this memo should be directed to the ALTO working group: alto@ietf.org.
The ALTO protocol [I-D.ietf-alto-protocol] is a client/server protocol, operating between a number of ALTO clients and an ALTO server, as sketched in Figure 1.
+----------+
| ALTO |
| Server |
+----------+
^
_.-----|------.
,-'' | `--.
,' | `.
( Network | )
`. | ,'
`--. | _.-'
`------|-----''
v
+----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client |
+----------+ +----------+ +----------+
Figure 1: Baseline Deployment Scenario of the ALTO Protocol
The ALTO server and ALTO clients can be situated at various entities in a network deployment. The first differentiation is whether the ALTO client is located on the actual host that runs the application, as shown in Figure 2, or if the ALTO client is located on a resource directory, as shown in Figure 3.
+-----+
=====| |**
==== +-----+ *
==== * *
==== * *
+-----+ +------+===== +-----+ *
| |.....| |======================| | *
+-----+ +------+===== +-----+ *
Source of ALTO ==== * *
topological service ==== * *
information ==== +-----+ *
=====| |**
+-----+
Legend:
=== ALTO client protocol
*** Application protocol
... Provisioning protocol
Figure 2: Overview of protocol interaction between ALTO elements without a resource directory
Figure 2 shows the operational model for applications that do not use a resouce directory. An example would be a peer-to-peer file sharing application that does not use a tracker, such as edonkey.
+-----+
**| |**
** +-----+ *
** * *
** * *
+-----+ +------+ +-----+** +-----+ *
| |.....| |=====| |**********| | *
+-----+ +------+ +-----+** +-----+ *
Source of ALTO Resource ** * *
topological service directory ** * *
information ** +-----+ *
**| |**
+-----+
Legend:
=== ALTO client protocol
*** Application protocol
... Provisioning protocol
Figure 3: Overview of protocol interaction between ALTO elements with a resource directory
In Figure 3, a use case with a resource directory is illustrated, e.g., a tracker in peer-to-peer filesharing. Both deployment scenarios may differ in the number of ALTO clients that access an ALTO service: If ALTO clients are implemented in a resource directory, ALTO servers may be accessed by a limited and less dynamic set of clients, whereas in the general case any host could be an ALTO client. This use case is further detailed in Section 4.
Using ALTO in CDNs may be similar to a resource directory [I-D.jenkins-alto-cdn-use-cases]. The ALTO server can also be queried by CDN entities to get a guidance about where the a particular client accessing data in the CDN is exactly located in the ISP's network, as discussed in Section 5.
ALTO is a general-purpose solution and it is intended to be used by a wide range of applications. This implies that there are different possibilities where the ALTO entities are actually located, i.e., if the ALTO clients and the ALTO server are in the same ISP's domain, or if the clients and the ALTO server are managed/owned/located in different domains.
ALTO deployments can be differentiated e.g. according to the following aspects:
The following sections enumerate different classes of use cases for ALTO, and they discuss the deployment implications of each of them.
However, it must be emphasized that any application using ALTO must also work if no ALTO servers can be found or if no responses to ALTO queries are received, e.g., due to connectivity problems or overload situations (see also [RFC6708]).
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:
Approach 1 has the advantage (seen from the client) that all operational information stays within the client and is not revealed to the provider of the server. On the other hand, approach 1 requires that the provider of the ALTO server, i.e., the network operator, reveals information about its network structure (e.g., AS numbers, IP ranges, topology information in general) to the ALTO client. The ALTO protocol supports this scheme by the Network and Cost Map Service.
Approach 2 has the advantage (seen from the operator) that all operational information stays with the ALTO server and is not revealed to the ALTO client. On the other hand, approach 2 requires that the clients send their operational information to the server. This approach is realized by the ALTO Endpoint Cost Service (ECS).
Both approaches have their pros and cons, as detailed in Section 3.3.
From an ALTO client's perspective, there are two fundamental ways to use ALTO:
There are also different options regarding the guidance offered by an ALTO server:
An assumption of the ALTO solution is that ISP operate ALTO servers independently, irrespectively of other ISPs. This may true for most envisioned deployments of ALTO but there are certain deployments that may have different settings. Figure 4 shows such setting with a university network that is connected to two upstream providers. ISP2 is the national research network and ISP1 is a commercial upstream provider to this university network. The university, as well as ISP1, are operating their own ALTO server. The ALTO clients, located on the peers will contact the ALTO server located at the university.
+-----------+
| ISP1 |
| ALTO |
| Server |
+----------=+
,-------= ,------.
,-' =`-. ,-' `-.
/ Upstream= \ / Upstream \
( ISP1 = ) ( ISP2 )
\ = / \ /
`-. =,-' `-. ,-'
`---+---= `+------'
| = |
| =======================
|,-------------. | =
,-+ `-+ +-----------+
,' University `. |University |
( Network ) | ALTO |
`. =======================| Server |
`-= +-' +-----------+
=`+------------'|
= | |
+--------+-+ +-+--------+
| Peer1 | | PeerN |
+----------+ +----------+
Figure 4: Cascaded ALTO Server
In this setting all "destinations" useful for the peers within ISP2 are free-of-charge for the peers located in the university network (i.e., they are preferred in the rating of the ALTO server). However, all traffic that is not towards ISP2 will be handled by the ISP1 upstream provider. Therefore, the ALTO server at the university has also to include the guidance given by the ISP1 ALTO server in its replies to the ALTO clients. This is an example for cascaded ALTO servers.
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.
The objective of ALTO is to give guidance to applications on what IP addresses or IP prefixes are to be preferred according to the operator of the ALTO server. The ALTO protocol gives means to let the ALTO server operator express its preference, whatever this preference is.
ALTO enables ISPs to perform traffic engineering by influencing application resource selections. This traffic engineering can have different objectives:
In the following, these objectives are explained in more detail with deployment examples.
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). Figure 5 shows such a scenario where hosts prefer hosts in the same network (e.g., Host 1 and Host 2 in ISP1 and Host 3 and Host 4 in ISP2).
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 ########|ALTO Client|
/ \ / # \ +-----------+
/ ISP X \ | # | +-----------+
/ \ \ ########| Host 2 |
; +----------------------------|ALTO Client|
| | | `-. ,-' +-----------+
| | | `-------'
| | | ,-------. +-----------+
: | ; ,-' `########| Host 3 |
\ | / / ISP 2 # \ |ALTO Client|
\ | / / # \ +-----------+
\ +---------+ # | +-----------+
`-. ,-' \ | ########| Host 4 |
`---' \ +------------------|ALTO Client|
`-. ,-' +-----------+
`-------'
Legend:
### preferred "connections"
--- non-preferred "connections"
Figure 5: ALTO Traffic Network Localization
TBD: Describes limits of this approach (e.g., traffic localization guidance is of less use if the peers cannot upload); describe how maps would look like.
The above sections described the results of the ALTO guidance on an inter-network level. However, ALTO can also be used for intra-network localization. In this case, ALTO provides guidance which internal hosts are to be preferred inside a single network or, e.g., one AS. Figure 6 shows such a scenario where Host 1 and Host 2 are located in Net 2 of ISP1 and connect via a low capacity link to the core (Net 1) of the same ISP1. If Host 1 and Host 2 exchange their data with remote hosts, they would probably congest the bottleneck link.
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 #########|ALTO Client|
/ \ / Net 2 # \ +-----------+
/ ISP 1 \ | ######### | +-----------+
/ Net 1 \ \ # / | Host 2 |
; ###; \ # ##########|ALTO Client|
| X~~~~~~~~~~~~X#######,-' +-----------+
| ### | ^ `-------'
| | |
: ; |
\ / Bottleneck
\ /
\ /
`-. ,-'
`---'
Legend:
### peer "connections"
~~~ bottleneck link
Figure 6: Without Intra-Network ALTO Traffic Localization
The operator can guide the hosts in such a situation to try first local hosts in the same network islands, avoiding or at least lowering the effect on the bottleneck link, as shown in Figure 7.
,-------. +-----------+
,---. ,-' `-. | Peer 1 |
,-' `-. / ISP 1 #########|ALTO Client|
/ \ / Net 2 # \ +-----------+
/ ISP 1 \ | # | +-----------+
/ Net 1 \ \ #########| Peer 2 |
; ; \ ##########|ALTO Client|
| #~~~~~~~~~~~########,-' +-----------+
| ### | ^ `-------'
| | |
: ; |
\ / Bottleneck
\ /
\ /
`-. ,-'
`---'
Legend:
### peer "connections"
~~~ bottleneck link
Figure 7: With Intra-Network ALTO Traffic Localization
Another scenario is off-loading traffic from networks. This use of ALTO can be beneficial in particular in mobile broadband networks. The network operator may have the desire to guide hosts in its own network to use hosts in remote networks. One reason can be that the wireless network is not made for the load cause by, e.g., peer-to-peer applications, and the operator has the need that peers fetch their data from remote peers in other parts of the Internet.
,-------. +-----------+
,---. ,-' `-. | Host 1 |
,-' `-. / ISP 1 +-------|ALTO Client|
/ \ / | \ +-----------+
/ ISP X \ | | | +-----------+
/ \ \ +-------| Host 2 |
; #-###########################|ALTO Client|
| # | `-. ,-' +-----------+
| # | `-------'
| # | ,-------. +-----------+
: # ; ,-' `+-------| Host 3 |
\ # / / ISP 2 | \ |ALTO Client|
\ # / / | \ +-----------+
\ ########### | | +-----------+
`-. ,-' \ # +-------| Host 4 |
`---' \ ###################|ALTO Client|
`-. ,-' +-----------+
`-------'
Legend:
=== preferred "connections"
--- non-preferred "connections"
Figure 8: ALTO Traffic Network De-Localization
Figure 8 shows the result of such a guidance process where Host 2 prefers a connection with Host 4 instead of Host 1, as shown in Figure 5.
TBD: Limits of this approach in general and with respect to p2p. describe how maps would look like.
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.
TBD: This section will describe how ALTO maps in the protocol can be populated before using them. The maps can significantly differ depending on the use case, the network architecture, and the trust relationship between ALTO server and ALTO client, etc.
The ALTO server builds an ALTO-specific network topology that represents the network as it should be understood and utilized by the application. Besides the security requirements that consist of not delivering any confidential or critical information about the infrastructure, there are efficiency requirements in terms of what aspects of the network are visible and required by the given use case and/or application.
The ALTO server builds topology (for either Map and ECS services) based on multiple sources that may include routing protocols, network policies, state and performance information, geo-location, etc. The network topology information is controlled and managed by the ALTO server. In all cases, the ALTO topology will not contain any details that would endanger the network integrity and security, e.g., there will be no leaking of OSPF/ISIS/BGP databases to ALTO clients.
Providing ALTO guidance results in a win-win situation both for network providers and users of the ALTO information. Applications possibly get a better performance, while the the network provider has means to optimize the traffic engineering and thus its costs.
Still, ISPs may have other important requirements when deploying ALTO: In particular, an ISP may not be willing to expose sensitive operational details of its network. The topology abstraction of ALTO enables an ISP to expose the network topology at a desired granularity only.
With the ALTO Endpoint Cost Service, the ALTO client does not to have to implement any specific algorithm or mechanism in order to retrieve, maintain and process network topology information (of any kind). The complexity of the network topology (computation, maintenance and distribution) is kept in the ALTO server and ECS is delivered on demand. This allows the ALTO server to enhance and modify the way the topology information sources are used and combined. This simplifies the enforcement of privacy policies of the ISP.
The ALTO Network Map and Cost Map service expose an abstracted view on the ISP network topology. Therefore, in this case care is needed when constructing those maps, as further discussed in Section 3.2.3.
Host group descriptors are used in the ALTO client protocol to describe the location of a host in the network topology. These identifiers are called Partition ID (PID) and e.g. expand to a set of IP address ranges (CIDR).
An automated ALTO implementation may use dynamic algorithms to aggregate network topology. However, it is often desirable to have a mechanism through which the network operator can control the level and details of network aggregation based on a set of requirements and constraints.
IP/MPLS networks make use of a common mechanism to aggregate and group prefixes that is called BGP Communities. BGP is the protocol all ISP networks use in order to exchange information about their prefix reachability. BGP Community is an attribute used to tag a prefix to group prefixes based on mostly any criteria (as an example, most ISP networks originate BGP prefixes with communities identifying the Point of Presence (PoP) where the prefix has been originated).
The ALTO server may leverage the BGP information that is available in the SP network layer and compute group of prefixes. By policy, the ALTO server operator may decide an arbitrary cost defined between groups. Alternatively, there are algorithms that allows a dynamic computation of cost between groups.
Rating criteria are used in the ALTO client protocol to express topology- or connectivity-related properties, which are evaluated in order to generate the ALTO guidance. The ALTO client protocol specification defines a basic set of rating criteria, which have to be supported by all implementations, and an extension procedure for adding new criteria.
The following list gives an overview on further rating criteria that have been proposed or which are in use by ALTO-related prototype implementations. This list is not intended as normative text. Instead, the only purpose of the following list is to document the rating criteria that have been proposed so far, and to solicit further feedback and discussion.
Distance-related rating criteria:
Charging-related rating criteria:
Performance-related rating criteria:
These rating criteria are subject to the remarks below:
The ALTO client MUST be aware, that with high probability, the actual performance values differ significantly from these upper and lower bounds. In particular, an ALTO client MUST NOT consider the "upper bound for throughput" parameter as a permission to send data at the indicated rate without using congestion control mechanisms.
The discrepancies are due to various reasons, including, but not limited to the facts that
Because of these inaccuracies and the lack of complete, instantaneous state information, which are inherent to the ALTO service, the application must use other mechanisms (such as passive measurements on actual data transmissions) to assess the currently achievable throughput, and it MUST use appropriate congestion control mechanisms in order to avoid a congestion collapse. Nevertheless, these rating criteria may provide a useful shortcut for quickly excluding candidate resource providers from such probing, if it is known in advance that connectivity is in any case worse than what is considered the minimum useful value by the respective application.
Rating criteria that SHOULD NOT be defined for and used by the ALTO service include:
This section describes some known limitations of ALTO in general or specific mechanisms in ALTO.
The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses so-called network maps. The network map approach uses host group descriptors that group one or multiple subnetworks (i.e., IP prefixes) to a single aggregate. A set of IP prefixes is called partition and the associated Host Group Descriptor is called Partition ID (PID). The "costs" between the various partition IDs is stored in a second map, the cost map. Map-based approaches lower the signaling load on the server as maps have to be retrieved only if they change.
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:
For 1): ISPs reallocate IPv4 subnets within their infrastructure from time to time, partly to ensure the efficient usage of IPv4 addresses (a scarce resource), and partly to enable efficient route tables within their network routers. The frequency of these "renumbering events" depend on the growth in number of subscribers and the availability of address space within the ISP. As a result, a subscriber's household device could retain an IPv4 address for as short as a few minutes, or for months at a time or even longer.
Some folks have suggested that ISPs providing ALTO services could sub-divide their subscribers' devices into different IPv4 subnets (or certain IPv4 address ranges) based on the purchased service tier, as well as based on the location in the network topology. The problem is that this sub-allocation of IPv4 subnets tends to decrease the efficiency of IPv4 address allocation. A growing ISP that needs to maintain high efficiency of IPv4 address utilization may be reluctant to jeopardize their future acquisition of IPv4 address space.
However, this is not an issue for map-based approaches if changes are applied in the order of days.
For 2): ISPs can use techniques that allow the reallocation of IP prefixes on very short notice, i.e., within minutes. An IP prefix that has no IP address assignment to a host anymore can be reallocated to areas where there is currently a high demand for IP addresses.
For 3): In DSL-based access networks, IP prefixes are assigned to DSLAMs which are the first IP-hop in the access-network between the CPE and the Internet. The access-network between CPE and DSLAM (called aggregation network) can have varying characteristics (and thus associated costs), but still using the same IP prefix. For instance one IP addresses IP11 out of a IP prefix IP1 can be assigned to a VDSL (e.g., 2 MBit/s uplink) access line while the subsequent IP address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s uplink). These IP addresses are assigned on a first come first served basis, i.e., the a single IP address out of the same IP prefix can change its associated costs quite fast. This may not be an issue with respect to the used upstream provider (thus the cross ISP traffic) but depending on the capacity of the aggregation-network this may raise to an issue.
For 4): The routing and traffic engineering inside an ISP network, as well as the peering with other autonomous systems, can change dynamically and affect the information exposed by an ALTO server. As a result, cost map and possibly also network maps can change.
The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses, amongst others mechanism, a mechanism called Endpoint Cost Service (ECS). ALTO clients can ask guidance for specific IP addresses to the ALTO server. However, asking for IP addresses, asking with long lists of IP addresses, and asking quite frequently may overload the ALTO server. The server has to rank each received IP address, which causes load at the server. This may be amplified by the fact that not only a single ALTO client is asking for guidance, but a larger number of them. The results of the ECS are also more difficult to cache than ALTO maps.
Caching of IP addresses at the ALTO client or the usage of the H12 approach [I-D.kiesel-alto-h12] in conjunction with caching may lower the query load on the ALTO server.
For a small ISP, the inter-domain traffic optimizing problem is how to decrease the traffic exchanged with other ISPs, because of high settlement costs. By using the ALTO service to optimize traffic, a small ISP can define two "optimization areas": one is its own network; the other one consists of all other network destinations. The cost map can be defined as follows: the cost of link between clients of inner ISP's networks is lower than between clients of outer ISP's networks and clients of inner ISP's network. As a result, a host with ALTO client inside the network of this ISP will prefer retrieving data from hosts connected to the same ISP.
An example is given in Figure 9. It is assumed that ISP A is a small ISP only having one access network. As operator of the ALTO service, ISP A can define its network to be one optimization area, named as PID1, and define other networks to be the other optimization area, named as PID2. C1 is denoted as the cost inside the network of ISP A. C2 is denoted as the cost from PID2 to PID1, and C3 from PID1 to PID2. For the sake of simplifity, in the following C2=C3 is assumed. In order to keep traffic local inside ISP A, it makes sense to define: C1<C2
-----------
//// \\\\
// \\
// \\ /-----------\
| +---------+ | //// \\\\
| | ALTO | ISP A | C2 | Other Networks |
| | Service | PID 1 <----------- PID 2
| +---------+ C1 | | |
| | \\\\ ////
\\ // \-----------/
\\ //
\\\\ ////
-----------
Figure 9: Example ALTO deployment in small ISPs
A simplified extract of the corresponding ALTO network and cost maps is listed in Figure 10 and Figure 11, assuming that the network of ISP A has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25. In this example, the cost values C1 and C2 can be set to any number C1<C2.
HTTP/1.1 200 OK
...
Content-Type: application/alto-networkmap+json
{
...
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
]
},
"PID2" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
Figure 10: Example ALTO network map
HTTP/1.1 200 OK
...
Content-Type: application/alto-costmap+json
{
...
"cost-type" : {"cost-mode" : "numerical",
"cost-metric": "routingcost"
}
},
"cost-map" : {
"PID1": { "PID1": C1, "PID2": C2 },
"PID2": { "PID1": C2, "PID2": 0 },
}
}
Figure 11: Example ALTO cost map
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.
Such a large ISP deploying an ALTO service may want to optimize its traffic according to the network topology of its access networks. For example, each access network could be defined to be one optimization area, i.e., traffic should be kept locally withing that area if possible. Then the costs between those access networks can be defined according to a corresponding traffic optimizing requirement by this ISP. One example setup is further described below and also shown in Figure 12.
In this example, ISP A has one backbone network and three access networks, named as AN A, AN B, and AN C. A P2P application is used in this example. For the traffic optimization, the first requirement is to decrease the P2P traffic on the backbone network inside the Autonomous System of ISP A; and the second requirement is to decrease the P2P traffic to other ISPs, i.e., other Autonomous Systems. The second requirement can be assumed to have priority over the first one. Also, we assume that the settlement rate with ISP B is lower than with other ISPs. Then ISP A can deploy an ALTO service to meet these traffic optimization requirements. In the following, we will give an example of an ALTO setting and configuration according to these requirements.
In inner network of ISP A, we can define each access network to be one optimization area, and assign one PID to each access network, such as PID 1, PID 2, and PID 3. Because of different peerings with different outer ISPs, we define ISP B to be one optimization area, and we assign PID 4 to it. We define all other networks to be one optimization area and assign PID 5 to it.
We assign costs (C1, C2, C3, C4, C5, C6, C7, C8) as shown in Figure 12. Cost C1 is denoted as the link cost in inner AN A (PID 1), and C2 and C3 are defined accordingly. C4 is denoted as the link cost from PID 1 to PID 2, and C5 is the correspinding cost from PID 3, which is assumed to have a similar value. C6 is the cost between PID 1 and PID 3. For simplicity, we assume symmetrical costs between the AN this example. C7 is denoted as the link cost from the ISP B to ISP A. C8 is the link cost from other networks to ISP A.
According to previous discussion of the first requirement and the second requirement, the relationship of these costs will be defined as: (C1, C2, C3) < (C4, C5, C6) < (C7) < (C8)
+------------------------------------+ +----------------+ | ISP A +---------------+ | | | | | Backbone | | C7 | ISP B | | +--+ Network +---+ |<--------+ PID 4 | | | +-------+-------+ | | | | | | | | | | | | | | | | +----------------+ | +---+--+ +--+---+ +-+----+ | | |AN A | C4 |AN B | C5 |AN C | | | |PID 1 +<-->|PID 2 |<--->+PID 3 | | | |C1 | |C2 | |C3 | | +----------------+ | +---+--+ +------+ +-+----+ | | | | | | | C8 | Other Networks | | +----------------------+ |<--------+ PID 5 | | C6 | | | | | | | +------------------------------------+ +----------------+
Figure 12: ALTO deployment in large ISPs with layered fixed network structures
An ISP with both mobile network and fixed network my focus on optimizing the mobile traffic by keeping traffic in the fixed network as far as possible, because wireless bandwidth is a scarce resource and traffic is costly in mobile network. In such a case, the main requirement of traffic optimization could be decreasing the usage of radio resources in the mobile network. An ALTO service can be deployed to meet these needs.
Figure 13 shows an example: ISP A operates one mobile network, which is connected to a backbone network. The ISP also runs two fixed access networks AN A and AN B, which are also connected to the backbone network. In this network structure, the mobile network can be defined as one optimization area, and PID 1 can be assigned to it. Access networks AN A and B can also be defined as optimization areas, and PID 2 and PID 3 can be assigned, respectively. The cost values are then defined as shown in Figure 13.
To decrease the usage of wireless link, the relationship of these costs can be defined as follows:
From view of mobile network: C4 < C1. This means that clients in mobile network requiring data resource from other clients will prefer clients in AN A to clients in the mobile network. This policy can decrease the usage of wireless link and power consumption in terminals.
From view of AN A: C2 < C6, C5 = maximum cost. This means that clients in other optimization area will avoid retrieving data from the mobile network.
+-----------------------------------------------------------------+ | | | ISP A +-------------+ | | +--------+ ALTO +---------+ | | | | Service | | | | | +------+------+ | | | | | | | | | | | | | | | | | | +-------+-------+ | C6 +--------+------+ | | | AN A |<--------------| AN B | | | | PID 2 | C7 | | PID 3 | | | | C2 |-------------->| C3 | | | +---------------+ | +---------------+ | | ^ | | | ^ | | | | | | | | | | |C4 | | | | | C5 | | | | | | | | | +--------+---------+ | | | | | +-->| Mobile Network |<---+ | | | | | PID 1 | | | | +------- | C1 |----------+ | | +------------------+ | +-----------------------------------------------------------------+
Figure 13: ALTO deployment in ISPs with mobile network
The examples in the previous section are simple and do not consider specific requirements inside access networks, uch as different link types. Deploying an ALTO service in real network will have to require further network conditions and requirements. One real example is described in greater detail in reference [I-D.lee-alto-chinatelecom-trial].
Also, experiments have been conducted with ALTO-like deployments in Internet Service Provider (ISP) networks. For instance, NTT performed tests with their HINT server implementation and dummy nodes to gain insight on how an ALTO-like service influence peer-to-peer systems [I-D.kamei-p2p-experiments-japan]. The results of an early experiment conducted in the Comcast network are documented in [RFC5632].
The scope of this section is the interaction of peer-to-peer applications that use a centralized resource directory ("tracker"), with the ALTO service. In this scenario, the resource consumer ("peer") asks the resource directory for a list of candidate resource providers, which can provide the desired resource.
For efficiency reasons (i.e., message size), usually only a subset of all resource providers known to the resource directory will be returned to the resource consumer. Some or all of these resource providers, plus further resource providers learned by other means such as direct communication between peers, will be contacted by the resource consumer for accessing the resource. The purpose of ALTO is giving guidance on this peer selection, which is supposed to yield better-than-random results. The tracker response as well as the ALTO guidance are most beneficial in the initial phase after the resource consumer has decided to access a resource, as long as only few resource providers are known. Later, when the resource consumer has already exchanged some data with other peers and measured the transmission speed, the relative importance of ALTO may dwindle.
,-------.
,---. ,-' `-. +-----------+
,-' `-. / ISP 1 \ | Peer 1 |*****
/ \ / +-------------+ \ | | *
/ ISP X \ +=====>+ ALTO Server | )+-----------+ *
/ \ = \ +-------------+ / +-----------+ *
; +-----------+ : = \ / | Peer 2 | *
| | Tracker |<====+ `-. ,-' | |*****
| |ALTO Client|<====+ `-------' +-----------+ **
| +-----------+ | = ,-------. **
: * ; = ,-' `-. +-----------+ **
\ * / = / ISP 2 \ | Peer 3 | **
\ * / = / +-------------+ \ | |*****
\ * / +=====>| ALTO Server | )+-----------+ ***
`-. * ,-' \ +-------------+ / +-----------+ ***
`-*-' \ / | Peer 4 |*****
* `-. ,-' | | ****
* `-------' +-----------+ ****
* ****
* ****
***********************************************<******
Legend:
=== ALTO client protocol
*** Application protocol
Figure 14: Global tracker accessing ALTO server at various ISPs
Figure 14 depicts a tracker-based system, in which the tracker embeds the ALTO client. The tracker itself is hosted and operated by an entity different than the ISP hosting and operating the ALTO server. A tracker outside the network of the ISP is the typical use case. For instance, a tracker like Pirate Bay can serve Bittorrent peers world-wide. Initially, the tracker has to look-up the ALTO server in charge for each peer where it receives a ALTO query for. Therefore, the ALTO server has to discover the handling ALTO server, as described in [I-D.ietf-alto-server-discovery]. However, the peers do not have any way to query the server themselves. This setting allows giving the peers a better selection of candidate peers for their operation at an initial time, but does not consider peers learned through direct peer-to-peer knowledge exchange. This is called peer exchange (PEX) in bittorent, for instance.
,-------. +-----------+
,---. ,-' `-. +==>| Peer 1 |*****
,-' `-. / ISP 1 \ = |ALTO Client| *
/ \ / +-------------+<=+ +-----------+ *
/ ISP X \ | + ALTO Server |<=+ +-----------+ *
/ \ \ +-------------+ /= | Peer 2 | *
; +---------+ : \ / +==>|ALTO Client|*****
| | Global | | `-. ,-' +-----------+ **
| | Tracker | | `-------' **
| +---------+ | ,-------. +-----------+ **
: * ; ,-' `-. +==>| Peer 3 | **
\ * / / ISP 2 \ = |ALTO Client|*****
\ * / / +-------------+<=+ +-----------+ ***
\ * / | | ALTO Server |<=+ +-----------+ ***
`-. * ,-' \ +-------------+ /= | Peer 4 |*****
`-*-' \ / +==>|ALTO Client| ****
* `-. ,-' +-----------+ ****
* `-------' ****
* ****
***********************************************<****
Legend:
=== ALTO client protocol
*** Application protocol
Figure 15: Global Tracker - Local ALTO Servers
The scenario in Figure 15 lets the peers directly communicate with their ISP's ALTO server (i.e., ALTO client embedded in the peers), giving thus the peers the most control on which information they query for, as they can integrate information received from trackers and through direct peer-to-peer knowledge exchange.
,-------. +-----------+
,---. ,-' ISP 1 `-. ***>| Peer 1 |
,-' `-. /+-------------+\ * | |
/ \ / + Tracker |<** +-----------+
/ ISP X \ | +-----===-----+<** +-----------+
/ \ \ +-----===-----+ /* | Peer 2 |
; +---------+ : \+ ALTO Server |/ ***>| |
| | Global | | +-------------+ +-----------+
| | Tracker | | `-------'
| +---------+ | +-----------+
: ^ ; ,-------. | Peer 3 |
\ * / ,-' ISP 2 `-. ***>| |
\ * / /+-------------+\ * +-----------+
\ * / / + Tracker |<** +-----------+
`-. *,-' | +-----===-----+ | | Peer 4 |<*
`---* \ +-----===-----+ / | | *
* \+ ALTO Server |/ +-----------+ *
* +-------------+ *
* `-------' *
***********************************************
Legend:
=== ALTO client protocol
*** Application protocol
Figure 16: P4P approach with local tracker and local ALTO server
There are some attempts to let ISP's to deploy their own trackers, as shown in Figure 16. In this case, the client has no chance to get guidance from the ALTO server, other than talking to the ISP's tracker. However, the peers would have still chance the contact other trackers, deployed by entities other than the peer's ISP.
Figure 16 and Figure 14 ostensibly take peers the possibility to directly query the ALTO server, if the communication with the ALTO server is not permitted for any reason. However, considering the plethora of different applications of ALTO, e.g., multiple tracker and non-tracker based P2P systems and or applications searching for relays, it seems to be beneficial for all participants to let the peers directly query the ALTO server. The peers are also the single point having all operational knowledge to decide whether to use the ALTO guidance and how to use the ALTO guidance. This is a preference for the scenario depicted in Figure Figure 15.
TODO
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.
The ALTO protocol specification [I-D.ietf-alto-protocol] details how an ALTO client can query an ALTO server for guiding information and receive the corresponding replies. However, in the considered scenario of a tracker-based P2P application, there are two fundamentally different possibilities where to place the ALTO client:
In the following, both scenarios are compared in order to explain the need for third-party ALTO queries.
In the first scenario (see Figure 18), the resource consumer queries the resource directory for the desired resource (F1). The resource directory returns a list of potential resource providers without considering ALTO (F2). It is then the duty of the resource consumer to invoke ALTO (F3/F4), in order to solicit guidance regarding this list.
In the second scenario (see Figure 20), the resource directory has an embedded ALTO client, which we will refer to as RDAC in this document. After receiving a query for a given resource (F1) the resource directory invokes the RDAC to evaluate all resource providers it knows (F2/F3). Then it returns a, possibly shortened, list containing the "best" resource providers to the resource consumer (F4).
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : k good :
: | | +--------+ : P2P App. : +--------+ peers +------+ :
: | N | | random | : Protocol : | ALTO- |------>| data | :
: | known |====>| pre- |*************>| biased | | ex- | :
: | peers, | | selec- | : transmit : | peer |------>| cha- | :
: | M good | | tion | : n peer : | select | n-k | nge | :
: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :
:...........................: :.....^.....................:
|
| ALTO
| client protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
Figure 17: Tracker-based P2P Application with random peer preselection
Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| F2 Tracker reply | |
|<======================| |
| F3 ALTO client protocol query |
|---------------------------------------------->|
| F4 ALTO client protocol reply |
|<----------------------------------------------|
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
Figure 18: Basic message sequence chart for resource consumer-initiated ALTO query
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : :
: | | +--------+ : P2P App. : k good peers & +------+ :
: | N | | ALTO- | : Protocol : n-k bad peers | data | :
: | known |====>| biased |******************************>| ex- | :
: | peers, | | peer | : transmit : | cha- | :
: | M good | | select | : n peer : | nge | :
: +-______-+ +--------+ : IDs : +------+ :
:.....................^.....: :...........................:
|
| ALTO
| client protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
Figure 19: Tracker-based P2P Application with ALTO client in tracker
Peer Tracker w. RDAC ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| | F2 ALTO cli. p. query |
| |---------------------->|
| | F3 ALTO cli. p. reply |
| |<----------------------|
| F4 Tracker reply | |
|<======================| |
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
Figure 20: Basic message sequence chart for third-party ALTO query
Note: the message sequences depicted in Figure 18 and Figure 20 may occur both in the target-aware and the target-independent query mode (c.f. [RFC6708]). In the target-independent query mode no message exchange with the ALTO server might be needed after the tracker query, because the candidate resource providers could be evaluated using a locally cached "map", which has been retrieved from the ALTO server some time ago.
The problem with the first approach is, that while the resource directory might know thousands of peers taking part in a swarm, the list returned to the resource consumer is usually shortened for efficiency reasons. Therefore, the "best" (in the sense of ALTO) potential resource providers might not be contained in that list anymore, even before ALTO can consider them.
For illustration, consider a simple model of a swarm, in which all peers fall into one of only two categories: assume that there are "good" ("good" in the sense of ALTO's better-than-random peer selection, based on an arbitrary desired rating criterion) and "bad' peers only. Having more different categories makes the maths more complex but does not change anything to the basic outcome of this analysis. Assume that the swarm has a total number of N peers, out of which are M "good" and N-M "bad" peers, which are all known to the tracker. A new peer wants to join the swarm and therefore asks the tracker for a list of peers.
If, according to the first approach, the tracker randomly picks n peers from the N known peers, the result can be described with the hypergeometric distribution. The probability that the tracker reply contains exactly k "good" peers (and n-k "bad" peers) is:
/ m \ / N - m \
\ k / \ n - k /
P(X=k) = ---------------------
/ N \
\ n /
/ n \ n!
with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1
k! (n-k)!
The probability that the reply contains at most k "good" peers is: P(X<=k)=P(X=0)+P(X=1)+..+P(X=k).
For example, consider a swarm with N=10,000 peers known to the tracker, out of which M=100 are "good" peers. If the tracker randomly selects n=100 peers, the formula yields for the reply: P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approx. 36% this list does not contain a single "good" peer, and with 99% probability there are only four or less of the "good" peers on the list. Processing this list with the guiding ALTO information will ensure that the few favorable peers are ranked to the top of the list; however, the benefit is rather limited as the number of favorable peers in the list is just too small.
Much better traffic optimization could be achieved if the tracker would evaluate all known peers using ALTO, and return a list of 100 peers afterwards. This list would then include a significantly higher fraction of "good" peers. (Note, that if the tracker returned "good" peers only, there might be a risk that the swarm might disconnect and split into several disjunct partitions. However, finding the right mix of ALTO-biased and random peer selection is out of the scope of this document.)
Therefore, from an overall optimization perspective, the second scenario with the ALTO client embedded in the resource directory is advantageous, because it is ensured that the addresses of the "best" resource providers are actually delivered to the resource consumer. An architectural implication of this insight is that the ALTO server discovery procedures must support third-party discovery. That is, as the tracker issues ALTO queries on behalf of the peer which contacted the tracker, the tracker must be able to discover an ALTO server that can give guidance suitable for that respective peer.
This section discuss the usage of ALTO for Content Delivery Networks (CDNs) [I-D.jenkins-alto-cdn-use-cases]. CDNs are used to bring a service (e.g., a web page, videos, etc) closer to the location of the user – where close refers to shorten the distance between the client and the server in the IP topology. CDNs use several techniques to decide which server is closest to a client requesting a service. One common way to do so, is relying on the DNS system, but there are many other ways, see [RFC3568].
The general issue for CDNs, independent of DNS or HTTP Redirect based approaches (see, for instance, [I-D.penno-alto-cdn]), is that the CDN logic has to match the client's IP address with the closest CDN cache. This matching is not trivial, for instance, in DNS based approaches, where the IP address of the DNS original requester is unknown (see [I-D.vandergaast-edns-client-ip] for a discussion of this and a solution approach).
TODO: Rewording required
When a user request a given content, the CDN locates the content in one or more caches and executes a selection algorithms in order to redirect the user to the 'best' cache. In order to achieve that, the CDN issues an ECS request with the endpoint address (IPv4/IPv6) of the user (content requester) and the set of endpoint addresses of the content caches (content targets). The ALTO server, receives the request and ranks the list of content targets addresses based on their distance from the content requester. By default, according to [I-D.ietf-alto-protocol], the distance represents the routing cost as computed by the routing layer (OSPF, ISIS, BGP) and may take into consideration other routing criteria such as MPLS-VPN (MP-BGP) and MPLS-TE (RSVP), policy and state and performance information in addition to other information sources (policy, geo-location, state and performance).
Once the ALTO server computed the distance it replies with the ranked list of content target addresses. The list being ranked by distance, the CDN is capable of integrating the rankings into its selection process (that will also incorporate other criteria) and redirect the user accordingly.
The Request Router may request the Endpoint service from the ALTO client.
Specifically, the Request Router requests the Endpoint Cost Service in order to rank/rate the content locations (i.e., IP addresses of CDN nodes) based on their distance/cost (by default the Endpoint Cost Service operates based on Routing Distance) from/to the user address.
Once the Request Router obtained from the ALTO Server the ranked list of locations (for the specific user) it can incorporate this information into its selection mechanisms in order to point the user to the most appropriate location.
A Request Router that uses the Endpoint Cost Service may query the ALTO Server for rankings of CDN Node IP addresses for each interesting host and cache the results for later usage.
Maps Services and ECS deliver similar ALTO service by allowing the CDN to optimize internal selection mechanisms. Both services deliver similar level of security, confidentiality of layer-specific information (i.e.: application and network) however, Maps and ECS differ in the way the ALTO service is delivered and address a different set of requirements in terms of topology information and network operations.
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:
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).
Each reply sent back by the ALTO server to the ALTO client running in the CDN has a validity in time so that the CDN can cache the results in order to re-use it and hence reducing the number of transactions between CDN and ALTO server. The ALTO server may indicate in the reply message how long the content of the message is to be considered reliable and insert a lifetime value that will be used by the CDN in order to cache (and then flush or refresh) the entry.
An ALTO server implementation may want to keep state about ALTO clients so to inform and signal to these clients when a major network event happened so to clear the ALTO cache in the client. In a CDN/ALTO interworking architecture where there's a few CDN component interacting with the ALTO server there are no scalability issues in maintaining state about clients in the ALTO server.
ALTO server ranks addresses based on topology information it acquires from the network. The different methods and algorithms through which the ALTO server computes topology information and rankings is out of the scope of this document. However, and in the case the rankings are based on routing (IP/MPLS) topology, it is obvious that network events may impact the ranking computation. The scope of the ECS service delivered to a CDN is not to maintain the CDN aware of any possible network topology changes since, due to redundancy of current networks, most of the network events happening in the infrastructure will have limited impact on the CDN. However, catastrophic events such as main trunks failures or backbone partition will have to take into account by the ALTO server so to redirect traffic away from the failure impacted area.
This section briefly surveys and references other use cases that have been suggested for ALTO.
TODO
TODO
Deployment of intra-domain P2P caches has been proposed for a cooperations between the network operator and the P2P service providers, e.g., to reduce the bandwith consumption in access networks [I-D.deng-alto-p2pcache].
+--------------+ +------+
| ISP 1 network+----------------+Peer 1|
+-----+--------+ +------+
|
+--------+------------------------------------------------------+
| | ISP 2 network |
| +---------+ |
| |L1 Cache | |
| +-----+---+ |
| +--------------------+----------------------+ |
| | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | AN1 | | AN2 | | AN3 | |
| | +---------+ | | +----------+ | | | |
| | |L2 Cache | | | |L2 Cache | | | | |
| | +---------+ | | +----------+ | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | |
| +--------------------+ | |
| | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | SUB-AN11 | | SUB-AN12 | | SUB-AN31 | |
| | +---------+ | | | | | |
| | |L3 Cache | | | | | | |
| | +---------+ | | | | | |
| +------+------+ +------+-------+ +------+-------+ |
| | | | |
+--------+--------------------+----------------------+----------+
| | |
+---+---+ +---+---+ |
| | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
|Peer2| |Peer3| |Peer4| |Peer5| |Peer6|
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 21: General architecture of intra-ISP caches
Figure 21 depics the overall architecture of a potential P2P cache deployments inside an ISP 2 with various access network types. As shown in the figure, P2P caches may be deployed at various levels, including the interworking gateway linking with other ISPs, internal access network gateways linking with different types of accessing networks (e.g. WLAN, cellular and wired), and even within an accessing network at the entries of individual WLAN sub-networks. Moreover, depending on the network context and the operator's policy, each cache can be a Forwarding Cache or a Bidirectional Cache [I-D.deng-alto-p2pcache].
In such a cache architecture, the locations of caches could be used as dividers of different PIDs to guide intra-ISP network abstraction and mark costs among them according to the location and type of relevant caches.
Further details and deployment considerations can be found in [I-D.deng-alto-p2pcache].
The ALTO protocol itself as well as the ALTO client and server raise new security issues beyond the ones mentioned in [I-D.ietf-alto-protocol] and issues related to message transport over the Internet. For instance, Denial of Service (DoS) is of interest for the ALTO server and also for the ALTO client. A server can get overloaded if too many TCP requests hit the server, or if the query load of the server surpasses the maximum computing capacity. An ALTO client can get overloaded if the responses from the sever are, either intentionally or due to an implementation mistake, too large to be handled by that particular client.
This section is solely giving a first shot on security issues related to ALTO deployments.
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.
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.
Depending on the use case of ALTO, several access restrictions to an ALTO server may or may not apply.
For peer-to-peer applications, a potential deployment scenario is that an ALTO server is solely accessible by peers from the ISP network (as shown in Figure 15). For instance, the source IP address can be used to grant only access from that ISP network to the server. This will "limit" the number of peers able to attack the server to the user's of the ISP (however, including botnet computers).
If the ALTO server has to be accessible by parties not located in the ISP's network (see Figure Figure 14), e.g., by a third-party tracker or by a CDN system outside the ISP's network, the access restrictions have to be looser. In the extreme case, i.e., no access restrictions, each and every host in the Internet can access the ALTO server. This might no be the intention of the ISP, as the server is not only subject to more possible attacks, but also on the load imposed to the server, i.e., possibly more ALTO clients to serve and thus more work load.
There are also use cases where the access to the ALTO server has to be much more strictly controlled, i. e., where an authentication and authorization of the ALTO client to the server may be needed. For instance, in case of CDN optimization the provider of an ALTO service as well as potential users are possibly well-known. Only CDN entities may need ALTO access; access to the ALTO servers by residential users may neither be necessary nor be desired.
It has not yet been investigated how a faked or wrong ALTO guidance by an ALTO server can impact the operation of the network and also the peers.
Here is a list of examples how the ALTO guidance could be faked and what possible consequences may arise:
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3568] | Barbir, A., Cain, B., Nair, R. and O. Spatscheck, "Known Content Network (CN) Request-Routing Mechanisms", RFC 3568, July 2003. |
| [RFC6708] | Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R. and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, September 2012. |
| [I-D.ietf-alto-protocol] | Alimi, R., Penno, R. and Y. Yang, "ALTO Protocol", Internet-Draft draft-ietf-alto-protocol-13, September 2012. |
| [RFC5693] | Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009. |
| [I-D.ietf-alto-server-discovery] | Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M. and S. Yongchao, "ALTO Server Discovery", Internet-Draft draft-ietf-alto-server-discovery-07, January 2013. |
| [I-D.vandergaast-edns-client-ip] | Contavalli, C., Gaast, W., Leach, S. and D. Rodden, "Client IP information in DNS requests", Internet-Draft draft-vandergaast-edns-client-ip-01, May 2010. |
| [I-D.penno-alto-cdn] | Penno, R., Medved, J., Alimi, R., Yang, R. and S. Previdi, "ALTO and Content Delivery Networks", Internet-Draft draft-penno-alto-cdn-03, March 2011. |
| [I-D.kamei-p2p-experiments-japan] | Kamei, S., Momose, T., Inoue, T. and T. Nishitani, "ALTO-Like Activities and Experiments in P2P Network Experiment Council", Internet-Draft draft-kamei-p2p-experiments-japan-09, October 2012. |
| [I-D.kiesel-alto-h12] | Kiesel, S. and M. Stiemerling, "ALTO H12", Internet-Draft draft-kiesel-alto-h12-02, March 2010. |
| [RFC5632] | Griffiths, C., Livingood, J., Popkin, L., Woundy, R. and Y. Yang, "Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial", RFC 5632, September 2009. |
| [I-D.lee-alto-chinatelecom-trial] | Li, K. and G. Jian, "ALTO and DECADE service trial within China Telecom", Internet-Draft draft-lee-alto-chinatelecom-trial-04, March 2012. |
| [I-D.jenkins-alto-cdn-use-cases] | Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J. and S. Previdi, "Use Cases for ALTO within CDNs", Internet-Draft draft-jenkins-alto-cdn-use-cases-03, June 2012. |
| [I-D.deng-alto-p2pcache] | Lingli, D., Chen, W., Yi, Q. and Y. Zhang, "Considerations for ALTO with network-deployed P2P caches", Internet-Draft draft-deng-alto-p2pcache-02, July 2013. |
In addition to providing configuration, an ISP providing ALTO may want to deploy a monitoring infrastructure to assess the benefits of ALTO and adjust its ALTO configuration according to the results of the monitoring.
To construct an effective monitoring infrastructure, the ISP should (1) define the performance metrics to be monitored; (2) and identify and deploy data sources to collect data to compute the performance metrics. We discuss both below.
[Editor's note: Is there a relationship to the IPPM working group at the IETF?]
The preceding metrics are derived from data sources. We identify three data sources.
As discussed in the preceding section, some data sources are from ISP while some others are from application. When there is a collaboration agreement between the ISP and an application, there can be an integrated monitoring system as shown in the figure below. In particular, an application developer may deploy Monitor Clients to communicate with Monitor Server of the ISP to transmit raw data from the Log Server or P2P clients of the application to the ISP.
+------------------------------------------------+
| |
| New Entities +--------------------------------------+
| | Service Provider |
| | (P2P/CDN Operator etc)|
| +-----------+ | +-----------+ | |
| |ALTO Server|-------------|ALTO Client| | |
| +-----------+ | +-----------+ | |
| | | +----------+ |
| | | |Log Server| |
| | | +----------+ |
| +--------------+ | +--------------+ | +----------+ |
| |Monitor Server|----------|Monitor Client| | |P2P Client| |
| +--------------+ | +--------------+ | +----------+ |
| | | | |
| +--------|--------+ +--------------------------------------+
+-|--------|--------|----------------------------+
| | |
| | |
| +---+ |
| |OAM| |
| +---+ |
| ISP |
-----------------
Figure 22: Monitoring Structure
This section gives some informational guidance on how the interface between the actual application using the ALTO guidance and the ALTO client can look like.
This is still TBD.
This memo is the result of contributions made by several people, such as:
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.