3.1. Interface

The procedure specified in this document takes two parameters, X and SP, where X is an IP address or prefix and SP is a U-NAPTR Service Parameter.¶

The parameter X may be an IPv4 or an IPv6 address or prefix in Classless Inter-Domain Routing (CIDR) notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for IPv6). Consequently, the address type AT is either "IPv4" or "IPv6". In both cases, X consists of an IP address A and a prefix length L. From the definitions of IPv4 and IPv6, it follows that syntactically valid values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128 when AT=IPv6. However, not all syntactically valid values of L are actually supported by this procedure; Step 1 (see below) will check for unsupported values and report an error if necessary.¶

For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0, and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6, A=2001:0DB8::20, and L=128.¶

In the intended usage scenario, the procedure is normally always called with the parameter SP set to "ALTO:https". However, for general applicability and in order to support future extensions, the procedure MUST support being called with any valid U-NAPTR Service Parameter (see Section 4.5 of [RFC4848] for the syntax of U-NAPTR Service Parameters and Section 5 of the same document for information about the IANA registries).¶

The procedure performs DNS lookups and returns one or more URIs of information resources related to that IP address or prefix, usually the URIs of one or more ALTO Information Resource Directories (IRDs; see Section 9 of [RFC7285]). For each URI, the procedure also returns order and preference values (see Section 4.1 of [RFC3403]), which should be considered if more than one URI is returned.¶

During execution of this procedure, various error conditions may occur and have to be reported to the caller; see Section 3.5.¶

For the remainder of the document, we use the following notation for calling the ALTO Cross-Domain Server Discovery Procedure:    IRD_URIS_X = XDOMDISC(X,"ALTO:https")¶

3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup

First, the procedure checks the prefix length L for unsupported values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the procedure aborts and indicates an "unsupported prefix length" error to the caller. Similarly, if AT=IPv6 and L < 32, the procedure aborts and indicates an "unsupported prefix length" error to the caller. Otherwise, the procedure continues.¶

If AT=IPv4, the procedure will then produce a DNS domain name, which will be referred to as R32. This domain name is constructed according to the rules specified in Section 3.5 of [RFC1035], and it is rooted in the special domain "IN-ADDR.ARPA.".¶

For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.".¶

If AT=IPv6, a domain name, which will be called R128, is constructed according to the rules specified in Section 2.5 of [RFC3596], and the special domain "IP6.ARPA." is used.¶

For example (note: a line break was added after the second line),¶

A = 2001:0DB8::20    yields
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
        1.0.0.2.IP6.ARPA."

3.3. Step 2: Prepare Shortened Domain Names

For this step, an auxiliary function, "skip", is defined as follows: skip(str,n) will skip all characters in the string str, up to and including the n-th dot, and return the remaining part of str. For example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.".¶

If AT=IPv4, the following additional domain names are generated from the result of the previous step:¶

• R24=skip(R32,1),¶
• R16=skip(R32,2), and¶
• R8=skip(R32,3).¶

Removing one label from a domain name (i.e., one number of the "dotted quad notation") corresponds to shortening the prefix length by 8 bits.¶

For example,¶

R32="3.100.51.198.IN-ADDR.ARPA." yields
R24="100.51.198.IN-ADDR.ARPA."
R16="51.198.IN-ADDR.ARPA."
R8="198.IN-ADDR.ARPA."

If AT=IPv6, the following additional domain names are generated from the result of the previous step:¶

• R64=skip(R128,16),¶
• R56=skip(R128,18),¶
• R48=skip(R128,20),¶
• R40=skip(R128,22), and¶
• R32=skip(R128,24).¶

Removing one label from a domain name (i.e., one hex digit) corresponds to shortening the prefix length by 4 bits.¶

For example (note: a line break was added after the first line),¶

R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
        1.0.0.2.IP6.ARPA."    yields
R64  = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R56  = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R48  = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R40  = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32  = "8.B.D.0.1.0.0.2.IP6.ARPA."

3.4. Step 3: Perform DNS U-NAPTR Lookups

The address type and the prefix length of X are matched against the first and the second column of the following table, respectively:¶

Then, the domain name given in the 3rd column and the U-NAPTR Service Parameter SP with which the procedure was called (usually "ALTO:https") MUST be used for a U-NAPTR [RFC4848] lookup, in order to obtain one or more URIs (indicating protocol, host, and possibly path elements) for the ALTO server's Information Resource Directory (IRD). If such URIs can be found, the ALTO Cross-Domain Server Discovery Procedure returns that information to the caller and terminates successfully.¶

For example, the following two U-NAPTR resource records can be used for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in the previous step) to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird", with the former being preferred.¶

    100.51.198.IN-ADDR.ARPA.  IN NAPTR 100  10  "u"  "ALTO:https"
         "!.*!https://alto1.example.net/ird!"  ""

    100.51.198.IN-ADDR.ARPA.  IN NAPTR 100  20  "u"  "ALTO:https"
         "!.*!https://alto2.example.net/ird!"  ""

If no matching U-NAPTR records can be found, the procedure SHOULD try further lookups, using the domain names from the fourth column in the indicated order, until one lookup succeeds. If no IRD URI can be found after looking up all domain names from the 3rd and 4th columns, the procedure terminates unsuccessfully, returning an empty URI list.¶

3.5. Error Handling

The ALTO Cross-Domain Server Discovery Procedure may fail for several reasons.¶

If the procedure is called with syntactically invalid parameters or unsupported parameter values (in particular, the prefix length L; see Section 3.2), the procedure aborts, no URI list will be returned, and the error has to be reported to the caller.¶

The procedure performs one or more DNS lookups in a well-defined order (corresponding to descending prefix lengths, see Section 3.4) until one produces a usable result. Each of these DNS lookups might fail to produce a usable result, due to either a normal condition (e.g., a domain name exists, but no ALTO-specific NAPTR resource records are associated with it), a permanent error (e.g., nonexistent domain name), or a temporary error (e.g., timeout). In all three cases, and as long as there are further domain names that can be looked up, the procedure SHOULD immediately try to look up the next domain name (from Column 4 in the table given in Section 3.4). Only after all domain names have been tried at least once, the procedure MAY retry those domain names that had caused temporary lookup errors.¶

Generally speaking, ALTO provides advisory information for the optimization of applications (peer-to-peer applications, overlay networks, etc.), but applications should not rely on the availability of such information for their basic functionality (see Section 8.3.4.3 of [RFC7285]). Consequently, the speedy detection of an ALTO server, even though it may give less accurate answers than other servers, or the quick realization that there is no suitable ALTO server, is in general preferable to causing long delays by retrying failed queries. Nevertheless, if DNS queries have failed due to temporary errors, the ALTO Cross-Domain Server Discovery Procedure SHOULD inform its caller that DNS queries have failed for that reason and that retrying the discovery at a later point in time might give more accurate results.¶

4.1. Network and Cost Map Service

An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix X and get a list of one or more IRD URIs, including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRD(s) referenced by these URIs will always contain a network and a cost map, as these are mandatory information resources (see Section 11.2 of [RFC7285]). However, the cost matrix may be very sparse. If, according to the network map, PID_X is the Provider-defined Identifier (PID; see Section 5.1 of [RFC7285]) that contains the IP address or prefix X, and PID_1, PID_2, PID_3, ... are other PIDs, the cost map may look like this:¶

In this example, all cells outside Column X and Row X are unspecified. A cost map with this structure contains the same information as what could be retrieved using the Endpoint Cost Service, Cases 1 and 2 in Section 4.4. Accessing cells that are neither in Column X nor Row X may not yield useful results.¶

Trying to assemble a more densely populated cost map from several cost maps with this very sparse structure may be a nontrivial task, as different ALTO servers may use different PID definitions (i.e., network maps) and incompatible scales for the costs, in particular for the "routingcost" metric.¶

4.2. Map-Filtering Service

An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix X and get a list of one or more IRD URIs, including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRDs may provide the optional Map-Filtering Service (see Section 11.3 of [RFC7285]). This service returns a subset of the full map, as specified by the client. As discussed in Section 4.1, a cost map may be very sparse in the envisioned deployment scenario. Therefore, depending on the filtering criteria provided by the client, this service may return results similar to the Endpoint Cost Service, or it may not return any useful result.¶

4.3. Endpoint Property Service

If an ALTO client wants to query an Endpoint Property Service (see Section 11.4 of [RFC7285]) about an endpoint with IP address X or a group of endpoints within IP prefix X, respectively, it has to invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The result, IRD_URIS_X, is a list of one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]). Considering the order and preference values, the client has to check these IRDs for a suitable Endpoint Property Service and query it.¶

If the ALTO client wants to do a similar Endpoint Property query for a different IP address or prefix "Y", the whole procedure has to be repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a different list of IRD URIs. Of course, the results of individual DNS queries may be cached as indicated by their respective time-to-live (TTL) values.¶

4.4. Endpoint Cost Service

The optional ALTO Endpoint Cost Service (ECS; see Section 11.5 of [RFC7285]) provides information about costs between individual endpoints and also supports ranking. The ECS allows endpoints to be denoted by IP addresses or prefixes. The ECS is called with a list of one or more source IP addresses or prefixes, which we will call (S1, S2, S3, ...), and a list of one or more destination IP addresses or prefixes, called (D1, D2, D3, ...).¶

This specification distinguishes several cases, regarding the number of elements in the list of source and destination addresses, respectively:¶

1. Exactly one source address S1 and more than one destination addresses (D1, D2, D3, ...). In this case, the ALTO client has to invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) with that single source address as a parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result, IRD_URIS_S1, is a list of one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]). Considering the order and preference values, the client has to check these IRDs for a suitable Endpoint Cost Service and query it. The ECS is an optional service (see Section 11.5.1 of [RFC7285]), and therefore, it may well be that an IRD does not refer to an ECS.¶

   Calling the Cross-Domain Server Discovery Procedure only once with the single source address as a parameter -- as opposed to multiple calls, e.g., one for each destination address -- is not only a matter of efficiency. In the given scenario, it is advisable to send all ECS queries to the same ALTO server. This ensures that the results can be compared (e.g., for sorting candidate resource providers), even when cost metrics lack a well-defined base unit -- e.g., the "routingcost" metric.¶

2. More than one source address (S1, S2, S3, ...) and exactly one destination address D1. In this case, the ALTO client has to invoke the ALTO Cross-Domain Server Discovery Procedure with that single destination address as a parameter: IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result, IRD_URIS_D1, is a list of one or more URIs of IRDs. Considering the order and preference values, the client has to check these IRDs for a suitable ECS and query it.¶
3. Exactly one source address S1 and exactly one destination address D1. The ALTO client may perform the same steps as in Case 1, as specified above. As an alternative, it may also perform the same steps as in Case 2, as specified above.¶
4. More than one source address (S1, S2, S3, ...) and more than one destination address (D1, D2, D3, ...). In this case, the ALTO client should split the list of desired queries based on source addresses and perform separately for each source address the same steps as in Case 1, as specified above. As an alternative, the ALTO client may also group the list based on destination addresses and perform separately for each destination address the same steps as in Case 2, as specified above. However, comparing results between these subqueries may be difficult, in particular if the cost metric is a relative preference without a well-defined base unit (e.g., the "routingcost" metric).¶

See Appendix C for a detailed example showing the interaction of a tracker-based peer-to-peer application, the ALTO Endpoint Cost Service, and the ALTO Cross-Domain Server Discovery Procedure.¶

4.5. Summary and Further Extensions

Considering the four services defined in the ALTO base protocol specification [RFC7285], the ALTO Cross-Domain Server Discovery Procedure works best with the Endpoint Property Service (EPS) and the Endpoint Cost Service (ECS). Both the EPS and the ECS take one or more IP addresses as a parameter. The previous sections specify how the parameter for calling the ALTO Cross-Domain Server Discovery Procedure has to be derived from these IP addresses.¶

In contrast, the ALTO Cross-Domain Server Discovery Procedure seems less useful if the goal is to retrieve network and cost maps that cover the whole network topology. However, the procedure may be useful if a map centered at a specific IP address is desired (i.e., a map detailing the vicinity of said IP address or a map giving costs from said IP address to all potential destinations).¶

The interaction between further ALTO services (and their corresponding information resources) needs to be investigated and defined once such further ALTO services are specified in an extension document.¶

6.1. Integrity of the ALTO Server's URI

Scenario Description

An attacker could compromise the ALTO server discovery procedure or the underlying infrastructure in such a way that ALTO clients would discover a "wrong" ALTO server URI.¶

Threat Discussion

The Cross-Domain ALTO Server Discovery Procedure relies on a series of DNS lookups, in order to produce one or more URIs. If an attacker were able to modify or spoof any of the DNS records, the resulting URIs could be replaced by forged URIs. This is probably the most serious security concern related to ALTO server discovery. The discovered "wrong" ALTO server might not be able to give guidance to a given ALTO client at all, or it might give suboptimal or forged information. In the latter case, an attacker could try to use ALTO to affect the traffic distribution in the network or the performance of applications (see also Section 15.1 of [RFC7285]). Furthermore, a hostile ALTO server could threaten user privacy (see also Case (5a) in Section 5.2.1 of [RFC6708]).¶

Protection Strategies and Mechanisms

The application of DNS security (DNSSEC) [RFC4033] provides a means of detecting and averting attacks that rely on modification of the DNS records while in transit. All implementations of the Cross-Domain ALTO Server Discovery Procedure MUST support DNSSEC or be able to use such functionality provided by the underlying operating system. Network operators that publish U-NAPTR resource records to be used for the Cross-Domain ALTO Server Discovery Procedure SHOULD use DNSSEC to protect their subdomains of "in-addr.arpa." and/or "ip6.arpa.", respectively. Additional operational precautions for safely operating the DNS infrastructure are required in order to ensure that name servers do not sign forged (or otherwise "wrong") resource records. Security considerations specific to U-NAPTR are described in more detail in [RFC4848].¶

In addition to active protection mechanisms, users and network operators can monitor application performance and network traffic patterns for poor performance or abnormalities. If it turns out that relying on the guidance of a specific ALTO server does not result in better-than-random results, the usage of the ALTO server may be discontinued (see also Section 15.2 of [RFC7285]).¶

Note

The Cross-Domain ALTO Server Discovery Procedure finishes successfully when it has discovered one or more URIs. Once an ALTO server's URI has been discovered and the communication between the ALTO client and the ALTO server starts, the security threats and protection mechanisms discussed in the ALTO protocol specification [RFC7285] apply.¶

A threat related to the one considered above is the impersonation of an ALTO server after its correct URI has been discovered. This threat and protection strategies are discussed in Section 15.1 of [RFC7285]. The ALTO protocol's primary mechanism for protecting authenticity and integrity (as well as confidentiality) is the use of HTTPS-based transport -- i.e., HTTP over TLS [RFC2818]. Typically, when the URI's host component is a host name, a further DNS lookup is needed to map it to an IP address before the communication with the server can begin. This last DNS lookup (for A or AAAA resource records) does not necessarily have to be protected by DNSSEC, as the server identity checks specified in [RFC2818] are able to detect DNS spoofing or similar attacks after the connection to the (possibly wrong) host has been established. However, this validation, which is based on the server certificate, can only protect the steps that occur after the server URI has been discovered. It cannot detect attacks against the authenticity of the U-NAPTR lookups needed for the Cross-Domain ALTO Server Discovery Procedure, and therefore, these resource records have to be secured using DNSSEC.¶

C.1. A Generic Tracker-Based Peer-to-Peer Application

The optimization of peer-to-peer (P2P) applications such as BitTorrent was one of the first use cases that lead to the inception of the IETF ALTO working group. Further use cases have been identified as well, yet we will use this scenario to illustrate the operation and usefulness of the ALTO Cross-Domain Server Discovery Procedure.¶

For the remainder of this chapter, we consider a generic, tracker-based peer-to-peer file-sharing application. The goal is the dissemination of a large file, without using one large server with a correspondingly high upload bandwidth. The file is split into chunks. So-called "peers" assume the role of both a client and a server. That is, they may request chunks from other peers, and they may serve the chunks they already possess to other peers at the same time, thereby contributing their upload bandwidth. Peers that want to share the same file participate in a "swarm". They use the peer-to-peer protocol to inform each other about the availability of chunks and request and transfer chunks from one peer to another. A swarm may consist of a very large number of peers. Consequently, peers usually maintain logical connections to only a subset of all peers in the swarm. If a new peer wants to join a swarm, it first contacts a well-known server, the "tracker", which provides a list of IP addresses of peers in the swarm.¶

A swarm is an overlay network on top of the IP network. Algorithms that determine the overlay topology and the traffic distribution in the overlay may consider information about the underlying IP network, such as topological distance, link bandwidth, (monetary) costs for sending traffic from one host to another, etc. ALTO is a protocol for retrieving such information. The goal of such "topology-aware" decisions is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.¶

C.2. Architectural Options for Placing the ALTO Client

The ALTO protocol specification [RFC7285] details how an ALTO client can query an ALTO server for guiding information and receive the corresponding replies. However, in the considered scenario of a tracker-based P2P application, there are two fundamentally different possible locations for where to place the ALTO client:¶

1. ALTO client in the resource consumer ("peer")¶
2. ALTO client in the resource directory ("tracker")¶

In the following, both scenarios are compared in order to explain the need for ALTO queries on behalf of remote resource consumers.¶

In the first scenario (see Figure 2), the resource consumer queries the resource directory for the desired resource (F1). The resource directory returns a list of potential resource providers without considering ALTO (F2). It is then the duty of the resource consumer to invoke ALTO (F3/F4), in order to solicit guidance regarding this list.¶

In the second scenario (see Figure 4), the resource directory has an embedded ALTO client. After receiving a query for a given resource (F1), the resource directory invokes this ALTO client to evaluate all resource providers it knows (F2/F3). Then it returns a list, possibly shortened, containing the "best" resource providers to the resource consumer (F4).¶

 .............................          .............................
 : Tracker                   :          : Peer                      :
 :   ______                  :          :                           :
 : +-______-+                :          :            k good         :
 : |        |     +--------+ : P2P App. : +--------+ peers +------+ :
 : |   N    |     | random | : Protocol : | ALTO-  |------>| data | :
 : | known  |====>| pre-   |*************>| biased |       | ex-  | :
 : | peers, |     | selec- | : transmit : | peer   |------>| cha- | :
 : | M good |     | tion   | : n peer   : | select | n-k   | nge  | :
 : +-______-+     +--------+ : IDs      : +--------+ bad p.+------+ :
 :...........................:          :.....^.....................:
                                              |
                                              | ALTO protocol
                                            __|___
                                          +-______-+
                                          |        |
                                          | ALTO   |
                                          | server |
                                          +-______-+

Peer w. ALTO cli.            Tracker               ALTO Server
--------+--------       --------+--------       --------+--------
        | F1 Tracker query      |                       |
        |======================>|                       |
        | F2 Tracker reply      |                       |
        |<======================|                       |
        | F3 ALTO query         |                       |
        |---------------------------------------------->|
        | F4 ALTO reply         |                       |
        |<----------------------------------------------|
        |                       |                       |

====  Application protocol (i.e., tracker-based P2P app protocol)
----  ALTO protocol

 .............................          .............................
 : Tracker                   :          : Peer                      :
 :   ______                  :          :                           :
 : +-______-+                :          :                           :
 : |        |     +--------+ : P2P App. :  k good peers &  +------+ :
 : |   N    |     | ALTO-  | : Protocol :  n-k bad peers   | data | :
 : | known  |====>| biased |******************************>| ex-  | :
 : | peers, |     | peer   | : transmit :                  | cha- | :
 : | M good |     | select | : n peer   :                  | nge  | :
 : +-______-+     +--------+ : IDs      :                  +------+ :
 :.....................^.....:          :...........................:
                       |
                       | ALTO protocol
                     __|___
                   +-______-+
                   |        |
                   | ALTO   |
                   | server |
                   +-______-+

      Peer             Tracker w. ALTO cli.       ALTO Server
--------+--------       --------+--------       --------+--------
        | F1 Tracker query      |                       |
        |======================>|                       |
        |                       | F2 ALTO query         |
        |                       |---------------------->|
        |                       | F3 ALTO reply         |
        |                       |<----------------------|
        | F4 Tracker reply      |                       |
        |<======================|                       |
        |                       |                       |

====  Application protocol (i.e., tracker-based P2P app protocol)
----  ALTO protocol

C.3. Evaluation

The problem with the first approach is that while the resource directory might know thousands of peers taking part in a swarm, the list returned to the resource consumer is usually shortened for efficiency reasons. Therefore, the "best" (in the sense of ALTO) potential resource providers might not be contained in that list anymore, even before ALTO can consider them.¶

For illustration, consider a simple model of a swarm, in which all peers fall into one of only two categories: assume that there are only "good" (in the sense of ALTO's better-than-random peer selection, based on an arbitrary desired rating criterion) and "bad" peers. Having more different categories makes the math more complex but does not change anything about the basic outcome of this analysis. Assume that the swarm has a total number of N peers, out of which there are M "good" and N-M "bad" peers, which are all known to the tracker. A new peer wants to join the swarm and therefore asks the tracker for a list of peers.¶

If, according to the first approach, the tracker randomly picks n peers from the N known peers, the result can be described with the hypergeometric distribution. The probability that the tracker reply contains exactly k "good" peers (and n-k "bad" peers) is:¶

            / M \   / N - M \
            \ k /   \ n - k /
P(X=k) =  ---------------------
                  / N \
                  \ n /


        / n \        n!
with    \ k /  = -----------    and   n! = n * (n-1) * (n-2) * .. * 1
                  k! (n-k)!

The probability that the reply contains at most k "good" peers is: P(X<=k) = P(X=0) + P(X=1) + .. + P⁠(X=k).¶

For example, consider a swarm with N=10,000 peers known to the tracker, out of which M=100 are "good" peers. If the tracker randomly selects n=100 peers, the formula yields for the reply: P⁠(X=0)=36%, P(X<=4)=99%. That is, with a probability of approximately 36%, this list does not contain a single "good" peer, and with 99% probability, there are only four or fewer of the "good" peers on the list. Processing this list with the guiding ALTO information will ensure that the few favorable peers are ranked to the top of the list; however, the benefit is rather limited as the number of favorable peers in the list is just too small.¶

Much better traffic optimization could be achieved if the tracker would evaluate all known peers using ALTO and return a list of 100 peers afterwards. This list would then include a significantly higher fraction of "good" peers. (Note that if the tracker returned "good" peers only, there might be a risk that the swarm might disconnect and split into several disjunct partitions. However, finding the right mix of ALTO-biased and random peer selection is out of the scope of this document.)¶

Therefore, from an overall optimization perspective, the second scenario with the ALTO client embedded in the resource directory is advantageous, because it is ensured that the addresses of the "best" resource providers are actually delivered to the resource consumer. An architectural implication of this insight is that the ALTO server discovery procedures must support ALTO queries on behalf of remote resource consumers. 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 peer. This task can be solved using the ALTO Cross-Domain Server Discovery Procedure.¶

¶

C.4. Example

This section provides a complete example of the ALTO Cross-Domain Server Discovery Procedure in a tracker-based peer-to-peer scenario.¶

The example is based on the network topology shown in Figure 5. Five access networks -- Networks a, b, c, x, and t -- are operated by five different network operators. They are interconnected by a backbone structure. Each network operator runs an ALTO server in their network -- i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and ALTO_SRV_T, respectively.¶

     _____    __             _____    __             _____    __
  __(     )__(  )_        __(     )__(  )_        __(     )__(  )_
 (    Network a   )      (    Network b   )      (    Network c   )
( Res. Provider A  )    ( Res. Provider B  )    ( Res. Provider C  )
 (__ ALTO_SRV_A __)      (__ ALTO_SRV_B __)      (__ ALTO_SRV_C __)
   (___)--(____) \         (___)--(____)         / (___)--(____)
                  \           /                 /
                ---+---------+-----------------+----
               (              Backbone              )
                ------------+------------------+----
                _____    __/            _____   \__
             __(     )__(  )_        __(     )__(  )_
            (    Network x   )      (    Network t   )
           ( Res. Consumer X  )    (Resource Directory)
            (_  ALTO_SRV_X __)      (_  ALTO_SRV_T __)
              (___)--(____)           (___)--(____)  

A new peer of a peer-to-peer application wants to join a specific swarm (overlay network), in order to access a specific resource. This new peer will be called "Resource Consumer X", in accordance with the terminology of [RFC6708], and is located in Network x. It contacts the tracker ("Resource Directory"), which is located in Network t. The mechanism by which the new peer discovers the tracker is out of the scope of this document. The tracker maintains a list of peers that take part in the overlay network, and hence it can determine that Resource Providers A, B, and C are candidate peers for Resource Consumer X.¶

As shown in the previous section, a tracker-side ALTO optimization (cf. Figures 3 and 4) is more efficient than a client-side optimization. Consequently, the tracker wants to use the ALTO Endpoint Cost Service (ECS) to learn the routing costs between X and A, X and B, and X and C, in order to sort A, B, and C by their respective routing costs to X.¶

In theory, there are many options for how the ALTO Cross-Domain Server Discovery Procedure could be used. For example, the tracker could do the following steps:¶

IRD_URIS_A = XDOMDISC(A,"ALTO:https")
COST_X_A   = query the ECS(X,A,routingcost) found in IRD_URIS_A

IRD_URIS_B = XDOMDISC(B,"ALTO:https")
COST_X_B   = query the ECS(X,B,routingcost) found in IRD_URIS_B

IRD_URIS_C = XDOMDISC(C,"ALTO:https")
COST_X_C   = query the ECS(X,C,routingcost) found in IRD_URIS_C

In this scenario, the ALTO Cross-Domain Server Discovery Procedure queries might yield: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B = ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. That is, each ECS query would be sent to a different ALTO server. The problem with this approach is that we are not necessarily able to compare COST_X_A, COST_X_B, and COST_X_C with each other. The specification of the routingcost metric mandates that "A lower value indicates a higher preference", but "an ISP may internally compute routing cost using any method that it chooses" (see Section 6.1.1.1 of [RFC7285]). Thus, COST_X_A could be 10 (milliseconds round-trip time), while COST_X_B could be 200 (kilometers great circle distance between the approximate geographic locations of the hosts) and COST_X_C could be 3 (router hops, corresponding to a decrease of the TTL field in the IP header). Each of these metrics fulfills the "lower value is more preferable" requirement on its own, but they obviously cannot be compared with each other. Even if there were a reasonable formula to compare, for example, kilometers with milliseconds, we could not use it, as the units of measurement (or any other information about the computation method for the routingcost) are not sent along with the value in the ECS reply.¶

To avoid this problem, the tracker tries to send all ECS queries to the same ALTO server. As specified in Section 4.4 of this document, Case 2, it uses the IP address of Resource Consumer x as a parameter of the discovery procedure:¶

IRD_URIS_X = XDOMDISC(X,"ALTO:https")
COST_X_A   = query the ECS(X,A,routingcost) found in IRD_URIS_X
COST_X_B   = query the ECS(X,B,routingcost) found in IRD_URIS_X
COST_X_C   = query the ECS(X,C,routingcost) found in IRD_URIS_X

This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be compared with each other.¶

¶

As discussed above, the tracker calls the ALTO Cross-Domain Server Discovery Procedure with IP address X as a parameter. For the remainder of this example, we assume that X = 2001:DB8:1:2:227:eff:fe6a:de42. Thus, the procedure call is IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https").¶

The first parameter, 2001:DB8:1:2:227:eff:fe6a:de42, is a single IPv6 address. Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42, L = 128, and SP = "ALTO:https".¶

The procedure constructs (see Step 1 in Section 3.2)¶

R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0.
        8.B.D.0.1.0.0.2.IP6.ARPA."

as well as the following (see Step 2 in Section 3.2):¶

R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA." 
R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."

In order to illustrate the third step of the ALTO Cross-Domain Server Discovery Procedure, we use the "dig" (domain information groper) DNS lookup utility that is available for many operating systems (e.g., Linux). A real implementation of the ALTO Cross-Domain Server Discovery Procedure would not be based on the "dig" utility but instead would use appropriate libraries and/or operating-system APIs. Please note that the following steps have been performed in a controlled lab environment with an appropriately configured name server. A suitable DNS configuration will be needed to reproduce these results. Please also note that the rather verbose output of the "dig" tool has been shortened to the relevant lines.¶

Since AT = IPv6 and L = 128, in the table given in Section 3.4, the sixth row (not counting the column headers) applies.¶

As mandated by the third column, we start with a lookup of R128, looking for NAPTR resource records:¶

| user@labpc:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\
| 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| 
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26553
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0

The domain name R128 does not exist (status: NXDOMAIN), so we cannot get a useful result. Therefore, we continue with the fourth column of the table and do a lookup of R64:¶

| user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| 
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0

The domain name R64 could be looked up (status: NOERROR), but there are no NAPTR resource records associated with it (ANSWER: 0). There may be some other resource records such as PTR, NS, or SOA, but we are not interested in them. Thus, we do not get a useful result, and we continue with looking up R56:¶

| user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| 
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| 
| ;; ANSWER SECTION:
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" 
|  "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" .
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u"
|  "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .

The domain name R56 could be looked up, and there are NAPTR resource records associated with it. However, each of these records has a service parameter that does not match our SP = "ALTO:https" (see [RFC7216] for "LIS:HELD"), and therefore we have to ignore them. Consequently, we still do not have a useful result and continue with a lookup of R48:¶

| user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| 
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| 
| ;; ANSWER SECTION:
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
|  "ALTO:https" "!.*!https://alto1.example.net/ird!" .
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
|  "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" .

This lookup yields two NAPTR resource records. We have to ignore the second one as its service parameter does not match our SP, but the first NAPTR resource record has a matching service parameter. Therefore, the procedure terminates successfully and the final outcome is: IRD_URIS_X = "https://alto1.example.net/ird".¶

The ALTO client that is embedded in the tracker will access the ALTO Information Resource Directory (IRD, see Section 9 of [RFC7285]) at this URI, look for the Endpoint Cost Service (ECS, see Section 11.5 of [RFC7285]), and query the ECS for the costs between A and X, B and X, and C and X, before returning an ALTO-optimized list of candidate resource providers to resource consumer X.¶