RFC 7971
Application-Layer Traffic Optimization (ALTO) Deployment Considerations
Pages: 77
Informational
Informational
Part 3 of 4 – Pages 36 to 58
3.5. Abstract Map Examples for Different Types of ISPs
3.5.1. Small ISP with Single Internet Uplink
The ALTO protocol does not mandate how to determine costs between endpoints and/or determine map data. In complex usage scenarios, this can be a non-trivial problem. In order to show the basic principle, this and the following sections explain for different deployment scenarios how ALTO maps could be structured. 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 and the other one consists of all other network destinations. The cost map can be defined as follows: the cost of a link between clients of the inner ISP's network is lower than between clients of the outer ISP's network and clients of inner ISP's network. As a result, a host with an 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. In the following, C2=C3 is assumed for the sake of simplicity. 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 |----------->| | | | C3 (=C2) \\\\ //// \\ // \-----------/ \\ // \\\\ //// ----------- Figure 9: Example ALTO Deployment for a Small ISP A simplified extract of the corresponding ALTO network and cost maps is listed in Figures 10 and 11, assuming that the network of ISP A has the IPv4 address ranges 192.0.2.0/24 and 198.51.100.0/25, as well as the IPv6 address range 2001:db8:100::/48. 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" ], "ipv6" : [ "2001:db8:100::/48" ] }, "PID2" : { "ipv4" : [ "0.0.0.0/0" ], "ipv6" : [ "::/0" ] } } } Figure 10: Example ALTO Network Map HTTP/1.1 200 OK ... Content-Type: application/alto-costmap+json { ... "cost-type" : {"cost-mode" : "numerical", "cost-metric": "routingcost" } }, "cost-map" : { "PID1": { "PID1": C1, "PID2": C2 }, "PID2": { "PID1": C2, "PID2": 0 }, } } Figure 11: Example ALTO Cost Map
3.5.2. ISP with Several Fixed-Access Networks
This example discusses a P2P application traffic optimization use case for a larger ISP with a fixed network comprising several access networks and a core network. The traffic optimizing objectives 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 local withing that area if possible. This can be achieved by mapping each area to a PID. 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 a reasonable application-level traffic optimization, the first requirement could be a decrease of the P2P traffic on the backbone network inside the AS of ISP A and the second requirement could be a decrease of the P2P traffic to other ISPs, i.e., other ASes. 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. ISP A can deploy an ALTO service to meet these traffic distribution requirements. In the following, we will give an example of an ALTO setting and configuration according to these requirements. In the network of ISP A, the operator of the ALTO server 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, one can define ISP B to be one additional optimization area and assign PID 4 to it. All other networks can be added to a PID to be one further optimization area (PID 5). In the setup, costs (C1, C2, C3, C4, C5, C6, C7, C8) can be assigned 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 corresponding cost from PID 3, which is assumed to have a similar value. C6 is the cost between PID 1 and PID 3. For simplicity, this scenario assumes
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 Structures3.5.3. ISP with Fixed and Mobile Network
An ISP with both mobile network and fixed network may focus on optimizing the mobile traffic by keeping traffic in the fixed network as much 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 and C4 = C8. This means that clients in mobile network requiring data resources from other clients will prefer clients in AN A or B 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. From view of AN B: Analog to the view of AN A, C3 < C8 and C9 = maximum cost. +-----------------------------------------------------------------+ | | | ISP A +-------------+ | | +--------+ ALTO +---------+ | | | | Service | | | | | +------+------+ | | | | | | | | | | | | | | | | | | +-------+-------+ | C6 +--------+------+ | | | AN A |<--------------| AN B | | | | PID 2 | C7 | | PID 3 | | | | C2 |-------------->| C3 | | | +---------------+ | +---------------+ | | ^ | | | ^ | | | | | | | | | | | C4 | C8 | | | | C5 | | | | | C9 | | | | +--------+---------+ | | | | | +-->| Mobile Network |<---+ | | | | | PID 1 | | | | +------- | C1 |----------+ | | +------------------+ | +-----------------------------------------------------------------+ Figure 13: ALTO Deployment in ISPs with Mobile Network These examples show that for ALTO in particular the relationships between different costs matter; the operator of the server has several degrees of freedom how to set the absolute values.
3.6. Comprehensive Example for Map Calculation
In addition to the previous, abstract examples, this section presents a more detailed scenario with a realistic IGP and BGP routing protocol configuration. This example was first described in [MAP-CALC].3.6.1. Example Network
Figure 14 depicts a network that is used to explain the steps carried out in the course of this example. The network consists of nine routers (R1 to R9). Two of them are border routers (R1 + R8) connected to neighbored networks (AS 2 to AS 4). Furthermore, AS 4 is not directly connected to the local network, but has AS 3 as transit network. The links between the routers are point-to-point connections. These connections also form the core network with the 2001:db8:1:0::/56 prefix. This prefix is large enough to provide addresses for all router interconnections. In addition to the core network, the local network also has five client networks attached to five different routers (R2, R5, R6, R7 and R9). Each client network has a /56 prefix with 2001:db8:1:x00:: (x = [1..5]) as network address.
+-------------------+ +-----+ +-----+ +-------------------+ |2001:db8:1:200::/56+----+ R6 | | R7 +----+2001:db8:1:300::/56| +-------------------+ +--+--+ +--+--+ +-------------------+ | | +---------------+ | | | AS 2 | | | |2001:db8:2::/48| | 10 | 10 +------------+--+ | | | | | | | | +--+--+ 15 +--+--+ +--+--+ +-------------------+ | R1 +--------+ R3 +----+ R5 |----+2001:db8:1:400::/56| +--+--+ +--+--+ 5 +--+--+ +-------------------+ | \ / | | | \ / 15 | | | \ / | | +---------------+ | \/ | | | AS 4 | | 20 /\ | 5 | 10 |2001:db8:4::/48| | / \ | | +-------+-------+ | / \ 20 | | | | / \ | | | +--+--+ +--+--+ +--+--+ +-------+-------+ | R2 | | R4 | | R8 +--------+ AS 3 | +--+--+ +--+--+ +--+--+ |2001:db8:3::/48| | | | +---------------+ | | | 10 | | 20 | +------------+------+ | +--+--+ +-------------------+ |2001:db8:1:100::/56| +-------+ R9 +----+2001:db8:1:500::/56| +-------------------+ +-----+ +-------------------+ Figure 14: Example Network The example network utilizes two different routing protocols, one for IGP and another for EGP routing. The used IGP is a link-state protocol such as IS-IS. The applied link weights are annotated in the graph and additionally shown in Figure 15. All links are bidirectional and their weights are symmetric. To obtain the topology and routing information from the network, the topology data source must be connected directly to one of the routers (R1...R9). Furthermore, the topology data source must be enabled to communicate with the router and vice versa. The BGP is used in this scenario to route between autonomous systems. External BGP is running on the two border routers R1 and R8. Furthermore, internal BGP is used to propagate external as well as internal prefixes within the network boundaries; it is running on every router with an attached client network (R2, R5, R6, R7 and R9).
Since no route reflector is present it is necessary to fetch routes from each BGP router separately. R1 R2 R3 R4 R5 R6 R7 R8 R9 R1 0 15 15 20 - - - - - R2 15 0 20 - - - - - - R3 15 20 0 5 5 10 - - - R4 20 - 5 0 5 - - - 20 R5 - - 5 5 0 - 10 10 - R6 - - 10 - - 0 - - - R7 - - - - 10 - 0 - - R8 - - - - 10 - - 0 10 R9 - - - 20 - - - 10 0 Figure 15: Example Network Link Weights For monitoring purposes, it is possible to enable, e.g., SNMP or NETCONF on the routers within the network. This way an ALTO server may obtain several additional information about the state of the network. For example, utilization, latency, and bandwidth information could be retrieved periodically from the network components to get and keep an up-to-date view on the network situation. In the following, it is assumed that the listed attributes are collected from the network: o IS-IS: topology, link weights o BGP: prefixes, AS numbers, AS distances, or other BGP metrics o SNMP: latency, utilization, bandwidth3.6.2. Potential Input Data Processing and Storage
Due to the variety of data sources available in a network, it may be necessary to aggregate the information and define a suitable data model that can hold the information efficiently and easily accessible. One potential model is an annotated directed graph that represents the topology. The attributes can be annotated at the corresponding positions in the graph. The following shows how such a topology graph could describe the example topology. In the topology graph, a node represents a router in the network, while the edges stand for the links that connect the routers. Both routers and links have a set of attributes that store information gathered from the network.
Each router could be associated with a basic set of information, such
as:
o ID: Unique ID within the network to identify the router.
o Neighbor IDs: List of directly connected routers.
o Endpoints: List of connected endpoints. The endpoints may also
have further attributes themselves depending on the network and
address type. Such potential attributes are costs for reaching
the endpoint from the router, AS numbers, or AS distances.
In addition to the basic set, many more attributes may be assigned to
router nodes. This mainly depends on the utilized data sources.
Examples for such additional attributes are geographic location, host
name and/or interface types, just to name a few.
The example network shown in Figure 14 represents such an internal
network graph where the routers R1 to R9 represent the nodes and the
connections between them are the links. For instance, R2 has one
directly attached IPv6 endpoint that belongs to its own AS, as shown
in Figure 16.
ID: 2
Neighbor IDs: 1,3 (R1, R3)
Endpoints:
Endpoint: 2001:db8:1:100::/56
Weight: 10 (e.g., the default IGP metric value)
ASNumber: 1 (our own AS)
ASDistance: 0
Host Name: R2
Figure 16: Example Router R2
Router R8 has two attached IPv6 endpoints, as explained in Figure 17.
The first one belongs to a directly neighbored AS with AS number 3.
The AS distance from our network to AS3 is 1. The second endpoint
belongs to an AS (AS4) that is no direct neighbor but directly
connected to AS3. To reach endpoints in AS4, it is necessary to
cross AS3, which increases the AS distance by one.
ID: 8 Neighbor IDs: 5,9 (R5, R9) Endpoints: Endpoint: 2001:db8:3::/48 Weight: 100 ASNumber: 3 ASDistance: 1 Endpoint: 2001:db8:4::/48 Weight: 200 ASNumber: 4 ASDistance: 2 Host Name: R8 Figure 17: Example Router R8 A potential set of attributes for a link is described in the following list: o Source ID: ID of the source router of the link. o Destination ID: ID of the destination router of the link. o Weight: The cost to cross the link, e.g., defined by the used IGP. Additional attributes that provide technical details and state information can be assigned to links as well. The availability of such additional attributes depends on the utilized data sources. Such attributes can be characteristics like maximum bandwidth, utilization, or latency on the link as well as the link type. In the example, the link attributes are equal for all links and only their values differ. It is assumed that the attributes utilization, bandwidth, and latency are collected, e.g., via SNMP or NETCONF. In the topology of Figure 14, the links between R1 and R2 would then have the following link attributes explained in Figure 18:
R1->R2: Source ID: 1 Destination ID: 2 Weight: 15 Bandwidth: 10 Gbit/s Utilization: 0.1 Latency: 2 ms R2->R1: Source ID: 2 Destination ID: 1 Weight: 15 Bandwidth: 10 Gbit/s Utilization: 0.55 Latency: 5 ms Figure 18: Link Attributes It has to be emphasized that values for utilization and latency can be very volatile.3.6.3. Calculation of Network Map from the Input Data
The goal of the ALTO map calculation process is to get from the graph representation of the network to a coarser-grained and abstract matrix representation. The first step is to generate the network map. Only after the network map has been generated is it possible to compute the cost map since it relies on the network map. To generate an ALTO network map, a grouping function is required. A grouping function processes information from the network graph to group endpoints into PIDs. The way of grouping is manifold and algorithms can utilize any information provided by the network graph to perform the grouping. The functions may omit certain endpoints in
order to simplify the map or in order to hide details about the network that are not intended to be published in the resulting ALTO network map. For IP endpoints, which are either an IP (version 4 or version 6) address or prefix, [RFC7285] requires the use of a longest-prefix matching algorithm to map IPs to PIDs. This requirement results in the constraints that every IP must be mapped to a PID and the same prefix or address not be mapped to more than one PID. To meet the first constraint, every calculated map must provide a default PID that contains the prefixes 0.0.0.0/0 for IPv4 and ::/0 for IPv6. Both prefixes cover their entire address space, and if no other PID matches an IP endpoint, the default PID will. The second constraint must be met by the grouping function that assigns endpoints to PIDs. In case of collision, the grouping function must decide to which PID an endpoint is assigned. These or other constraints may apply to other endpoint types depending on the used matching algorithm. A simple example for such grouping is to compose PIDs by host names. For instance, each router's host name is selected as the name for a PID and the attached endpoints are the member endpoints of the corresponding PID. Additionally, backbone prefixes should not appear in the map so they are filtered out. The following table in Figure 19 shows the resulting ALTO network map, using the network in Figure 14 as example: PID | Endpoints ---------+----------------------------------- R1 | 2001:db8:2::/48 R2 | 2001:db8:1:100::/56 R5 | 2001:db8:1:400::/56 R6 | 2001:db8:1:200::/56 R7 | 2001:db8:1:300::/56 R8 | 2001:db8:3::/48, 2001:db8:4::/48 R9 | 2001:db8:1:500::/56 default | 0.0.0.0/0, ::/0 Figure 19: Example ALTO Network Map Since router R3 and R4 have no endpoints assigned, they are not represented in the network map. Furthermore, as previously mentioned, the "default" PID was added to represent all endpoints that are not part of the example network.
3.6.4. Calculation of Cost Map
After successfully creating the network map, the typical next step is to calculate the costs between the generated PIDs, which form the cost map. Those costs are calculated by cost functions. A cost function may calculate unidirectional values, which means it is necessary to compute the costs from every PID to every PID. In general, it is possible to use all available information in the network graph to compute the costs. In case a PID contains more than one IP address or prefix, the cost function may first calculate a set of cost values for each source/destination IP pair. In that case, a tiebreaker function is required to decide the resulting cost value, as [RFC7285] allows one cost value only between two PIDs. Such a tiebreaker can be a simple function such as minimum, maximum, or average value. No matter what metric the cost function uses, the path from source to destination is usually defined by the path with minimum weight. When the link weight is represented by an additive metric, the path weight is the sum of link weights of all traversed links. The path may be determined, for instance, with the Bellman-Ford or Dijkstra algorithms. The latter progressively builds the shortest path in terms of cumulated link lengths. In our example, the link lengths are link weights with values illustrated in Figure 15. Hence, the cost function generally extracts the optimal path with respect to a chosen metric, such as the IGP link weight. It is also possible that more than one path with the same minimum weight exists, which means it is not entirely clear which path is going to be selected by the network. Hence, a tiebreaker similar to the one used to resolve costs for PIDs with multiple endpoints is necessary. An important note is that [RFC7285] does not require cost maps to provide costs for every PID pair, so if no path cost can be calculated for a certain pair, the corresponding field in the cost map is left out. Administrators may also not want to provide cost values for some PID pairs due to various reasons. Such pairs may be defined before the cost calculation is performed. Based on the network map example shown in the previous section, it is possible to calculate the cost maps. Figure 20 provides an example where the selected metric for the cost map is the minimum number of hops necessary to get from the endpoints in the source PID to endpoints in the destination PID. Our chosen tiebreaker selects the minimum hop count when more than one value is returned by the cost function.
PID | default | R1 | R2 | R5 | R6 | R7 | R8 | R9 | --------+---------+-----+-----+-----+-----+-----+-----+-----| default | x | x | x | x | x | x | x | x | R1 | x | 0 | 2 | 3 | 3 | 4 | 4 | 3 | R2 | x | 2 | 0 | 3 | 3 | 4 | 4 | 4 | R5 | x | 3 | 3 | 0 | 3 | 2 | 2 | 3 | R6 | x | 3 | 3 | 3 | 0 | 4 | 4 | 4 | R7 | x | 4 | 4 | 2 | 4 | 0 | 3 | 4 | R8 | x | 4 | 4 | 2 | 4 | 3 | 0 | 2 | R9 | x | 3 | 4 | 3 | 4 | 4 | 2 | 0 | Figure 20: Example ALTO Hop Count Cost Map It should be mentioned that R1->R9 has several paths with equal path weights. The paths R1->R3->R5->R8->R9, R1->R3->R4->R9, and R1->R4->R9 all have a path weight of 40. Due to the minimum hop count value tiebreaker, 3 hops is chosen as value for the path R1->R4->R9. Furthermore, since the "default" PID is, in a sense, a virtual PID with no endpoints that are part of the example network, no cost values are calculated for other PIDs from or towards it.3.7. Deployment Experiences
There are multiple interoperable implementations of the ALTO protocol. Some experiences in implementing and using ALTO for large- scale networks have been documented in [MAP-CALC] and are here summarized: o Data collection: Retrieving topology information typically requires implementing several protocols other than ALTO for data collection. For such other protocols, ALTO deployments faced protocol behaviors that were different from what would be expected from the specification of the corresponding protocol. This includes behavior caused by older versions of the protocol specification, a lax interpretation on the remote side or simply incompatibility with the corresponding standard. This sort of problems in collecting data can make an ALTO deployment more complicated, even if it is unrelated to ALTO protocol itself. o Data processing: Processing network information can be very complex and quite resource demanding. Gathering information from an autonomous system connected to the Internet may imply that a server must store and process hundreds of thousands of prefixes, several hundreds of megabytes of IPFIX/Netflow information per minute, and information from hundreds of routers and attributes of thousands of links. A lot of disk memory, RAM, and CPU cycles as well as efficient algorithms are required to process the
information. Operators of an ALTO server have to be aware that
significant compute resources are not only required for the ALTO
server, but also for the corresponding data collection.
o Network map calculation: Large IP-based networks consist of
hundreds of thousands of prefixes that have to be mapped to PIDs
in the process of network map calculation. As a result, network
maps get very large (up to tens of megabytes). However, depending
on the design of the network and the chosen grouping function the
calculated network maps contains redundancy that can be removed.
There are at least two ways to reduce the size by removing
redundancy. First, adjacent IP prefixes can be merged. When a
PID has two adjacent prefix entries it can merge them together to
one larger prefix. It is mandatory that both prefixes be in the
same PID. However, the large prefix being assigned to another PID
cannot be ruled out. This must be checked, and it is up to the
grouping function whether or not to merge the prefixes and remove
the larger prefix from the other PID. A simple example, when a
PID comprises the prefixes 2001:db8:0:0::/64 and 2001:db8:0:1::/64
it can easily merge them to 2001:db8:0:0::/63. Second, a prefix
and its next-longest-prefix match may be in the same PID. In this
case, the smaller prefix can simply be removed since it is
redundant for obvious reasons. A simple example, a PID comprises
the prefixes 2001:db8:0:0::/62 and 2001:db8:0:1::/64 and the /62
is the next-longer prefix match of the /64, the /64 prefix can
simply be removed. In contrast, if another PID contains the
2001:db8:0:0::/63 prefix, the entry 2001:db8:0:1::/64 cannot be
removed since the next-longest prefix is not in the same PID
anymore. Operators of an ALTO server thus have to analyze whether
their address assignment schemes allows such tuning.
o Cost map calculation: One known implementation challenge with cost
map calculations is the vast amount of CPU cycles that may be
required to calculate the costs in large networks. This is
particular problematic if costs are calculated between the
endpoints of each source-destination PID pair. Very often several
to many endpoints of a PID are attached to the same node, so the
same path cost is calculated several times. This is clearly
inefficient. A remedy could be more sophisticated algorithms,
such as looking up the routers the endpoints of each PID are
connected to in our network graph and calculated cost map based on
the costs between the routers. When deploying and configuring
ALTO servers, administrators should consider the impact of huge
cost maps and possibly ensure that map sizes do not get too large.
In addition, further deployment experiences have been documented.
One real example is described in greater detail in reference
[CHINA-TRIAL].
Also, experiments have been conducted with ALTO-like deployments in ISP networks. For instance, NTT performed tests with their HINT server implementation and dummy nodes to gain insight on how an ALTO- like service can influence peer-to-peer systems [RFC6875]. The results of an early experiment conducted in the Comcast network are documented in [RFC5632].4. Using ALTO for P2P Traffic Optimization
4.1. Overview
4.1.1. Usage Scenario
Originally, P2P applications were the main driver for the development of ALTO. In this use case, it is assumed that one party (usually the operator of a "managed" IP network domain) will disclose information about the network through ALTO. The application overlay will query this information and optimize its behavior in order to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure. The resulting win-win situation is assumed to be the incentive for both parties to provide or consume the ALTO information, respectively. P2P systems can be built with or without use of a centralized resource directory ("tracker"). The scope of this section is the interaction of P2P applications with the ALTO service. In this scenario, the resource consumer ("peer") asks the resource directory for a list of candidates that can provide the desired resource. There are different options for how ALTO can be deployed in such use cases with a centralized resource directory. For efficiency reasons (i.e., message size), 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 should 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.
4.1.2. Applicability of ALTO
A tracker-based P2P application can leverage ALTO in different ways. In the following, the different alternatives and their pros and cons are discussed. ,-------. +-----------+ ,---. ,-' ========>| Peer 1 |******** ,-' `-. / ISP 1 V \ |ALTO Client| * / \ / +-------------+ \ +-----------+ * / ISP X \ | + ALTO Server | | +-----------+ * / \ \ +-------------+<====>| Peer 2 | * ; +---------+ : \ / |ALTO Client|****** * | | Global | | `-. ,-' +-----------+ * * | | Tracker | | `-------' * * | +---------+ | ,-------. +-----------+ * * : * ; ,-' ========>| Peer 3 | * * \ * / / ISP 2 V \ |ALTO Client|**** * * \ * / / +-------------+ \ +-----------+ * * * \ * / | | ALTO Server | | +-----------+ * * * `-. * ,-' \ +-------------+<====>| Peer 4 |** * * * `-*-' \ / |ALTO Client| * * * * * `-. ,-' +-----------+ * * * * * `-------' * * * * * * * * * ******************************************************* Legend: === ALTO protocol *** Application protocol Figure 21: Global Tracker and Local ALTO Servers Figure 21 depicts a tracker-based P2P system with several peers. The peers (i.e., resource consumers) embed an ALTO client to improve the resource provider selection. The tracker (i.e., resource directory) itself may be hosted and operated by another entity. A tracker external to the ISPs of the peers may be a typical use case. For instance, a tracker like Pirate Bay can serve BitTorrent peers worldwide. The figure only shows one tracker instance, but deployments with several trackers could be possible, too. The scenario depicted in Figure 21 lets the peers directly communicate with their ISP's ALTO server (i.e., ALTO client embedded in the peers), thus giving the peers the most control on which information they query for, as they can integrate information received from one tracker or several trackers and through direct peer-to-peer knowledge exchange. For instance, the latter approach
is called peer exchange (PEX) in BitTorrent. In this deployment scenarios, the peers have to discover a suitable ALTO server (e.g., offered by their ISP, as described in [RFC7286]). There are also tracker-less P2P system architectures that do not rely on centralized resource directories, e.g., unstructured P2P networks. Regarding the use of ALTO, their deployment would be similar to Figure 21, since the ALTO client would be embedded in the peers as well. This option is not further considered in this memo. ,-------. ,---. ,-' `-. +-----------+ ,-' `-. / ISP 1 \ | Peer 1 |******** / \ / +-------------+ \ | | * / ISP X \ ++====>| ALTO Server | )+-----------+ * / \ || \ +-------------+ / +-----------+ * ; +-----------+ : || \ / | Peer 2 | * | | Tracker |<====++ `-. ,-' | |****** * | |ALTO Client| | `-------' +-----------+ * * | +-----------+<====++ ,-------. * * : * ; || ,-' `-. +-----------+ * * \ * / || / ISP 2 \ | Peer 3 | * * \ * / || / +-------------+ \ | |**** * * \ * / ++====>| ALTO Server | )+-----------+ * * * `-. * ,-' \ +-------------+ / +-----------+ * * * `-*-' \ / | Peer 4 |** * * * * `-. ,-' | | * * * * * `-------' +-----------+ * * * * * * * * * * * * * * ********************************************************* Legend: === ALTO protocol *** Application protocol Figure 22: Global Tracker Accessing ALTO Server at Various ISPs An alternative deployment scenario for a tracker-based system is depicted in Figure 22. Here, the tracker embeds the ALTO client. When the tracker receives a request from a querying peer, it first discovers the ALTO server responsible for the querying peer. This discovery can be done by using various ALTO server discovery mechanisms [RFC7286] [XDOM-DISC]. The ALTO client subsequently sends to the querying peer only those peers that are preferred by the ALTO server responsible for the querying peer. The peers do not query the ALTO servers themselves. This gives the peers a better initial selection of candidates, but does not consider peers learned through direct peer-to-peer knowledge exchange.
ISP 1 ,-------. +-----------+ ,---. +-------------+******| Peer 1 | ,-' `-. /| Tracker |\ | | / \ / +-------------+**** +-----------+ / ISP X \ | === | * +-----------+ / \ \ +-------------+ / * | Peer 2 | ; +---------+ : \| ALTO Server |/ ***| | | | Global | | +-------------+ +-----------+ | | Tracker | | `-------' | +---------+ | +-----------+ : * ; ,-------. | Peer 3 | \ * / +-------------+ ****| | \ * / /| Tracker |*** +-----------+ \ * / / +-------------+ \ +-----------+ `-. * ,-' | === | | Peer 4 |** `-*-' \ +-------------+ / | | * * \| ALTO Server |/ +-----------+ * * +-------------+ * * ISP 2 `-------' * ************************************************* Legend: === ALTO protocol *** Application protocol Figure 23: Local Trackers and Local ALTO Servers (P4P Approach) There are some attempts to let ISPs deploy their own trackers, as shown in Figure 23. In this case, the client cannot get guidance from the ALTO server other than by talking to the ISP's tracker, which in turn communicates with the ALTO server using the ALTO protocol. It should be noted that the peers are still allowed to contact other trackers operated by entities other than the peer's ISP, but in this case they cannot benefit from ALTO guidance.4.2. Deployment Recommendations
4.2.1. ALTO Services
The ALTO protocol specification [RFC7285] details how an ALTO client can query an ALTO server for guiding information and receive the corresponding replies. In case of peer-to-peer networks, two different ALTO services can be used: the cost map service is often preferred as solution by peer-to-peer software implementors and users, since it avoids disclosing peer IP addresses to a centralized entity. Alternatively, network operators may have a preference for the ECS, since it does not require exposure of the network topology.
For actual use of ALTO in P2P applications, both software vendors and network operators have to agree which ALTO services to use. The ALTO protocol is flexible and supports both services. Note that for other use cases of ALTO, in particular in more controlled environments, both the cost map service and the ECS might be feasible; it is more of an engineering trade-off whether to use a map-based or query-based ALTO service.4.2.2. Guidance Considerations
As explained in Section 4.1.2, for a tracker-based P2P application, there are two fundamentally different possibilities where to place the ALTO client: 1. ALTO client in the resource consumer ("peer") 2. ALTO client in the resource directory ("tracker") Both approaches have advantages and drawbacks that have to be considered. If the ALTO client is in the resource consumer (Figure 21), a potentially very large number of clients has to be deployed. Instead, when using an ALTO client in the resource directory (Figures 22 and 23), ostensibly peers do not have to directly query the ALTO server. In this case, an ALTO server could even not permit access to peers. However, it seems to be beneficial for all participants to let the peers directly query the ALTO server. Considering the plethora of different applications that could use ALTO, e.g., multiple-tracker- based or non-tracker-based P2P systems or other applications searching for relays, this renders the ALTO service more useful. 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. For a given peer, one can also expect that an ALTO server of the corresponding ISP provides useful guidance and can be discovered. Yet, ALTO clients in the resource consumer also have drawbacks compared to use in the resource directory. In the following, both scenarios are compared more in detail in order to explain the impact on ALTO guidance and the need for third-party ALTO queries. In the first scenario (see Figure 24), the peer (resource consumer) queries the tracker (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.
Peer w. ALTO cli. Tracker ALTO Server --------+-------- --------+-------- --------+-------- | F1 Tracker query | | |======================>| | | F2 Tracker reply | | |<======================| | | F3 ALTO protocol query | |---------------------------------------------->| | F4 ALTO protocol reply | |<----------------------------------------------| | | | ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO protocol Figure 24: Basic Message Sequence Chart for Resource-Consumer-Initiated ALTO Query In the second scenario (see Figure 25), the resource directory has an embedded ALTO client, which we will refer to as Resource Directory ALTO Client (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). 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 protocol Figure 25: Basic Message Sequence Chart for Third-Party ALTO Query Note: The message sequences depicted in Figures 24 and 25 may occur both in the target-aware and the target-independent query mode (cf. [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 first approach has the following problem: 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. Much better traffic optimization could be achieved if the tracker would evaluate all known peers using ALTO. This list would then include a significantly higher fraction of "good" peers. 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 that contacted the tracker, the tracker must be able to discover an ALTO server that can give guidance suitable for that respective peer (see [XDOM-DISC]). In principle, a combined approach could also be possible. For instance, a tracker could use a coarse-grained "global" ALTO server to find the peers in the general vicinity of the requesting peer, while peers could use "local" ALTO servers for a more fine-grained guidance. Yet, there is no known deployment experience for such a combined approach.
(page 58 continued on part 4)