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]