[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
ALTO                                                               Y. Gu
Internet-Draft                                                    Huawei
Intended status: Standards Track                          Richard. Alimi
Expires: April 22, 2010                                       Yale Univ.
                                                              Roni. Even
                                                                  Huawei
                                                        October 19, 2009


                    ALTO information redistribution
                    draft-gu-alto-redistribution-00

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 April 22, 2010.

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
   and restrictions with respect to this document.






Gu, et al.               Expires April 22, 2010                 [Page 1]


Internet-Draft       ALTO information redistribution        October 2009


Abstract

   The ALTO protocol proposes several mechanisms to increase
   scalability.  One of the proposed mechanisms is ALTO information
   redistribution.  This document proposes a redistribution framework
   and provides suggestions concerning the corresponding data format.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminologies and concepts . . . . . . . . . . . . . . . . . .  3
   3.  Redistribution Framework . . . . . . . . . . . . . . . . . . .  4
     3.1.  Information Types  . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Redistribution Scheme  . . . . . . . . . . . . . . . . . .  5
   4.  Data Format  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Input Parameters . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Signature and Authentication . . . . . . . . . . . . . . .  6
   5.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Tracker-based redistribution . . . . . . . . . . . . . . .  8
     5.2.  Trackerless redistribution . . . . . . . . . . . . . . . .  9
   6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Updating . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12






















Gu, et al.               Expires April 22, 2010                 [Page 2]


Internet-Draft       ALTO information redistribution        October 2009


1.  Introduction

   When providing an ALTO service, Network Providers offer information
   to clients with the goal of helping P2P applications to perform peer
   selection and improving network efficiency.  The ALTO Service becomes
   a distribution point of network information for a ALTO Clients within
   its network.  A Network Provider may deploy an ALTO Service using
   techniques such as load balancing and caching to handle a large
   number of subscribers.  In this document, we discuss an additional
   mechanism to distribute ALTO information to ALTO Clients: ALTO
   Information Redistribution.

   Consider a scenario where a large number (e.g., millions) of users
   start their P2P live streaming clients just before the start of a
   popular event.  Each client requests ALTO information directly from
   the ALTO Service within their ISP it is not already downloaded.  For
   certain content (e.g., content with national interest), even the
   number of streaming clients within a single ISP may be extremely
   large.  For example, tens of millions of people watched the United
   States Presidential Inauguration in Jan. 2009 via the Internet
   through such sites as CNN.  During the 2009 Spring Festival Evening
   in China, about 24 millions of audiences watched the program on
   Internet.  In such a case, an ISP's ALTO Service may not be able to
   handle the load and provide ALTO information directly to each client.

   Many mechanisms to increase scalability are possible.  For example,
   the ALTO Service could use load balancing techniques; [I-D.penno-
   alto-protocol] proposes several mechanisms to increase capability.
   One of the proposed mechanisms is ALTO information redistribution,
   which can use infrastructure other than the ALTO Service itself to
   distribute ALTO information (e.g., P2P infrastructure) to a large
   number of ALTO Clients.

   This document aims to enumerate various issues that should be
   considered when designing ALTO information redistribution mechanism.
   Note that certain design decisions of the final ALTO Protocol and
   framework will affect ALTO information redistribution mechanism.
   This document will be updated to track the progress of the ALTO
   requirements and solution.


2.  Terminologies and concepts

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

   The document uses terms defined in [I-D.ietf-alto-problem-statement]



Gu, et al.               Expires April 22, 2010                 [Page 3]


Internet-Draft       ALTO information redistribution        October 2009


   and [draft-penno-alto-protocol].

   To make the presentation more concise, we use some abbreviations in
   this document.

      ALTO_Server_hostname: AS_n

      ALTO_Server_port: AS_p


3.  Redistribution Framework

   Before discussing specific redistribution techniques, we provide a
   set of guidelines for redistributing ALTO Information.  While other
   methods for redistributing information may be possible in some
   settings (e.g., broadcast), we focus on a pull-based mechanism where
   ALTO Clients explicitly request a particular set of ALTO information.

      1) Basic Requirements.  We first define a set of requirements of
      the redistribution scheme.  For a particular query, an ALTO Client
      knows the ALTO Server (hostname and port), and input parameters.
      The ALTO Client may fetch the query result from either the ALTO
      Service directly, or it may fetch the query result through another
      means (e.g., redistribution).  We assume in this document that the
      client uses redistribution.The ALTO Client should be able to
      locate the desired redistributed data based only on AS_n, AS_p,
      and the input parameters.

      2) The ALTO Client should be able to check the validity of the
      information once it is retrieved.  That is, the ALTO Client should
      be able to determine if the retrieved information was indeed
      generated by the desired ALTO Service.

3.1.  Information Types

   In general, it should be possible to redistribute the query response
   that does not depend on anything except the input parameters, AS_n,
   and AS_p.  However, redistribution may only be worthwhile for queries
   that are made by a large number of ALTO Clients.  In the context of
   [I-D.penno-alto-protocol], we provide an example list of information
   types that may be commonly used across many ALTO Clients, and hence
   benefit from redistribution:

      1) Server Capability which indicates the capabilities implemented
      by an ALTO Server.

      2) Full Network Map which lists the PIDs and IP prefixes that are
      contained within each PID.



Gu, et al.               Expires April 22, 2010                 [Page 4]


Internet-Draft       ALTO information redistribution        October 2009


      3) Full Path Cost Map among all PIDs, which indicates the Path
      Cost between each pair of PIDs.

      4) Path Cost Map from the perspective of a single PID, which
      indicates the Path Costs from a single PID to itself and all other
      PIDs.

   [I-D.penno-alto-protocol] also specifies certain queries that may not
   benefit from redistribution.  For example, if a peer requests ordinal
   Path Costs (i.e., a ranked list) for a set of individual endpoint
   addresses (i.e., Resource Providers), the response may not be useful
   to other ALTO Clients.  This is because other ALTO Clients may be
   running different applications or have a different set of available
   peers (e.g., participating in a different swarm, or be in contact
   with a different set of peers).

3.2.  Redistribution Scheme

   1) We have previously identified basic requirements for pull-based
   distribution schemes.  Implementing a redistribution scheme for a set
   of ALTO Clients includes other considerations.  For example:Which
   ALTO Client(s) query the original ALTO Service?What protocol is used
   for locating redistributed ALTO information?

   2) What naming scheme is used to specify AS_n, AS_p, and the input
   parameters in the protocol for locating redistributed ALTO
   information?  For example, the naming scheme could define how to
   compute the 'key' in a DHT.

   3) What protocol is used for retrieving redistributed ALTO
   information?

   4) How is the redistributed information encoded?  Note that the
   original response from the ALTO Service may be reformated (e.g.,
   compressed) for redistribution.  Note that if this approach is taken
   and ALTO Clients still wish to verify received information against
   the ALTO Server, ALTO Clients should be able to reconstruct the ALTO
   Service's original response (e.g., via decompression).  If a lossy
   transformation is made (e.g., filtering), ALTO Clients may not be
   able to verify the received information.


4.  Data Format

4.1.  Input Parameters

   In this section, we propose a simple naming scheme to identify
   redistributed ALTO information that is applicable to many P2P



Gu, et al.               Expires April 22, 2010                 [Page 5]


Internet-Draft       ALTO information redistribution        October 2009


   applications.  The scheme allows redistribution of ALTO information
   requested using HTTP GET requests in [I-D.penno-alto-protocol].
   Since REST-style URLs are used, input parameters are included
   directly in the URL (along with AS_n and AS_p).  Thus, we compute a
   hash of the form:

      hash("alto:REQUEST_URL")

   where REQUEST_URL is the full HTTP URL that would have been used to
   request ALTO information from the ALTO Server itself.  The resulting
   string can be used to locate the desired ALTO information (e.g., in a
   DHT).

   The following simple examples show how naming can be accomplished
   using the Information Types in Section 3.2:

      1) Server Capability

         The publish key, e.g. via DHT overlay, is

         hash("alto:http://alto.example.net:80/capability").

      2) Full Network Map.

         The publish key, e.g. via DHT overlay, is

         hash("alto:http://alto.example.net:80/prop/pid").

      3) Full Path Cost among all PIDs

         The publish key, e.g. via DHT overlay, is

         hash("alto:http://alto.example.net:80/cost/map).

      4) Path Cost Map from the perspective of a single PID (e.g.  PID1)

         The publish key, e.g. via DHT overlay, is

         hash("alto:http://alto.example.net:80/cost/row?srcpid=PID1").

   Note that we assume the peer has already performed ALTO Service
   Discovery to determine AS_n and AS_p.  See
   [draft-song-alto-server-discovery-01].

4.2.  Signature and Authentication

   In this section, we would like to give a brief presentation of our
   consideration on security issues.



Gu, et al.               Expires April 22, 2010                 [Page 6]


Internet-Draft       ALTO information redistribution        October 2009


   For some redistribution schemes (e.g., posting a ".torrent" file on a
   website), any ALTO Client could provide the redistributed ALTO
   information.  A malicious ALTO Client could modify the information
   before it is redistributed.  Thus, the ALTO server should sign the
   information to help ALTO Clients verify the the information before it
   is utilized.

   The signature for a particular piece of ALTO information (query
   response) is generated by ALTO server who provides the information.
   The signature is composed of at least two parts: (1) the input
   parameters for generating the information (e.g., the REQUEST URL),
   and (2) hash of the ALTO information.  The signature is signed by
   ALTO server's Private Key.
     +-------------------------------------------+
   ( | Input parameters | Hash(ALTO information) | ) AS_PrivateKey
     +-------------------------------------------+
   Figure 1: Message format with signature

   To check the signature, an ALTO client requires ALTO server's Public
   Key. There are several methods to get the Public Key:

      1) Get the public key from the ALTO server.  The public key can be
      stored locally (until it is changed) by the ALTO Client and used
      regardless of how often ALTO information is updated.  Thus, while
      this is a query to the ALTO Server, it is only done once (e.g.,
      the first time the ALTO Server is queried).

      2) Get the public key from the discovery system where ALTO clients
      get their AS_n and AS_p.  DNS or DHCP is extensible to carry some
      additional information.

      3) From a Global Trusted Certificate Authority (GTCA).  This GTCA
      can be a hierarchical system.  The pair of <Public Key, Private
      Key> and the certificate of the ALTO server are generated by the
      GTCA.  Though this possibility may not be widely deployable on the
      public Internet (currently), we present it for completeness.


5.  Use Cases

   The architecture of P2P application will affect the redistribution
   mechanisms of ALTO information.  Generally speaking, there are two
   kinds of P2P applications, Tracker-based and Trackerless.  In
   Tracker-based applications, a resource directory is maintained on a
   tracker, and peers contact the tracker to learn about new peers.  In
   a Trackerless overlay, peers are organized through a particular
   algorithm, e.g.  DHT, and they publish or find resources by routing
   through the overlay.



Gu, et al.               Expires April 22, 2010                 [Page 7]


Internet-Draft       ALTO information redistribution        October 2009


5.1.  Tracker-based redistribution

   1) Tracker finds the ALTO server on behalf of a peer, queries the
   necessary ALTO information and reply peer with the ALTO information
   as well as the candidate list. [draft-kiesel-alto-3pdisc-00]
   describes several methods by which Tracker can find the right ALTO
   server.  Note that the Tracker might omit the 'more preferred' peers
   when making the original selection.  However, the ALTO Information
   can be applied to peers learned from other sources (e.g., Peer
   Exchange and/or DHT).

   2) A peer asks for a Resource and Tracker replies without any ALTO
   information.  The peer queries the ALTO server for ALTO information,
   and selects peers.  In order to help lessen the burden on ALTO
   server, as well as help other peers who want the same ALTO
   information, the peer publishes the ALTO information on the Tracker
   (if the Tracker allows this behavior).  Peers may then distribute the
   ALTO information just as any other Resource.  The method introduced
   here can be regard as a complementary process to (1).
































Gu, et al.               Expires April 22, 2010                 [Page 8]


Internet-Draft       ALTO information redistribution        October 2009


                +-------------+
                |             |
                |    ALTO     |
                |   Server    |
                |             |
                +-------------+
                       |
                       | (1) Query
                       |     and
                       |     Response
        ^^^^^^^^^^^^^^^|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        ^      +-----------------+    +----------------+           ^
        ^      |                 |    |                |           ^
        ^      |    Peer A       |    |  Peer B        |           ^
        ^      | (ALTO Client)   |    | (ALTO Client)  |           ^
        ^      +-----------------+    +----------------+           ^
        ^              * (3)                    * o                ^
        ^              * Redistribution         * o  (2)           ^
        ^              ************************** o   peer         ^
        ^                                         o  request       ^
        ^                                         o                ^
        ^                                         o                ^
        ^                                 +---------------+        ^
        ^                                 |               |        ^
        ^                                 |   Tracker     |        ^
        ^                                 |               |        ^
        ^                                 +---------------+        ^
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            ---   ALTO query and response protocol
            ooo   peer request protocol in p2p overlay (out of scope)
            ***   ALTO information redistribution in overlay
  Figure 2: Information redistribution among peers in Tracker-based P2P Application

5.2.  Trackerless redistribution

   In a Trackerless overlay, peers obtain the ALTO information, then
   publish it via a P2P protocol (e.g., in a DHT).  Peers can also
   locate and retrieve ALTO information through the protocol.













Gu, et al.               Expires April 22, 2010                 [Page 9]


Internet-Draft       ALTO information redistribution        October 2009


                +------------+
                |            |
                |    ALTO    |
                |   Server   |
                |            |
                +------------+
                       |
                       | (1) Query
                       |     and
                       |     Response
        ^^^^^^^^^^^^^^^|^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        ^      +------------------+    +-------------------+      ^
        ^      |                  |    |                   |      ^
        ^      |    Peer A        |    |     Peer B        |      ^
        ^      | (ALTO Client)    |    | (ALTO Client)     |      ^
        ^      +------------------+   +--------------------+      ^
        ^              * (2)                     *                ^
        ^              * Overlay redistribution  *                ^
        ^              ***************************                ^
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
               ---   ALTO query and response protocol
               ***   ALTO information searching and redistribution
                     by using P2P Protocol
   Figure 3: Information redistribution among peers in Trackerless P2P Overlay


6.  Discussion

6.1.  Updating

   A Network Provider may update the ALTO information provided by the
   ALTO Server.  It should be possible for ALTO Clients using
   redistribution to obtain updated information within a reasonable
   time.  [I-D.penno-alto-protocol] indicates that HTTP Caching
   directives should should be used by an ALTO Server to indicate the
   lifetime for retrieved ALTO information.  ALTO Clients contacting the
   ALTO Server directly (and providing it for redistribution) should
   refresh redistributed information when updated information is
   retrieved.  If the HTTP Caching directives indicate that the
   information should not be cached, then the information should not be
   provided for redistribution.


7.  Security Considerations

   Security aspects should be well discussed in a dedicated draft to
   analyze the potential harmful actions and corresponding solutions
   both to ALTO server and to the ALTO system.



Gu, et al.               Expires April 22, 2010                [Page 10]


Internet-Draft       ALTO information redistribution        October 2009


8.  Acknowledgments

   The authors would like to give special thanks to Jan Seedorf and
   David Bryan, (to be added).


9.  References

9.1.  Normative Reference

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

   [RFC5246]  Dierks, T, et al., "The Transport Layer Security (TLS)
              Protocol Version 1.2", Aug. 2008.

   [I-D.ietf-alto-problem-statement]
              Seedorf, J, et al., "Application-Layer Traffic
              Optimization (ALTO) Problem Statement",
              draft-ietf-alto-problem-statement-02 (work in progress)",
              July 2009.

9.2.  Informative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", June 1999.

   [RFC3552]  Rescorla, E, et al., "Guidelines for Writing RFC Text on
              Security considerations", July 2003.

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T, et al., "Guidelines for Writing an IANA
              Considerations Section in
              RFCs",draft-narten-iana-considerations-rfc2434bis-09 (work
              in progress)", March 2008.

   [draft-penno-alto-protocol-03]
              Penno, R, et al., "ALTO Protocol", July 2009.

   [draft-kiesel-alto-3pdisc-00]
              Kiesel, S, et al., "Third-party ALTO server discovery",
              Aug. 2009.

   [draft-song-alto-server-discovery-01]
              Song, H, et al., "ALTO Service Discovery", July 2009.

   [draft-stiemerling-alto-info-redist-00]
              Stiemerling, M, et al., "ALTO Information Redistribution
              Considered Harmful", Aug. 2009.



Gu, et al.               Expires April 22, 2010                [Page 11]


Internet-Draft       ALTO information redistribution        October 2009


Authors' Addresses

   Gu Yingjie
   Huawei
   Baixia Road No. 91
   Nanjing, Jiangsu Province  210001
   P.R.China

   Phone: +86-25-84565868
   Fax:   +86-25-84565888
   Email: guyingjie@huawei.com


   Richard Alimi
   Yale Univ.

   Email: richard.alimi@yale.edu


   Roni Even
   Huawei

   Email: ron.even.tlv@gmail.com




























Gu, et al.               Expires April 22, 2010                [Page 12]