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

Versions: 00

ALTO Working Group                                         YR. Yang, Ed.
Internet-Draft                                           Yale University
Intended status: Informational                                  D. Pasko
Expires: September 5, 2009                                       Verizon
                                                               L. Popkin
                                                          Pando Networks
                                                                R. Penno
                                                                 Juniper
                                                             S. Shalunov
                                                              BitTorrent
                                                           March 4, 2009


              An Architecture of ALTO for P2P Applications
                  draft-yang-alto-architecture-00.txt

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 5, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights



Yang, et al.            Expires September 5, 2009               [Page 1]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


   and restrictions with respect to this document.

Abstract

   ALTO enables Internet Service Providers (ISPs) and network
   application software distributors to work jointly and cooperatively
   to reduce network resource consumption and to improve application
   performance.  In this document, we specify an architecture for
   integrating ALTO into peer-to-peer (P2P) applications.

Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.3.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
     2.4.  Comparisons with Alternatives  . . . . . . . . . . . . . .  4
   3.  Architectural Model  . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Basic Concepts . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.1.  My-Internet View . . . . . . . . . . . . . . . . . . .  4
       3.1.2.  ALTO Cost Type . . . . . . . . . . . . . . . . . . . .  4
       3.1.3.  Hosting ALTO Server  . . . . . . . . . . . . . . . . .  5
       3.1.4.  Location Grouping  . . . . . . . . . . . . . . . . . .  5
     3.2.  Basic Functional Components  . . . . . . . . . . . . . . .  7
       3.2.1.  ALTO Query/Response Protocol . . . . . . . . . . . . .  8
       3.2.2.  ALTO Service Discovery . . . . . . . . . . . . . . . .  8
     3.3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.3.1.  Redistribution and Caching of ALTO Info  . . . . . . .  9
       3.3.2.  ALTO Effectiveness Monitoring  . . . . . . . . . . . .  9
   4.  Example Functional Components Instantiations . . . . . . . . .  9
     4.1.  Tracker-based Peer Selection using ALTO  . . . . . . . . . 10
     4.2.  Client Peer Selection using ALTO . . . . . . . . . . . . . 10
   5.  P2P Application ALTO Integration Guidelines  . . . . . . . . . 10
     5.1.  Peer Selection Guidelines  . . . . . . . . . . . . . . . . 10
     5.2.  Interoperability with Non-ALTO Clients . . . . . . . . . . 11
   6.  ALTO Service Discovery Guidelines  . . . . . . . . . . . . . . 11
     6.1.  Delegation . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  NAT  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.3.  Load Balancing and Robustness  . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 12
   Appendix B.  Acknowledgments . . . . . . . . . . . . . . . . . . . 12





Yang, et al.            Expires September 5, 2009               [Page 2]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


1.  Requirements Notation

   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 [RFC2119].

2.  Introduction

2.1.  Overview

   ALTO is a service to allow Internet service providers (ISPs) and
   network applications to work more cooperatively.  Since in general
   peer-to-peer applications generate large amounts of Internet traffic
   and many of these produce traffic patterns that are network-
   oblivious, it is important to provide such applications with more
   information so that they can effectively utilize their communication
   flexibility to perform better-than-random peer selection, which can
   reduce network resource consumption and improve application
   performance.

   Recently, multiple schemes have been proposed, including ALTO Info
   Export [Info-Export], P4P [P4P-framework], and PROXIDOR [PROXIDOR].
   These schemes represent different points at the solution spectrum.

   This document presents a unifying architecture of how ALTO can be
   integrated into large P2P applications such as those based on
   BitTorrent (e.g., BitTorrent and PPLive).  This class of applications
   share many common features to allow a unified study of architecture.

   The objective of this document is to complement the Problem Statement
   [ALTO-Problem] and the Requirements [ALTO-Reqs] documents to identify
   the essential functional components in the architecture.  Note that
   the architecture presented in this document serves an informative
   purpose only.  It provides a conceptual framework for more structured
   design and discussions.

2.2.  Terminology

   We use the following terms defined in [ALTO-Problem]:

   Application, Overlay Network, Peer, Resource, Resource Identifier,
   Resource Provider, Resource Consumer, Resource Directory, Transport
   Address, Host Location Attribute, ALTO Service, ALTO Server, ALTO
   Client, ALTO Query, ALTO Reply, ALTO Transaction, Local Traffic,
   Peering Traffic, Transit Traffic.






Yang, et al.            Expires September 5, 2009               [Page 3]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


2.3.  Requirements

   The architecture to be presented is guided by the following key
   design requirements:

   o  The architecture is extensible so that ALTO information can be
      used by both P2P Peers and P2P Application trackers (e.g., a
      BitTorrent tracker uses ALTO for initial peer selection).
      Tracker-based peer selection can be beneficial given the global
      knowledge of a tracker about a P2P Application.  However, since a
      P2P tracker may manage a large number of Peers, ALTO should avoid
      substantial workload and redundancy on the tracker.

   o  Each ISP or its delegate can configure the ALTO Server that
      provides the information about the ISP's network.  Each ISP can
      determine the level of detail that it wishes to expose.  It
      applies any desired aggregation and transformation mechanisms.
      Information from ALTO Servers can be "anonymized" or access-
      controlled to protect the ISP's topology and business policies.
      Although multiple ISPs can interact and negotiate with respect to
      the information provided by their ALTO Servers, it is outside the
      scope of this architecture.

2.4.  Comparisons with Alternatives

   To be added.

3.  Architectural Model

3.1.  Basic Concepts

3.1.1.  My-Internet View

   The basic architecture we present is based on a simple model that
   each ALTO Server defines a "my-Internet" view, which consists of a
   set of network locations identifiable by Host Location Attributes,
   and generic costs among network locations.  An ALTO Service provides
   its service based on its my-Internet view.

3.1.2.  ALTO Cost Type

   An ALTO server may allow multiple types of generic costs to be
   defined between each pair of network locations.  Example types
   include hop-count, air-mile, and routing-cost.  We refer to each type
   as an ALTO Cost Type.






Yang, et al.            Expires September 5, 2009               [Page 4]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


3.1.3.  Hosting ALTO Server

   Given a Resource Consumer p and a given type of ALTO Cost, an ALTO
   Client identifies a Hosting ALTO Server using ALTO Service Discovery.
   Network efficiency for p's behavior is considered from the my-
   Internet view of the Hosting ALTO Server of p.

3.1.4.  Location Grouping

   In this architecture, we introduce Location Grouping in ALTO Queries
   and Responses for scalability and privacy.

   Specifically, an ALTO Query specifies a set of locations on the my-
   Internet view representing Resource Consumers, and a set of locations
   on the my-Internet view representing potential Resource Providers.
   The ALTO Response reveals network information related with these
   network locations.

   We distinguish two types of location grouping: Source (Resource
   Consumer) Grouping and Destination (Resource Provider) Grouping.

3.1.4.1.  Source Grouping

   Without Source Grouping, each ALTO Query is from the vantage point of
   a specific Resource Consumer on the my-Internet view.  Consequently,
   the number of ALTO Queries to be handled (both by ALTO Servers and
   ALTO Clients) will grow with the number of Peers, which can be large.
   This can be particularly challenging for tracker-based systems, where
   a tracker manages a large number of peers and it is the tracker who
   uses ALTO to make initial peer selections.

   One can identify settings where fine-grained queries for individual
   IP addresses are necessary, and thus should be supported.

   On the other hand, for many ISPs and in particular in the setting of
   P2P, network information for each individual IP address may not be
   necessary or too fine-grained.  Instead, a set of network locations
   may have similar costs to other network locations.  Thus, an ISP,
   through its ALTO Server, may specify equivalent classes of network
   locations containing Resource Consumers.  Each such class is called a
   Source Grouping.

   By defining Source Grouping, we improve both scalability and privacy:

   o  Scalability: The number of ALTO Queries grow with the number of
      Source Groupings.  The state at a tracker who uses ALTO to make
      initial peer selection grows with the number of Source Groupings
      instead of the number of Peers.  It also makes it possible for



Yang, et al.            Expires September 5, 2009               [Page 5]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


      Peers to share ALTO information (e.g., redistribution using P2P),
      in both tracker-based and tracker-less P2P Applications.

   o  Privacy: By issuing ALTO queries for Source Groupings, it avoids
      revealing individual Peer information.

3.1.4.2.  Destination Grouping

   The network information to a set of network locations as Resource
   Providers may be similar.  For example, although there are tens of
   thousands of Autonomous Systems (ASes), the routing costs of an ISP
   to these ASes may be quite coarse-grained (e.g., according to the
   business relationship of the first hop BGP peer).  Thus, an ISP,
   through its ALTO Server, may specify equivalent classes of
   destination network locations.  Each such class is a Destination
   Grouping.  Destination Grouping can reduce redundancy, improve
   scalability, and can help to protect Peer privacy.

3.1.4.3.  Grouping Levels

   The level of grouping can span a whole spectrum: individual IP
   address, a subnet, a set of subnets, a point of presence (PoP), an
   Internet exchange point, an autonomous system (AS), a set of
   autonomous systems (e.g., those with the same next-hop AS, those
   reachable through provider ASes, or those with the same BGP AS_PATH
   length), or some other set defined by a common set of properties.

   Although some of the preceding groupings can be naturally expressed
   using the current Internet addressing scheme (IP prefix, ASN), others
   (e.g., PoP, those reachable through provider ASes) are not.

   In this architecture, we adopt a generic approach.  Each grouping is
   identified by a Network Grouping Identifier to allow flexibility,
   reuse and reducing redundancy.  A Grouping Identifier can be
   considered as a Host Location Attribute.

3.1.4.4.  Grouping Examples

   Table 1 illustrates how the three approaches aforementioned in the
   Introduction use Location Grouping.  The column "Source Grouping"
   denotes the levels of Source Groupings supported (i.e, how an ALTO
   Client specifies a Resource Consumer), the column "Destination Query"
   denotes how an ALTO Client specifies the Resource Providers
   (candidate Peers), and the column "Destination Grouping" denotes the
   levels of Destination Groupings supported.






Yang, et al.            Expires September 5, 2009               [Page 6]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


   +----------+----------------------+-----------------+---------------+
   | Approach | Source Grouping      | Destination     | Destination   |
   |          |                      | Query           | Grouping      |
   +----------+----------------------+-----------------+---------------+
   |   Info   | Per IP address Query | Does not        | CIDR; ASN     |
   |  Export  |                      | specify; assume |               |
   |          |                      | whole address   |               |
   |          |                      | space           |               |
   +----------+----------------------+-----------------+---------------+
   | PROXIDOR | Per [Src IP, list of | List of IP      | IP address;   |
   |          | Dst IP] Query; May   | addresses;      | Mentioned     |
   |          | extend to use        | Mentioned       | possibility   |
   |          | CIDR/ASN to replace  | possibility of  | of using      |
   |          | IP                   | using CIDR/ASN  | CIDR/ASN in   |
   |          |                      | in place of IP  | place of IP   |
   +----------+----------------------+-----------------+---------------+
   |    P4P   | One query for each   | List of         | Same as       |
   |          | Source Grouping;     | CIDR/ASN/PIDs   | Source        |
   |          | Source Grouping can  |                 | Grouping      |
   |          | be CIDR, ASN, or PID |                 |               |
   |          | which is a set of    |                 |               |
   |          | CIDR/ASN.            |                 |               |
   +----------+----------------------+-----------------+---------------+

   Table 1: Grouping Levels Used in ALTO Info Export, P4P, and PROXIDOR.

3.2.  Basic Functional Components

   Given the preceding key concepts, we now introduce the basic
   functional components.  Figure 1 shows the main functional components
   in the basic architecture:

     .----------.                      .-----------.
     | ALTO     | ALTO Query/Response  | ALTO      |
     | Server   | -------------------- | Client    |
     `----------'                      `-----------'
                                      /
              ALTO SD Query/Response /
                                    /
                         ..............
                        : ALTO Service :
                        : Discovery    :
                        `..............'

                    Figure 1: Basic ALTO Architecture.






Yang, et al.            Expires September 5, 2009               [Page 7]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


   o  ALTO Query/Response: We refer to an ALTO Query and its
      corresponding ALTO Response as an ALTO Transaction.  The
      information conveyed in ALTO Transactions is referred to as ALTO
      Information.

   o  ALTO Service Discovery: Although it is possible to use manual
      configuration to avoid this component, for large-scale deployment,
      service discovery is necessary.

3.2.1.  ALTO Query/Response Protocol

   Specifically, different types of ALTO Queries can be constructed
   depending on the information needed by the client.  In its most
   generic form, an ALTO query specifies (1) a set of Host Location
   Attributes (Network Grouping Identifiers) representing Resource
   Consumers, (2) a set of Host Location Attributes (Network Grouping
   Identifiers) representing potential Resource Providers, and (3) a
   desirable ALTO Cost Type.

   An ALTO Response includes the values of the costs from the Resource
   Consumers to the Resource Providers.

   The returned information may also be in a transformed format.  For
   example, instead of the exact values, they may be rankings derived
   from the cost values.  The response will be used for making peer
   selection.

3.2.2.  ALTO Service Discovery

3.3.  Extensions

   The Basic Architecture provides interoperability, but lacks
   components for (1) improving scalability, (2) using multiple
   information sources, and (3) handling issues that can arise when
   networks and P2P applications operate autonomously.  Although the
   ALTO Working Group may not pursue these components initially, it is
   important to identify the related issues when defining the core
   components defined in the Basic Architecture.

   Figure 2 shows additional functional components.  In particular,
   ultimately, P2P applications make peer selection decisions based on
   multiple sources of information, including not only ALTO information,
   but also application state (e.g., distribution of super nodes, seeds,
   and down loaders), and other sources of information such as probed
   network information or shared underlay information.






Yang, et al.            Expires September 5, 2009               [Page 8]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


                               ..................      ..............
                              : ALTO Effective.  :    : Other        :
                              : Monitoring       :----: Information  :
                              :                  :    : Sources      :
                              `..................'    `..............'
                                         |         \         |
                               ALTO Info |          \        |
                                         |           \       |
     .----------. ALTO           .-----------. ALTO  ................
     | ALTO     | Query/Response | ALTO      | Info : Peer Selection :
     | Server   | ---------------| Client    | ---> : Logic          :
     `----------'                `-----------'      `................'
                                      /     \
              ALTO SD Query/Response /       \
                                    /         \
                         ..............       ..................
                        : ALTO Service :     : ALTO Information :
                        : Discovery    :     : Redistribution   :
                        `..............'     `..................'

                  Figure 2: ALTO Architecture Extension.

3.3.1.  Redistribution and Caching of ALTO Info

   Redistribution and Caching of ALTO Information: Large-scale
   deployment of P2P applications may generate a large number of ALTO
   Transactions.  Thus, mechanisms for the caching (e.g., leveraging
   HTTP caches [P4P-spec]) and redistribution (e.g., using P2P) of ALTO
   Information are necessary to avoid ALTO becoming a system bottleneck
   and to reduce ISP deployment costs.

   In particular, if redistribution is allowed, then the ALTO Request/
   Response protocol may include mechanism to allow ease of
   redistribution and validation of redistributed ALTO Information.

3.3.2.  ALTO Effectiveness Monitoring

   ALTO Effectiveness Monitoring: Applications evaluate effectiveness of
   ALTO information, and the effectiveness is used in Peer Selection.
   It is possible that networks may also want to monitor the effects of
   its provided ALTO information.

4.  Example Functional Components Instantiations

   The preceding section gives basic functional components.  In this
   section, we give instantiations of the architecture for multiple
   application scenarios.




Yang, et al.            Expires September 5, 2009               [Page 9]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


4.1.  Tracker-based Peer Selection using ALTO

   In this setting, the application tracker (Resource Directory) keeps
   track of Peers in a torrent.  There is an ALTO Client embedded in the
   application tracker.  The ALTO Client queries the ALTO Servers of the
   Peers in the torrent to obtain their my-Internet views.  Then the
   application tracker conducts peer selection.

   There can be an alternative instantiation, in which a third party
   provides an ALTO Client (e.g., application optimization engine
   [P4P-SIGCOMM08], [P4P-framework]).  The application tracker sends
   application state to the third party, who issues ALTO Queries and
   computes peer selection guidance for the application tracker.

4.2.  Client Peer Selection using ALTO

   In this setting, a Peer uses ALTO when conducting peer selection
   (i.e., selecting among the known peers those that it preferentially
   connects to).  There are several settings that this may happen:

   o  There does not exist a tracker.  The Peers discover each other
      using mechanisms such as DHT.

   o  There is a tracker but the tracker does not support ALTO (yet).

   o  Even though there is a tracker and the tracker applies ALTO when
      conducting initial peer selection, the Peer applies ALTO when
      selecting peers as it learns additional peers such as those from
      Peer Exchange.

   There are at least two types of instantiations of ALTO Clients in
   this setting: In the first case, an ALTO Client is embedded in the
   BitTorrent Client; in the second case, the ALTO Client is implemented
   as part of the operating system.

   In either case, the ALTO Client discovers the ALTO Server of the
   Internet Service Provider of the Peer.  Then the ALTO Client obtains
   the my-Internet view of the ISP to help with peer selection.

5.  P2P Application ALTO Integration Guidelines

5.1.  Peer Selection Guidelines

   Multiple examples of using ALTO Information have been proposed (e.g.,
   the usage examples in [Info-Export], the Application Optimization
   Engine in [P4P-framework], and the example usages in [PROXIDOR].
   Although it is unlikely that we can enforce Applications behaviors,
   development of guidelines for Application peer selection can be



Yang, et al.            Expires September 5, 2009              [Page 10]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


   beneficial, in an organization such as the P4P Working Group.

5.2.  Interoperability with Non-ALTO Clients

   To be added.

6.  ALTO Service Discovery Guidelines

   Key issues in ALTO Service Discovery are the following:

6.1.  Delegation

6.2.  NAT

6.3.  Load Balancing and Robustness

7.  Security Considerations

   There are security considerations from the perspectives of both ISPs
   and P2P applications.  See [ALTO-Problem] and [ALTO-Reqs] for
   discussions.

8.  References

8.1.  Normative References

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

8.2.  Informative References

   [ALTO-Problem]   Seedorf, J. and E. Burger, "Application-Layer
                    Traffic Optimization (ALTO) Problem Statement",
                    draft-marocco-alto-problem-statement-04 (work in
                    progress) 2009.

   [ALTO-Reqs]      S. Kiesel, L. Popkin, S. Previdi,  R. Woundy, and
                    YR. Yang, "Application-Layer Traffic Optimization
                    (ALTO) Requirements", draft-kiesel-alto-reqs-01
                    (work in progress) 2008.

   [Info-Export]    S. Shalunov, R. Penno, and R. Woundy, "ALTO
                    Information Export Service",
                    draft-shalunov-alto-infoexport-00 (work in progress)
                    2008.

   [P4P-SIGCOMM08]  H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A.
                    Silberschatz., "P4P: Provider Portal for (P2P)



Yang, et al.            Expires September 5, 2009              [Page 11]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


                    Applications", In SIGCOMM 2008.

   [P4P-framework]  R. Alimi, D. Pasko, L. Popkin, Y. Wang, and YR.
                    Yang., "P4P: Provider Portal for (P2P)
                    Applications", draft-p4p-framework-00 (work in
                    Progress) 2008.

   [P4P-spec]       Y. Wang, R. Alimi, D. Pasko, L. Popkin, and YR.
                    Yang., "P4P Protocol Spec", draft-wang-p4p-spec-00
                    (work in Progress) 2009.

   [PROXIDOR]       O. Akonjang, A. Feldmann, S. Previdi, B. Davie, and
                    D. Saucez, "The PROXIDOR Service",
                    draft-akonjang-alto-proxidor-00.txt (work in
                    progress) 2009.

Appendix A.  Contributors

   Additional contributors:

   o  Richard Alimi, Yale

   o  Satish Raghunath, Juniper

   o  Richard Woundy, Comcast

   o  Yu-Shun Wang, Microsoft

Appendix B.  Acknowledgments

   The authors would like to thank the members of the p4p/alto/p2pi
   mailing lists for their insights.  The concept of my-Internet view is
   from Emilio Sepulveda of Telefonica.  The authors benefited from
   multiple discussions with Stefano Previdi and Anja Feldmann.

Authors' Addresses

   Y. Richard Yang (editor)
   Yale University

   EMail: yry@cs.yale.edu


   D. Pasko
   Verizon

   EMail: pasko@verizon.com




Yang, et al.            Expires September 5, 2009              [Page 12]


Internet-Draft   ALTO Architecture for P2P Applications       March 2009


   L. Popkin
   Pando Networks

   EMail: laird@pando.com


   Reinaldo Penno
   Juniper

   EMail: rpenno@juniper.net


   Stanislav Shalunov
   BitTorrent

   EMail: shalunov@bittorrent.com



































Yang, et al.            Expires September 5, 2009              [Page 13]


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