Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs

RFC 7971

 
 
 

Application-Layer Traffic Optimization (ALTO) Deployment Considerations

Part 2 of 4, p. 15 to 36
Prev Section       Next Section

 


prevText      Top      ToC       Page 15 
3.  Deployment Considerations by ISPs

3.1.  Objectives for the Guidance to Applications

3.1.1.  General Objectives for Traffic Optimization

   The Internet consists of many networks.  The networks are owned and
   managed by different network operators, such as commercial ISPs,
   enterprise IT departments, universities, and other organizations.
   These network operators provide network connectivity, e.g., by access
   networks, such as cable networks, xDSL networks, 3G/4G mobile
   networks, etc.  Network operators need to manage, control, and audit
   the traffic.  Therefore, it is important to understand how to deploy
   an ALTO service and what its expected impact might be.

   The general objective of ALTO is to give guidance to applications on
   what endpoints (e.g., 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 network operators to support application-level traffic
   engineering by influencing application resource provider selection.
   This traffic engineering can have different objectives:

   1.  Inter-network traffic localization: ALTO can help to reduce
       inter-domain traffic.  The networks of different network
       operators are interconnected through peering points.  From a
       business view, the inter-network settlement is needed for
       exchanging traffic between these networks.  These peering
       agreements can be costly.  To reduce these costs, a simple
       objective is to decrease the traffic exchange across the peering
       points and thus keep the traffic in the own network or Autonomous
       System (AS) as far as possible.

   2.  Intra-network traffic localization: In case of large network
       operators, the network may be grouped into several networks,
       domains, or ASes.  The core network includes one or several
       backbone networks, which are connected to multiple aggregation,
       metro, and access networks.  If traffic can be limited to certain
       areas such as access networks, this decreases the usage of
       backbone and thus helps to save resources and costs.

   3.  Network offloading: Compared to fixed networks, mobile networks
       have some special characteristics, including lower link
       bandwidth, high cost, limited radio frequency resource, and
       limited terminal battery.  In mobile networks, wireless links
       should be used efficiently.  For example, in the case of a P2P

Top      Up      ToC       Page 16 
       service, it is likely that hosts should prefer retrieving data
       from hosts in fixed networks, and avoid retrieving data from
       mobile hosts.

   4.  Application tuning: ALTO is also a tool to optimize the
       performance of applications that depend on the network and
       perform resource provider selection decisions among network
       endpoints; an example is the network-aware selection of CDN
       caches.

   In the following, these objectives are explained in more detail with
   examples.

3.1.2.  Inter-Network Traffic Localization

   ALTO guidance can be used to keep traffic local in a network, for
   instance, in order to reduce peering costs.  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).

Top      Up      ToC       Page 17 
                            ,-------.         +-----------+
          ,---.          ,-'         `-.      |   Host 1  |
       ,-'     `-.      /     ISP 1   ########|ALTO Client|
      /           \    /              #  \    +-----------+
     /    ISP X    \   |              #  |    +-----------+
    /               \  \              ########|   Host 2  |
   ;             +----------------------------|ALTO Client|
   |             |   |   `-.         ,-'      +-----------+
   |             |   |      `-------'
   |     Inter-  |   |      ,-------.         +-----------+
   :     network |   ;   ,-'         `########|   Host 3  |
    \    traffic |  /   /     ISP 2   # \     |ALTO Client|
     \           | /   /              #  \    +-----------+
      \          |/    |              #  |    +-----------+
       `-.     ,-|     \              ########|   Host 4  |
          `---'  +----------------------------|ALTO Client|
                         `-.         ,-'      +-----------+
                            `-------'

       Legend:
       ### preferred "connections"
       --- non-preferred "connections"

               Figure 5: Inter-Network Traffic Localization

   Examples for corresponding ALTO maps can be found in Section 3.5.
   Depending on the application characteristics, it may not be possible
   or even desirable to completely localize all traffic.

3.1.3.  Intra-Network Traffic Localization

   The previous section describes the results of the ALTO guidance on an
   inter-network level.  In the same way, ALTO can also be used for
   intra-network localization.  In this case, ALTO provides guidance on
   which internal hosts are to be preferred inside a single network
   (e.g., one AS).  This application-level traffic engineering can
   reduce the capacity requirements in the core network of an ISP.
   Figure 6 shows such a scenario where Host 1 and Host 2 are located in
   an access net 1 of ISP 1 and connect via a low capacity link to the
   core of the same ISP 1.  If Host 1 and Host 2 exchange their data
   with remote hosts, they would probably congest the bottleneck link.

Top      Up      ToC       Page 18 
              Bottleneck    ,-------.         +-----------+
          ,---.     |    ,-'         `-.      |   Host 1  |
       ,-'     `-.  |   /     ISP 1   ########|ALTO Client|
      /           \ |  /    (Access   #  \    +-----------+
     /    ISP 1    \|  |     net 1)   #  |    +-----------+
    /   (Core       V  \              ########|   Host 2  |
   ;    network) +--X~~~X---------------------|ALTO Client|
   |             |   |   `-.         ,-'      +-----------+
   |             |   |      `-------'
   |             |   |      ,-------.         +-----------+
   :             |   ;   ,-'         `########|   Host 3  |
    \            |  /   /     ISP 1   # \     |ALTO Client|
     \           | /   /     (Access  #  \    +-----------+
      \          |/    |      net 2)  #  |    +-----------+
       `-.     ,-X     \              ########|   Host 4  |
          `---'  ~~~~~~~X---------------------|ALTO Client|
                   ^     `-.         ,-'      +-----------+
                   |        `-------'
                Bottleneck
       Legend:
       ### preferred "connections"
       --- non-preferred "connections"

               Figure 6: Intra-Network Traffic Localization

   In such a situation, the operator can guide the hosts to try local
   hosts in the same network islands first, avoiding or at least
   lowering the effect on the bottleneck link, as shown in Figure 6.

   The objective is to avoid bottlenecks by optimized endpoint selection
   at the application level.  That said, it must be understood that ALTO
   is not a general-purpose method to deal with the congestion at the
   bottleneck.

3.1.4.  Network Offloading

   Another scenario is offloading traffic from networks.  This use of
   ALTO can be beneficial in particular in mobile networks.  A network
   operator may have the desire to guide hosts in its mobile network to
   use hosts outside this mobile network.  One reason could be that the
   wireless network or the mobile hosts were not designed for direct
   peer-to-peer communications between mobile hosts, and therefore, it
   makes sense for peers to fetch content from remote peers in other
   parts of the Internet.

Top      Up      ToC       Page 19 
                            ,-------.         +-----------+
          ,---.          ,-'         `-.      |   Host 1  |
       ,-'     `-.      /     ISP 1   +-------|ALTO Client|
      /           \    /    (Mobile   |  \    +-----------+
     /    ISP X    \   |    network)  |  |    +-----------+
    /               \  \              +-------|   Host 2  |
   ;             #############################|ALTO Client|
   |             #   |   `-.         ,-'      +-----------+
   |             #   |      `-------'
   |             #   |      ,-------.
   :             #   ;   ,-'         `-.
    \            #  /   /     ISP 2     \
     \           # /   /     (Fixed      \
      \          #/    |     network)    |    +-----------+
       `-.     ,-#     \                 /    |   Host 3  |
          `---'  #############################|ALTO Client|
                         `-.         ,-'      +-----------+
                            `-------'

       Legend:
       ### preferred "connections"
       --- non-preferred "connections"

              Figure 7: ALTO Traffic Network De-localization

   Figure 7 shows the result of such a guidance process where Host 2
   prefers a connection with Host 3 instead of Host 1, as shown in
   Figure 5.

   A realization of this scenario may have certain limitations and may
   not be possible in all cases.  For instance, it may require the ALTO
   server to distinguish mobile and non-mobile hosts based on their IP
   address.  This may depend on mobility solutions and may not be
   possible or accurate.  In general, ALTO is not intended as a fine-
   grained traffic engineering solution for individual hosts.  Instead,
   it typically works on aggregates (e.g., if it is known that certain
   IP prefixes are often assigned to mobile users).

3.1.5.  Application Tuning

   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 their 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

Top      Up      ToC       Page 20 
   alternative.  In addition, an ALTO server may also expose network
   information that applications cannot easily measure or reverse-
   engineer.

3.2.  Provisioning of ALTO Topology Data

3.2.1.  High-Level Process and Requirements

   A process to generate ALTO topology information typically comprises
   several steps.  The first step is to gather information, which is
   described in the following section.  The subsequent sections describe
   how the gathered data can be processed and which methods can be
   applied to generate the information exposed by ALTO, such as network
   and cost maps.

   Providing ALTO guidance can result in a win-win situation for network
   providers and users of the ALTO information.  Applications possibly
   get a better performance, while the network provider has means to
   optimize the traffic engineering and thus its costs.  Yet, there can
   be security concerns with exposing topology data.  Corresponding
   limitations are discussed in Section 7.2.

   ISPs may have important privacy requirements when deploying ALTO,
   which have to be taken into account when processing ALTO topology
   data.  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, determined by security policies.

   With the ECS, the ALTO client does not 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 and Cost Map Service expose an abstract view on the
   ISP network topology.  Therefore, care is needed when constructing
   those maps in order to take privacy policies into account, as further
   discussed in Section 3.2.3.  The ALTO protocol also supports further
   features such as endpoint properties, which could also be used to
   expose topology guidance.  The privacy considerations for ALTO maps
   also apply to such ALTO extensions.

Top      Up      ToC       Page 21 
3.2.2.  Data Collection from Data Sources

   The first step in the process of generating ALTO information is to
   gather the required information from the network.  An ALTO server can
   collect topological information from a variety of sources in the
   network and provides a cohesive, abstract view of the network
   topology to applications using an ALTO client.  Topology data sources
   may include routing protocols, network policies, state and
   performance information, geolocation, etc.  An ALTO server requires
   at least some topology and/or routing information, i.e., information
   about existing endpoints and their interconnection.  With this
   information, it is in principle possible to compute paths between all
   known endpoints.  Based on such basic data, the ALTO server builds an
   ALTO-specific network topology that represents the network as it
   should be understood and utilized by applications (resource
   consumers) at endpoints using ALTO services (e.g., Network and Cost
   Map Service or ECS).  A basic dataset can be extended by many other
   information obtainable from the network.

   The ALTO protocol does not assume a specific network technology or
   topology.  In principle, ALTO can be used with various types of
   addresses (Endpoint Addresses).  [RFC7285] defines the use of IPv4/
   IPv6 addresses or prefixes in ALTO, but further address types could
   be added by extensions.  In this document, only the use of IPv4/IPv6
   addresses is considered.

   The exposure of network topology information is controlled and
   managed by the ALTO server.  ALTO abstract network topologies can be
   automatically generated from the physical or logical topology of the
   network, e.g., using "live" network data.  The generation would
   typically be based on policies and rules set by the network operator.
   The maps and the guidance can significantly differ depending on the
   use case, the network architecture, and the trust relationship
   between ALTO server and ALTO client, etc.  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 operator has to ensure that the ALTO topology does
   not reveal any details that would endanger the network integrity and
   security.  For instance, ALTO is not intended to leak raw Interior
   Gateway Protocol (IGP) or Border Gateway Protocol (BGP) databases to
   ALTO clients.

Top      Up      ToC       Page 22 
                 +--------+   +--------+
                 |  ALTO  |   |  ALTO  |
                 | Client |   | Client |
                 +--------+   +--------+
                        /\     /\
                        ||     || ALTO protocol
                        ||     ||
                        \/     \/
                       +---------+
                       |  ALTO   |
                       | Server  |
                       +---------+
                        : :   : :
                        : :   : :
             +..........+ :   : +..........+ Provisioning
             :            :   :            : protocol
             :            :   :            :
     +---------+ +---------+ +---------+ +---------+
     |   BGP   | |   I2RS  | |   PCE   | |   NMS   | Potential
     | Speaker | |  Client | |         | |   OSS   | data sources
     +---------+ +---------+ +---------+ +---------+
          ^           ^           ^           ^
          |           |           |           |
     Link-State     I2RS         TED     Topology and traffic-related
      NLRI for      data         data    data from SNMP, NETCONF,
      IGP/BGP                            RESTCONF, REST, IPFIX, etc.

                 Figure 8: Potential Data Sources for ALTO

   As illustrated in Figure 8, the topology data used by an ALTO server
   can originate from different data sources:

   o  Relevant information sources are IGPs or BGP.  An ALTO server
      could get network routing information by listening to IGPs and/or
      peering with BGP speakers.  For data collection, link-state
      protocols are more suitable since every router propagates its
      information throughout the whole network.  Hence, it is possible
      to obtain information about all routers and their neighbors from
      one single router in the network.  In contrast, distance-vector
      protocols are less suitable since routing information is only
      shared among neighbors.  To obtain the whole topology with
      distance-vector routing protocols it is necessary to retrieve
      routing information from every router in the network.

   o  [RFC7752] describes a mechanism by which link-state and Traffic
      Engineering (TE) information can be collected from networks and
      shared with external components using the BGP routing protocol.
      This is achieved using a new BGP Network Layer Reachability

Top      Up      ToC       Page 23 
      Information (NLRI) encoding format.  The mechanism is applicable
      to physical and virtual IGP links and can also include TE data.
      For instance, prefix data can be carried and originated in BGP,
      while TE data is originated and carried in an IGP.  The mechanism
      described is subject to policy control.

   o  The Interface to the Routing System (I2RS) is a solution for state
      transfer in and out of the Internet's routing system [RFC7921].
      An ALTO server could use an I2RS client to observe routing-related
      information.  With the rise of Software-Defined Networking (SDN)
      and a decoupling of network data and control plane, topology
      information could also be fetched from an SDN controller.  If I2RS
      is used, [RFC7922] provides traceability for these interactions.
      This scenario is not further discussed in the remainder of this
      document.

   o  Another potential source of topology information could be a Path
      Computation Element (PCE) [RFC4655].  Topology and traffic-related
      information can be retrieved from the Traffic Engineering Database
      (TED) and Label Switched Path Database (LSP-DB).  This scenario is
      not further discussed in the remainder of this document.

   o  An ALTO server can also leverage a Network Management System (NMS)
      or an Operations Support System (OSS) as data sources.  NMS or OSS
      solutions are used to control, operate, and manage a network,
      e.g., using the Simple Network Management Protocol (SNMP) or
      Network Configuration Protocol (NETCONF).  As explained for
      instance in [RFC7491], the NMS and OSS can be consumers of network
      events reported and can act on these reports as well as displaying
      them to users and raising alarms.  In addition, NMS and OSS
      systems may have access to routing information and network
      inventory data (e.g., links, nodes, or link properties not visible
      to routing protocols, such as Shared Risk Link Groups).
      Furthermore, Operations, Administration, and Maintenance (OAM)
      information can be leveraged, including traffic utilization
      obtained from IP Flow Information Export (IPFIX), event
      notifications (e.g., via syslog), liveness detection (e.g.,
      bidirectional forwarding detection, BFD).  NMS or OSS systems also
      may have functions to correlate and orchestrate information
      originating from other data sources.  For instance, it could be
      required to correlate IP prefixes with routers (Provider, Provider
      Edge, Customer Edge, etc.), IGP areas, VLAN IDs, or policies.

   In the context of the provisioning protocol, topology information
   could be modeled in a YANG data model [NETWORK-TOPO].

Top      Up      ToC       Page 24 
   The data sources mentioned so far are only a subset of potential
   topology sources and protocols.  Depending on the network type,
   (e.g., mobile, satellite network) different hardware and protocols
   are in operation to form and maintain the network.

   In general, it is challenging to gather detailed information about
   the whole Internet, since the network consists of multiple domains
   and in many cases it is not possible to collect information across
   network borders.  Hence, potential information sources may be limited
   to a certain domain.

3.2.3.  Partitioning and Grouping of IP Address Ranges

   ALTO introduces provider-defined network location identifiers called
   Provider-defined Identifiers (PIDs) to aggregate network endpoints in
   the Map Services.  Endpoints within one PID may be treated as single
   entity, assuming proximity based on network topology or other
   similarity.  A key use case of PIDs is to specify network preferences
   (costs) between PIDs instead of individual endpoints.  It is up to
   the operator of the ALTO server how to group endpoints and how to
   assign PIDs.  For example, a PID may denote a subnet, a set of
   subnets, a metropolitan area, a POP, an autonomous system, or a set
   of autonomous systems.

   This document only considers deployment scenarios in which PIDs
   expand to a set of IP address ranges (CIDR).  A PID is characterized
   by a string identifier and its associated set of endpoint addresses
   [RFC7285].  If an ALTO server offers the Map Service, corresponding
   identifiers have to be configured.

   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.  This will typically be governed by policies that
   enforce a certain level of abstraction and prevent leakage of
   sensitive operational data.

   For instance, an ALTO server may leverage BGP information that is
   available in a network's service provider network layer and compute
   the group of prefix.  An example being BGP communities, which are
   used in MPLS/IP networks as a common mechanism to aggregate and group
   prefixes.  A 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).  These
   BGP communities could be used to map IP address ranges to PIDs.  By
   an additional policy, the ALTO server operator may decide an

Top      Up      ToC       Page 25 
   arbitrary cost defined between groups.  Alternatively, there are
   algorithms that allow the dynamic computation of costs between
   groups.  The ALTO protocol itself is independent of such algorithms
   and policies.

3.2.4.  Rating Criteria and/or Cost Calculation

   An ALTO server indicates preferences amongst network locations in the
   form of abstract costs.  These costs are generic costs and can be
   internally computed by the operator of the ALTO server according to
   its own policy.  For a given ALTO network map, an ALTO cost map
   defines directional costs pairwise amongst the set of source and
   destination network locations defined by the PIDs.

   The ALTO protocol permits the use of different cost types.  An ALTO
   cost type is defined by the combination of a cost metric and a cost
   mode.  The cost metric identifies what the costs represent.  The cost
   mode identifies how the costs should be interpreted, i.e., whether
   returned costs should be interpreted as numerical values or ordinal
   rankings.  The ALTO protocol also allows the definition of additional
   constraints defining which elements of a cost map shall be returned.

   The ALTO protocol specification [RFC7285] defines the "routingcost"
   cost metric as the basic set of rating criteria, which has to be
   supported by all implementations.  This cost metric conveys a generic
   measure for the cost of routing traffic from a source to a
   destination.  A lower value indicates a higher preference for traffic
   to be sent from a source to a destination.  How that metric is
   calculated is up to the ALTO server.

   It is possible to calculate the "routingcost" cost metric based on
   actual routing protocol information.  Typically, IGPs provide details
   about endpoints and links within a given network, while the BGP is
   used to provide details about links to endpoints in other networks.
   Besides topology and routing information, networks have a multitude
   of other attributes about their state, condition, and operation that
   comprises but is not limited to attributes like link utilization,
   bandwidth and delay, ingress/egress points of data flows from/towards
   endpoints outside of the network up to the location of nodes and
   endpoints.

   In order to enable use of extended information, there is a protocol
   extension procedure to add new ALTO cost types.  The following list
   gives an overview on further rating criteria that have been proposed
   or that are in use by ALTO-related prototype implementations.  This
   list is not intended as normative text.  Instead, its only purpose is
   to document and discuss rating criteria that have been proposed so
   far.  Whether such rating criteria are useful and whether the

Top      Up      ToC       Page 26 
   corresponding information would actually be made available by ISPs
   can also depend on the use case of ALTO.  A list of rating criteria
   for which normative specifications exist and which have successfully
   passed the IETF review process can be found at IANA's "ALTO Cost
   Metric Registry", available from [ALTO-REG].

   Distance-related rating criteria:

   o  Relative topological distance: The term relative means that a
      larger numerical value means greater distance, but it is up to the
      ALTO service how to compute the values, and the ALTO client will
      not be informed about the nature of the computation.  One way to
      determine relative topological distance may be counting AS hops,
      but when querying this parameter, the ALTO client must not assume
      that the numbers actually are AS hops.  In addition to the AS
      path, a relative cost value could also be calculated taking into
      account other routing protocol parameters, such as BGP local
      preference or Multi-Exit Discriminator (MED) attributes.

   o  Absolute topological distance, expressed in the number of
      traversed autonomous systems.

   o  Absolute topological distance, expressed in the number of router
      hops (i.e., how much the TTL value of an IP packet will be
      decreased during transit).

   o  Absolute physical distance, based on knowledge of the approximate
      geolocation (e.g., continent, country) of an IP address.

   Performance-related rating criteria:

   o  The minimum achievable throughput between the resource consumer
      and the candidate resource provider, which is considered useful by
      the application (only in ALTO queries).

   o  An arbitrary upper bound for the throughput from/to the candidate
      resource provider (only in ALTO responses).  This may be, but is
      not necessarily, the provisioned access bandwidth of the candidate
      resource provider.

   o  The maximum Round-Trip Time (RTT) between resource consumer and
      the candidate resource provider, which is acceptable for the
      application for useful communication with the candidate resource
      provider (only in ALTO queries).

Top      Up      ToC       Page 27 
   o  An arbitrary lower bound for the RTT between resource consumer and
      the candidate resource provider (only in ALTO responses).  This
      may be, for example, based on measurements of the propagation
      delay in a completely unloaded network.

   Charging-related rating criteria:

   o  Metrics representing an abstract cost, e.g., determined by
      policies that distinguish "cheap" from "expensive" IP subnet
      ranges without detailing the cost function.  According to
      [RFC7285], the abstract metric "routingcost" is an example for a
      metric for which the cost function does not have to be disclosed.

   o  Traffic volume caps, in case the Internet access of the resource
      consumer is not charged with a "flat rate".  For each candidate
      resource location, the ALTO service could indicate the amount of
      data or the bitrate that may be transferred from/to this resource
      location until a given point in time, and how much of this amount
      has already been consumed.  Furthermore, an ALTO server may have
      to indicate how excess traffic would be handled (e.g., blocked,
      throttled, or charged separately at an indicated price), e.g., by
      a new endpoint property.  This is outside the scope of this
      document.  Also, it is left for further study how several
      applications would interact if only some of them use this
      criterion.  Also left for further study is the use of such a
      criterion in resource directories that issue ALTO queries on
      behalf of other endpoints.

   All the above-listed rating criteria are subject to the remarks
   below:

   The ALTO client must be aware that with high probability the actual
   performance values will differ from whatever an ALTO server exposes.
   In particular, an ALTO client must not consider a 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 following facts:

   o  The ALTO service is not an admission control system.

   o  The ALTO service may not know the instantaneous congestion status
      of the network.

   o  The ALTO service may not know all link bandwidths, i.e., where the
      bottleneck really is, and there may be shared bottlenecks.

Top      Up      ToC       Page 28 
   o  The ALTO service may not have all information about the actual
      routing.

   o  The ALTO service may not know whether the candidate endpoint
      itself is overloaded.

   o  The ALTO service may not know whether the candidate endpoint
      throttles the bandwidth it devotes for the considered application.

   o  The ALTO service may not know whether the candidate endpoint will
      throttle the data it sends to the client (e.g., because of some
      fairness algorithm, such as tit for tat).

   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, the 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:

   o  Performance metrics that are closely related to the instantaneous
      congestion status.  The definition of alternate approaches for
      congestion control is explicitly out of the scope of ALTO.
      Instead, other appropriate means, such as using TCP-based
      transport, have to be used to avoid congestion.  In other words,
      ALTO is a service to provide network and policy information, with
      update intervals that are possibly several orders of magnitude
      slower than congestion-control loops (e.g., in TCP) can react on
      changes in network congestion state.  This clear separation of
      responsibilities avoids traffic oscillations and can help for
      network stability and cost optimization.

   o  Performance metrics that raise privacy concerns.  For instance, it
      has been questioned whether an ALTO service should publicly expose
      the provisioned access bandwidth of cable/DSL customers, as this
      could enable identification of "premium customers" of an ISP.

Top      Up      ToC       Page 29 
3.3.  ALTO Focus and Scope

   The purpose of this section is ensure that administrators and users
   of ALTO services are aware of the objectives of the ALTO protocol
   design.  Using ALTO beyond this scope may limit its efficiency.
   Likewise, Map-based and Endpoint-based ALTO Services may face certain
   issues during deployment.  This section explains these limitations
   and also outlines potential solutions.

3.3.1.  Limitations of Using ALTO beyond Design Assumptions

   ALTO is designed as a protocol between clients integrated in
   applications and servers that provide network information and
   guidance (e.g., basic network location structure and preferences of
   network paths).  The objective is to modify network resource
   consumption patterns at application level while maintaining or
   improving application performance.  This design focus results in a
   number of characteristics of ALTO:

   o  Endpoint focus: In typical ALTO use cases, neither the consumer of
      the topology information (i.e., the ALTO client) nor the
      considered resources (e.g., files at endpoints) are part of the
      network.  The ALTO server presents an abstract network topology
      containing only information relevant to an application overlay for
      better-than-random resource provider selection among its
      endpoints.  The ALTO protocol specification [RFC7285] is not
      designed to expose network internals such as routing tables or
      configuration data that are not relevant for application-level
      resource provider selection decisions in network endpoints.

   o  Abstraction: The ALTO services such as the Network and Cost Map
      Service or the ECS provide an abstract view of the network only.
      The operator of the ALTO server has full control over the
      granularity (e.g., by defining policies how to aggregate subnets
      into PIDs) and the level of detail of the abstract network
      representation (e.g., by deciding what cost types to support).

   o  Multiple administrative domains: The ALTO protocol is designed for
      use cases where the ALTO server and client can be located in
      different organizations or trust domains.  ALTO assumes a loose
      coupling between server and client.  In addition, ALTO does not
      assume that an ALTO client has any a priori knowledge about the
      ALTO server and its supported features.  An ALTO server can be
      discovered automatically.

   o  Read-only: ALTO is a query/response protocol to retrieve guidance
      information.  Neither network/cost map queries nor queries to the
      ECS are designed to affect state in the network.

Top      Up      ToC       Page 30 
   If ALTO shall be deployed for use cases beyond the scope defined by
   these assumptions, the protocol design may result in limitations.

   For instance, in an Application-Based Network Operations (ABNO)
   environment, the application could issue an explicit service request
   to the network [RFC7491].  In this case, the application would
   require detailed knowledge about the internal network topology and
   the actual state.  A network configuration would also require a
   corresponding security solution for authentication and authorization.
   ALTO is not designed for operations to control, operate, and manage a
   network.

   Such deployments could be addressed by network management solutions,
   e.g., based on SNMP [RFC3411] or NETCONF [RFC6241] and YANG
   [RFC6020], that are typically designed to manipulate configuration
   state.  [RFC7491] contains a more detailed discussion of interfaces
   between components such as Element Management System (EMS), Network
   Management System (NMS), Operational Support System (OSS), Traffic
   Engineering Database (TED), Label Switched Path Database (LSP-DB),
   Path Computation Element (PCE), and other Operations, Administration,
   and Maintenance (OAM) components.

3.3.2.  Limitations of Map-Based Services and Potential Solutions

   The specification of the Map Service in the ALTO protocol [RFC7285]
   is based on the concept of network maps.  A network map partitions
   the network into PIDs that group one or more endpoints (e.g.,
   subnetworks) to a single aggregate.  The "costs" between the various
   PIDs are stored in a cost map.  Map-based approaches such as the ALTO
   Network and Cost Map Service 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 long period of time.  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, and IP address assignment stays stable (and thus the mapping
   to the partitions).  However, there are several cases where this
   assumption is not valid:

   1.  ISPs reallocate IP subnets from time to time.

   2.  ISPs reallocate IP subnets on short notice.

   3.  IP prefix blocks may be assigned to a router that serves a
       variety of access networks.

Top      Up      ToC       Page 31 
   4.  Network costs between IP prefixes may change depending on the
       ISP's routing and traffic engineering.

   These effects can be explained as follows:

   Case 1: ISPs may reallocate IP 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" depends 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 IP address for as short
   as a few minutes or for months at a time or even longer.

   It has been suggested that ISPs providing ALTO services could
   subdivide their subscribers' devices into different IP subnets (or
   certain IP 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 IP subnets tends to decrease the
   efficiency of IP address allocation, in particular for IPv4.  A
   growing ISP that needs to maintain high efficiency of IP address
   utilization may be reluctant to jeopardize their future acquisition
   of IP address space.

   However, this is not an issue for map-based approaches if changes are
   applied in the order of days.

   Case 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.

   Case 3: In residential access networks (e.g., DSL, cable), IP
   prefixes are assigned to broadband gateways, which are the first IP-
   hop in the access-network between the Customer Premises Equipment
   (CPE) and the Internet.  The access-network between CPE and broadband
   gateway (called aggregation network) can have varying characteristics
   (and thus associated costs), but still using the same IP prefix.  For
   instance, one IP address IP1 out of a given CIDR prefix can be
   assigned to a VDSL access line (e.g., 2 Mbit/s uplink) while another
   IP address IP2 within the same given CIDR prefix is assigned to a
   slow ADSL line (e.g., 128 kbit/s uplink).  These IP addresses may be
   assigned on a first come first served basis, i.e., a single IP
   address out of the same CIDR 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.

Top      Up      ToC       Page 32 
   Case 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 maps and possibly also network maps can change.

   One solution to deal with map changes is to use incremental ALTO
   updates [UPDATE-SSE].

3.3.3.  Limitations of Non-Map-Based Services and Potential Solutions

   The specification of the ALTO protocol [RFC7285] also includes the
   ECS mechanism.  ALTO clients can ask the ALTO server for guidance for
   specific IP addresses, thereby avoiding the need of processing maps.
   This can mitigate some of the problems mentioned in the previous
   section.

   However, frequent requests, particularly with long lists of IP
   addresses, may overload the ALTO server.  The server has to rank each
   received IP address, which causes load at the server.  This may be
   amplified when a large number of ALTO clients are asking for
   guidance.  The results of the ECS are also more difficult to cache
   than ALTO maps.  Therefore, the ALTO client may have to await the
   server response before starting a communication, which results in an
   additional delay.

   Caching of IP addresses at the ALTO client or the use of the H12
   approach [ALTO-H12] in conjunction with caching may lower the query
   load on the ALTO server.

   When an ALTO server receives an ECS request, it may not have the most
   appropriate topology information in order to accurately determine the
   ranking.  [RFC7285] generally assumes that a server can always offer
   some guidance.  In such a case, the ALTO server could adopt one of
   the following strategies:

   o  Reply with available information (best effort).

   o  Query another ALTO server presumed to have better topology
      information and return that response (cascaded servers).

   o  Redirect the request to another ALTO server presumed to have
      better topology information (redirection).

   The protocol mechanisms and decision processes that would be used to
   determine if redirection is necessary and which mode to use is out of
   the scope of this document, since protocol extensions could be
   required.

Top      Up      ToC       Page 33 
3.4.  Monitoring ALTO

3.4.1.  Impact and Observation on Network Operation

   ALTO presents a new opportunity for managing network traffic by
   providing additional information to clients.  In particular, the
   deployment of an ALTO server may shift network traffic patterns, and
   the potential impact to network operation can be large.  An ISP
   providing ALTO may want to assess the benefits of ALTO as part of the
   management and operations (cf.  [RFC7285]).  For instance, the ISP
   might be interested in understanding whether the provided ALTO maps
   are effective in order to decide whether an adjustment of the ALTO
   configuration would be useful.  Such insight can be obtained from a
   monitoring infrastructure.  An ISP offering ALTO could consider the
   impact on (or integration with) traffic engineering and the
   deployment of a monitoring service to observe the effects of ALTO
   operations.  The measurement of impacts can be challenging because
   ALTO-enabled applications may not provide related information back to
   the ALTO service provider.

   To construct an effective monitoring infrastructure, the ALTO service
   provider should decide how to monitor the performance of ALTO and
   identify and deploy data sources to collect data to compute the
   performance metrics.  In certain trusted deployment environments, it
   may be possible to collect information directly from ALTO clients.
   It may also be possible to vary or selectively disable ALTO guidance
   for a portion of ALTO clients either by time, geographical region, or
   some other criteria to compare the network traffic characteristics
   with and without ALTO.  Monitoring an ALTO service could also be
   realized by third parties.  In this case, insight into ALTO data may
   require a trust relationship between the monitoring system operator
   and the network service provider offering an ALTO service.

   The required monitoring depends on the network infrastructure and the
   use of ALTO, and an exhaustive description is outside the scope of
   this document.

3.4.2.  Measurement of the Impact

   ALTO realizes an interface between the network and applications.
   This implies that an effective monitoring infrastructure may have to
   deal with both network and application performance metrics.  This
   document does not comprehensively list all performance metrics that
   could be relevant, nor does it formally specify metrics.

Top      Up      ToC       Page 34 
   The impact of ALTO can be classified regarding a number of different
   criteria:

   o  Total amount and distribution of traffic: ALTO enables ISPs to
      influence and localize traffic of applications that use the ALTO
      service.  Therefore, an ISP may be interested in analyzing the
      impact on the traffic, i.e., whether network traffic patterns are
      shifted.  For instance, if ALTO shall be used to reduce the inter-
      domain P2P traffic, it makes sense to evaluate the total amount of
      inter-domain traffic of an ISP.  Then, one possibility is to study
      how the introduction of ALTO reduces the total inter-domain
      traffic (inbound and/our outbound).  If the ISP's intention is to
      localize the traffic inside his network, the network-internal
      traffic distribution will be of interest.  Effectiveness of
      localization can be quantified in different ways, e.g., by the
      load on core routers and backbone links or by considering more-
      advanced effects, such as the average number of hops that traffic
      traverses inside a domain.

   o  Application performance: The objective of ALTO is to improve
      application performance.  ALTO can be used by very different types
      of applications, with different communication characteristics and
      requirements.  For instance, if ALTO guidance achieves traffic
      localization, one would expect that applications achieve a higher
      throughput and/or smaller delays to retrieve data.  If
      application-specific performance characteristics (e.g., video or
      audio quality) can be monitored, such metrics related to user
      experience could also help to analyze the benefit of an ALTO
      deployment.  If available, selected statistics from the TCP/IP
      stack in hosts could be leveraged, too.

   Of potential interest can also be the share of applications or
   customers that actually use an offered ALTO service, i.e., the
   adoption of the service.

   Monitoring statistics can be aggregated, averaged, and normalized in
   different ways.  This document does not mandate specific ways how to
   calculate metrics.

3.4.3.  System and Service Performance

   A number of interesting parameters can be measured at the ALTO
   server.  [RFC7285] suggests certain ALTO-specific metrics to be
   monitored:

   o  Requests and responses for each service listed in an Information
      Directory (total counts and size in bytes).

Top      Up      ToC       Page 35 
   o  CPU and memory utilization

   o  ALTO map updates

   o  Number of PIDs

   o  ALTO map sizes (in-memory size, encoded size, number of entries)

   This data characterizes the workload, the system performance as well
   as the map data.  Obviously, such data will depend on the
   implementation and the actual deployment of the ALTO service.
   Logging is also recommended in [RFC7285].

3.4.4.  Monitoring Infrastructures

   Understanding the impact of ALTO may require interaction between
   different systems operating at different layers.  Some information
   discussed in the preceding sections is only visible to an ISP, while
   application-level performance can hardly be measured inside the
   network.  It is possible that not all information of potential
   interest can directly be measured, either because no corresponding
   monitoring infrastructure or measurement method exists or because it
   is not easily accessible.

   One way to quantify the benefit of deploying ALTO is to measure
   before and after enabling the ALTO service.  In addition to passive
   monitoring, some data could also be obtained by active measurements,
   but due to the resulting overhead, the latter should be used with
   care.  Yet, in all monitoring activities, an ALTO service provider
   has to take into account that ALTO clients are not bound to ALTO
   server guidance as ALTO is only one source of information, and any
   measurement result may thus be biased.

   Potential sources for monitoring the use of ALTO include:

   o  Network monitoring and performance management systems: Many ISPs
      deploy systems to monitor the network traffic, which may have
      insight into traffic volumes, network topology, bandwidth
      information inside the management area.  Data can be obtained by
      SNMP, NETCONF, IP Flow Information Export (IPFIX), syslog, etc.
      On-demand OAM tests (such as Ping or BDF) could also be used.

   o  Applications/clients: Relevant data could be obtained by
      instrumentation of applications.

   o  ALTO server: If available, log files or other statistics data
      could be analyzed.

Top      Up      ToC       Page 36 
   o  Other application entities: In several use cases, there are other
      application entities that could provide data as well.  For
      instance, there may be centralized log servers that collect data.

   In many ALTO use cases, some data sources are located within an ISP
   network while some other data is gathered at the application level.
   Correlation of data could require a collaboration agreement between
   the ISP and an application owner, including agreements of data
   interchange formats, methods of delivery, etc.  In practice, such a
   collaboration may not be possible in all use cases of ALTO, because
   the monitoring data can be sensitive and because the interacting
   entities may have different priorities.  Details of how to build an
   overarching monitoring system for evaluating the benefits of ALTO are
   outside the scope of this memo.



(page 36 continued on part 3)

Next Section