[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-alto-xdom-disc

ALTO                                                           S. Kiesel
Internet-Draft                                   University of Stuttgart
Intended status: Informational                            M. Stiemerling
Expires: January 5, 2015                                            H-DA
                                                            July 4, 2014


   Application Layer Traffic Optimization (ALTO) Cross-Domain Server
                               Discovery
                     draft-kiesel-alto-xdom-disc-00

Abstract

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications that have to select one or several
   hosts from a set of candidates capable of providing a desired
   resource.  ALTO is realized by a client-server protocol.  Before an
   ALTO client can ask for guidance it needs to discover one or more
   ALTO servers that can provide suitable guidance.

   In some deployment scenarios, in particular if the information about
   the network topology is partitioned and distributed over several ALTO
   servers, an ALTO client may need to discover an ALTO server outside
   of its own network domain, in order to get appropriate guidance.

   This document details applicable scenarios, itemizes requirements,
   and analyzes existing solution approaches for such ALTO cross-domain
   server discovery.  However, the specification of a procedure is
   beyond the scope of this document.  Note, that in earlier versions of
   this document, ALTO cross-domain server discovery was referred to as
   "third-party discovery", but it has been renamed to avoid naming
   ambiguities.



















Kiesel & Stiemerling     Expires January 5, 2015                [Page 1]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


Terminology and Requirements Language

   This document makes use of the ALTO terminology defined in RFC 5693
   [RFC5693].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 5, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.











Kiesel & Stiemerling     Expires January 5, 2015                [Page 2]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Document History . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Feedback . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The Need for ALTO Cross-Domain Server Discovery  . . . . . . .  5
     2.1.  Partitioned ALTO Knowledge . . . . . . . . . . . . . . . .  5
     2.2.  ALTO Queries on behalf of a Third Party  . . . . . . . . .  6
     2.3.  Partitioned Knowledge and Queries for a a Third Party  . .  7
     2.4.  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Requirements for ALTO Cross-Domain Server Discovery  . . . . .  9
     3.1.  Discovery Client Application Programming Interface . . . .  9
     3.2.  Data Storage and Authority Requirements  . . . . . . . . .  9
     3.3.  Cross-Domain Operations Requirements . . . . . . . . . . .  9
     3.4.  Protocol Requirements  . . . . . . . . . . . . . . . . . . 10
     3.5.  Further Requirements . . . . . . . . . . . . . . . . . . . 10
   4.  Related IETF Protocols and Activities  . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  ALTO and Tracker-based Peer-to-Peer Applications  . . 16
   Appendix B.  Contributors List and Acknowledgments . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22


























Kiesel & Stiemerling     Expires January 5, 2015                [Page 3]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


1.  Introduction

   Application-Layer Traffic Optimization (ALTO) [RFC5693] is realized
   by an HTTP-based client-server protocol [RFC7285].  Before an ALTO
   client can issue ALTO queries, it needs to discover a suitable ALTO
   server.  During the design phase of the overall ALTO solution, two
   different server discovery scenarios have been identified and
   documented in the ALTO requirements document [RFC6708].

   In the first scenario, documented in Req. AR-32, it is sufficient for
   a given ALTO client to discover a single ALTO server (or a small
   number of ALTO servers with identical knowledge, for reasons of
   reliability), usually the nearest one, as recommended by the operator
   of the access network.  A discovery mechanism for this scenario,
   based on DHCP and DNS, is specified in [RFC7286].  An alternative
   approach, based on IP anycast, is documented in
   [I-D.kiesel-alto-ip-based-srv-disc].

   In the second scenario, documented in Req. AR-33, an ALTO client may
   need to discover many different ALTO servers, depending on the
   queries it wants to issue.  These ALTO servers may be located in
   other network domains than the client is.  This document details
   applicable scenarios, itemizes requirements, and analyzes existing
   solution approaches for such ALTO cross-domain server discovery.
   However, the specification of a procedure is beyond the scope of this
   document.  An experimental discovery procedure, which fulfills the
   requirements documented here, but which is currently not recommended
   for usage in the Internet, is documented in
   draft-kiesel-alto-xdom-disc-alg-00.txt.

1.1.  Document History

   This document is a direct successor of [I-D.kiesel-alto-3pdisc] and
   [I-D.kist-alto-3pdisc].  The scenario and mechanisms described here
   and in these documents have been referred to as "third-party server
   discovery" in the past.  However, to avoid ambiguities with a
   completely different scenario, it has been renamed to "ALTO Cross-
   Domain Server Discovery".

1.2.  Feedback

   Comments and discussions about this document should be directed to
   the ALTO working group: alto@ietf.org.








Kiesel & Stiemerling     Expires January 5, 2015                [Page 4]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


2.  The Need for ALTO Cross-Domain Server Discovery

   ALTO Cross-Domain Server discovery is needed, if two independent
   effects appear at the conjunction: partitioned knowledge and clients
   sending queries on behalf of other hosts.  The following two
   subsections will discuss these effects separately, before the next
   subsection will discuss the combination of both.

2.1.  Partitioned ALTO Knowledge

   ALTO is realized by an HTTP-based client-server protocol.  Basically,
   this protocol allows ALTO clients to download "cost maps", which
   indicate costs or other properties (according to various metrics) of
   the data path between endpoints.  Furthermore, ALTO clients may
   access only parts of a cost map through the "map filtering service",
   and they may query endpoint properties through the "endpoint property
   service".  Further similar services exist; for details refer to
   [RFC7285].  The endpoints are usually identified through their IP
   addresses.  For efficiency reasons, endpoints may be grouped by using
   IP address prefixes and the "network map" with provider-defined
   identifiers (PIDs) defined within the ALTO protocol.

   Conceptually, the ALTO protocol allows to query for path costs
   between arbitrary IP addresses from the whole IP address range, i.e.,
   a full 2^32 x 2^32 matrix for IPv4 and a 2^128 x 2^128 matrix for
   IPv6 (The "PID" mechanism introduced in the ALTO protocol makes
   storage and transmission more efficient but does not alter that basic
   principle).  And in fact, there may be deployment scenarios where a
   single ALTO server (or a cluster of servers operated by a single
   organization) has this "Internet-wide view", e.g., a community
   project collecting end-to-end measurements.

   However, a very important class of scenarios is, when guiding
   information actually originates from the (access) network operators,
   such as Internet Service Providers (ISPs), IT departments of large
   companies or universities, etc.  The information available at each of
   these providers will not be a full NxN matrix, but more like a 1xN
   vector, i.e., indicating cost "from us to anywhere" while cost "from
   anywhere to anywhere" is unknown.  Several options exist how these
   pieces of information could be exposed to the ALTO clients, at least
   in theory:

   1.  The individual 1xN vectors could be aggregated to a virtual
       network-wide NxN matrix.  This virtual matrix could be exposed
       through a single ALTO server or through a cluster of ALTO servers
       with identical information.  However, no back-end protocol and
       process for this aggregation is currently defined.




Kiesel & Stiemerling     Expires January 5, 2015                [Page 5]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


   2.  Each (access) network operator could operate their own ALTO
       server, which only has this partial knowledge available there.
       Requests for unknown (source,destination)-pairs would be
       redirected to another ALTO server.  The idea has been discussed
       [I-D.kiesel-alto-alto4alto] but no complete specification exists.
       A related option would be to establish something similar to a web
       search engine, which would do the redirecting.  But again, no
       detailed specification exists.

   3.  Each (access) network operator could operate their own ALTO
       server, which only has this partial knowledge available there.
       It would be the duty of the client-side ALTO server discovery
       mechanism to directly find an ALTO server that can reasonably
       answer a given query.  This option will be considered in more
       detail in the remainder of this memo.

2.2.  ALTO Queries on behalf of a Third Party

   An ALTO client may be co-located with or embedded into the resource
   consumer, i.e., the entity that seeks to access the desired resource
   and that will be one endpoint of the data transmission to be
   optimized.  This kind of ALTO client will most often only be
   interested in "cost from me to somewhere else" queries, i.e., in an
   1xN matrix.

   In contrast, the ALTO client may also be located at some kind of
   directory server, P2P tracker, CDN redirect server, etc., i.e., at
   some entity that takes part in the application signaling but is not
   the endpoint of the actual user data transmission to be optimized.
   From an ALTO perspective, this kind of ALTO client does not issue
   ALTO queries for its own optimization needs, but instead it issues
   queries on behalf of remote third parties.

   One motivation for this second type of configuration is faster
   deployment, as only some central servers would have to be equipped
   with an ALTO client and not all the clients.  Furthermore, only these
   central servers (e.g., servers of a CDN) would need to access the
   ALTO servers, while the less-trusted clients could be denied to
   access the topology and cost maps.  Another important reason is, that
   in some scenarios, much better optimization results can be achieved,
   if the ALTO guidance is considered at a central resource directory.
   See Appendix A for a detailed case study and analysis of such a
   scenario.

   In the second scenario, ALTO queries may be interested in the path
   costs from an arbitrary point in the network topology (where the
   third party is, on behalf of which the query is sent) to other
   arbitrary points in the topology (where the candidate resource



Kiesel & Stiemerling     Expires January 5, 2015                [Page 6]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


   providers are located).  That is, such ALTO clients might want to
   access the full (virtual) NxN matrices.

   A more detailed discussion of various options where to place the
   functional entities comprising the overall ALTO architecture can be
   found in [I-D.ietf-alto-deployments].

2.3.  Partitioned Knowledge and Queries for a a Third Party

   As long as all ALTO servers store identical information, an ALTO
   client can send its queries to any server.  A procedure for finding
   an ALTO server by means of DHCP is specified in [RFC7286].

   If ALTO knowledge is partitioned and distributed over several ALTO
   servers and the ALTO client is co-located with a resource consumer,
   the DHCP based discovery procedure [RFC7286] will most likely work as
   well.  The reason is, that this kind of ALTO client will only issue
   queries for "costs from me to anywhere", and the network operator can
   configure via DHCP an ALTO server that can answer these types of
   query.

   If, however, ALTO knowledge is partitioned and distributed over
   several ALTO servers and the ALTO client issues ALTO queries on
   behalf of third parties, a different kind of server discovery
   mechanism is needed.  These ALTO queries will ask for the "costs from
   X to anywhere" (where X is the IP address or PID of the third party).
   For each of these queries a suitable ALTO server has to be found and
   X will be the parameter for the discovery mechanism.

2.4.  Example

   The following, non-normative example illustrates the discovery
   procedure envisioned in this document.

   Assume a peer-to-peer tracker is located in the network operated by
   ISP A. Some peer, which is located in ISP B's network, asks the
   tracker for an ALTO-optimized list of other peers that take part in a
   specific swarm.  The tracker can observe the source address X of this
   message, which is the peer's IP address.

   Assume that there is no omniscient ALTO server that knows the whole
   Internet topology.  Therefore, the ALTO client in the tracker does a
   "back-connect" to the ALTO server operated by ISP B, which knows path
   costs from said peer (i.e., IP address X) to anywhere.  The ALTO
   client retrieves this information and the tracker sorts the peer list
   according to it, before returning it to the peer.

   Before this "back-connect" can occur, the server ALTO discovery



Kiesel & Stiemerling     Expires January 5, 2015                [Page 7]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


   mechanism needs to map from the peer's IP address X to the ALTO
   server of ISP B, i.e., the network operator that controls IP address
   X and has assigned it to the peer.
















































Kiesel & Stiemerling     Expires January 5, 2015                [Page 8]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


3.  Requirements for ALTO Cross-Domain Server Discovery

   A solution for the problem described in the previous section would be
   an ALTO Cross-Domain Server Discovery system.  This section itemizes
   requirements.

3.1.  Discovery Client Application Programming Interface

   The discovery client would be called through some kind of application
   programming interface (API) and the parameters would be an IP address
   and, for purposes of extensibility, a service identifier such as
   "ALTO".  It would return an URI that offers the requested service
   ("ALTO") for the given IP address.

   In other words, the client would be used to retrieve a mapping:

   (IP address, "ALTO") -> IRD-URI

   where IRD-URI is the URI of the Information Resource Directory (IRD,
   see Section 9 of [RFC7285]) of an ALTO server that can give
   reasonable guidance to a resource consumer with the indicated IP
   address.

3.2.  Data Storage and Authority Requirements

   The information for mapping IP addresses and service parameters to
   URIs should be stored in a - preferably distributed - database.  It
   must be possible to delegate administration of parts of this
   database.  Usually, the mapping from a specific IP address to an URI
   is defined by the authority that has administrative control over this
   IP address, e.g., the ISP in residential access networks or the IT
   department in enterprise, university, or similar networks.

3.3.  Cross-Domain Operations Requirements

   The cross-domain server discovery mechanism should be designed in
   such a way that it works across the public Internet and also in other
   IP-based networks.  This in turn means that such mechanisms cannot
   rely on protocols that are not widely deployed across the Internet or
   protocols that require special handling within participating
   networks.  An example is multicast, which is not generally available
   across the Internet.

   The ALTO Cross-Domain Server Discovery protocol must support gradual
   deployment without a network-wide flag day.  If the mechanism needs
   some kind of well-known "rendezvous point", re-using an existing
   infrastructure (such as the DNS root servers or the WHOIS database)
   should be preferred over establishing a new one.



Kiesel & Stiemerling     Expires January 5, 2015                [Page 9]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


3.4.  Protocol Requirements

   The protocol must be able to operate across middleboxes, especially
   across NATs and firewalls.

   The protocol will specify an algorithm that determines the service
   parameters to be used when queries and responses are exchanged.  This
   service parameter will specify 'ALTO' for the ALTO cross-domain
   service discovery.  Potentially, it also specifies other required
   parameters needed for the service discovery, such as to be used
   transport or application level protocol.

   The protocol will support the query with the above mentioned service
   parameters and allow that the response contains one or more URI(s).

   The protocol shall not require any pre-knowledge from the client
   other than any information that is known to a regular IP host on the
   Internet.

3.5.  Further Requirements

   The ALTO cross domain server discovery cannot assume that the server
   discovery client and the server discovery responding entity are under
   the same administrative control.



























Kiesel & Stiemerling     Expires January 5, 2015               [Page 10]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


4.  Related IETF Protocols and Activities

   TBD.  Survey.  In particular, the ECRIT WG has specified a reverse-
   DNS-based procedure [RFC7216] to solve a similar problem; TBD:
   analyze whether we can re-use or adapt it.














































Kiesel & Stiemerling     Expires January 5, 2015               [Page 11]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


5.  Security Considerations

   A high-level discussion of security issues related to ALTO is part of
   the ALTO problem statement [RFC5693].  A classification of unwanted
   information disclosure risks, as well as specific security-related
   requirements can be found in the ALTO requirements document
   [RFC6708].

   The remainder of this section focuses on security threats and
   protection mechanisms for the third-party ALTO server discovery
   procedure as such.  Once the 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.

   TBD



































Kiesel & Stiemerling     Expires January 5, 2015               [Page 12]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


6.  IANA Considerations

   This document does not require any IANA action.
















































Kiesel & Stiemerling     Expires January 5, 2015               [Page 13]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2.  Informative References

   [I-D.ietf-alto-deployments]
              Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf,
              "ALTO Deployment Considerations",
              draft-ietf-alto-deployments-09 (work in progress),
              February 2014.

   [I-D.kiesel-alto-3pdisc]
              Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M.,
              Tomsu, M., and H. Song, "ALTO Server Discovery Protocol",
              draft-kiesel-alto-3pdisc-05 (work in progress),
              March 2011.

   [I-D.kiesel-alto-alto4alto]
              Kiesel, S., "Using ALTO for ALTO server selection",
              draft-kiesel-alto-alto4alto-00 (work in progress),
              July 2010.

   [I-D.kiesel-alto-ip-based-srv-disc]
              Kiesel, S. and R. Penno, "Application-Layer Traffic
              Optimization (ALTO) Anycast Address",
              draft-kiesel-alto-ip-based-srv-disc-03 (work in progress),
              July 2014.

   [I-D.kist-alto-3pdisc]
              Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
              ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
              (work in progress), January 2014.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.

   [RFC6708]  Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", RFC 6708, September 2012.

   [RFC7216]  Thomson, M. and R. Bellis, "Location Information Server
              (LIS) Discovery Using IP Addresses and Reverse DNS",
              RFC 7216, April 2014.



Kiesel & Stiemerling     Expires January 5, 2015               [Page 14]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


   [RFC7285]  Alimi, R., Penno, R., and Y. Yang, "Application-Layer
              Traffic Optimization (ALTO) Protocol", RFC 7285,
              June 2014.

   [RFC7286]  Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
              H. Song, "Application-Layer Traffic Optimization (ALTO)
              Server Discovery", RFC 7286, June 2014.












































Kiesel & Stiemerling     Expires January 5, 2015               [Page 15]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


Appendix A.  ALTO and Tracker-based Peer-to-Peer Applications

   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
   possibilities 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 third-party ALTO queries.

   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, which we will refer to as 3PAC (Third-Party
   ALTO Client) in this document.  After receiving a query for a given
   resource (F1) the resource directory invokes the 3PAC 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).






















Kiesel & Stiemerling     Expires January 5, 2015               [Page 16]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


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

   Figure 1: Tracker-based P2P Application with random peer preselection


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

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

       Figure 2: Basic message sequence chart for resource consumer-
                           initiated ALTO query










Kiesel & Stiemerling     Expires January 5, 2015               [Page 17]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


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

    Figure 3: Tracker-based P2P Application with ALTO client in tracker


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

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

     Figure 4: Basic message sequence chart for third-party ALTO query

   Note: the message sequences depicted in Figure 2 and Figure 4 may
   occur both in the target-aware and the target-independent query mode
   (c.f.  [RFC6708]).  In the target-independent query mode no message
   exchange with the ALTO server might be needed after the tracker
   query, because the candidate resource providers could be evaluated
   using a locally cached "map", which has been retrieved from the ALTO
   server some time ago.



Kiesel & Stiemerling     Expires January 5, 2015               [Page 18]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


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

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

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



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


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


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

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



Kiesel & Stiemerling     Expires January 5, 2015               [Page 19]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


   list; however, the benefit is rather limited as the number of
   favorable peers in the list is just too small.

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

   Therefore, from an overall optimization perspective, the second
   scenario with the ALTO client embedded in the resource directory is
   advantageous, because it is ensured that the addresses of the "best"
   resource providers are actually delivered to the resource consumer.
   An architectural implication of this insight is that the ALTO server
   discovery procedures must support third-party discovery.  That is, as
   the tracker issues ALTO queries on behalf of the peer which contacted
   the tracker, the tracker must be able to discover an ALTO server that
   can give guidance suitable for that respective peer.






























Kiesel & Stiemerling     Expires January 5, 2015               [Page 20]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


Appendix B.  Contributors List and Acknowledgments

   The initial version of this document was co-authored by Marco Tomsu
   (Alcatel-Lucent).

   This document borrows some text from [RFC7286], as it was
   historically part of that memo.  Special thanks to Michael Scharf and
   Nico Schwan.











































Kiesel & Stiemerling     Expires January 5, 2015               [Page 21]


Internet-Draft     ALTO Cross-Domain Server Discovery          July 2014


Authors' Addresses

   Sebastian Kiesel
   University of Stuttgart Information Center
   Allmandring 30
   Stuttgart  70550
   Germany

   Email: ietf-alto@skiesel.de
   URI:   http://www.rus.uni-stuttgart.de/nks/


   Martin Stiemerling
   University of Applied Sciences Darmstadt,  Computer Science Dept.
   Haardtring 100
   Darmstadt  64295
   Germany

   Phone: +49 6151 16 7938
   Email: mls.ietf@gmail.com
   URI:   http://ietf.stiemerling.org






























Kiesel & Stiemerling     Expires January 5, 2015               [Page 22]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/