Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7971

Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Pages: 77
Informational
Part 3 of 4 – Pages 36 to 58
First   Prev   Next

Top   ToC   RFC7971 - Page 36   prevText

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.
Top   ToC   RFC7971 - Page 37
              -----------
          ////           \\\\
        //                   \\
      //                       \\                  /-----------\
     | +---------+               |             ////             \\\\
     | | 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.
Top   ToC   RFC7971 - Page 38
      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
Top   ToC   RFC7971 - Page 39

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
Top   ToC   RFC7971 - Page 40
   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

3.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.
Top   ToC   RFC7971 - Page 41
   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.
Top   ToC   RFC7971 - Page 42

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.
Top   ToC   RFC7971 - Page 43
   +-------------------+    +-----+    +-----+    +-------------------+
   |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).
Top   ToC   RFC7971 - Page 44
   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, bandwidth

3.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.
Top   ToC   RFC7971 - Page 45
   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.
Top   ToC   RFC7971 - Page 46
      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:
Top   ToC   RFC7971 - Page 47
      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
Top   ToC   RFC7971 - Page 48
   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.
Top   ToC   RFC7971 - Page 49

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.
Top   ToC   RFC7971 - Page 50
         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
Top   ToC   RFC7971 - Page 51
      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].
Top   ToC   RFC7971 - Page 52
   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.
Top   ToC   RFC7971 - Page 53

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
Top   ToC   RFC7971 - Page 54
   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.
Top   ToC   RFC7971 - Page 55
                      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.
Top   ToC   RFC7971 - Page 56
   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.
Top   ToC   RFC7971 - Page 57
   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
Top   ToC   RFC7971 - Page 58
   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)

Next Section