One document matched: draft-gu-alto-redistribution-01.txt
Differences from draft-gu-alto-redistribution-00.txt
ALTO Y. Gu
Internet-Draft Huawei
Intended status: Informational R. Alimi
Expires: April 29, 2010 Yale University
R. Even
Huawei
October 26, 2009
ALTO Information Redistribution
draft-gu-alto-redistribution-01
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 29, 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 29, 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 concretely defines ALTO Information
Redistribution, indicates suggested extensions to the ALTO Protocol
to support redistribution, and shows how redistribution could be used
in practice.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 4
3. Redistribution Framework . . . . . . . . . . . . . . . . . . . 4
3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 5
3.2. ALTO Information Types . . . . . . . . . . . . . . . . . . 5
3.3. Redistribution Scheme Design . . . . . . . . . . . . . . . 6
4. ALTO Protocol Requirements . . . . . . . . . . . . . . . . . . 6
4.1. Signature and Authentication . . . . . . . . . . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Tracker-based redistribution . . . . . . . . . . . . . . . 7
5.2. Trackerless redistribution . . . . . . . . . . . . . . . . 9
5.2.1. Lookup in DHT . . . . . . . . . . . . . . . . . . . . 9
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Updating . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Gu, et al. Expires April 29, 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
better peer selection and improving network efficiency. The ALTO
Service becomes a distribution point of network information for 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 if it has not yet been retrieved or needs to be refreshed. For
certain content (e.g., content with broad 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, an
audience of about 24 million watched the program on the 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, such as load balancing, can be used to increase
scalability of an ALTO Service. [I-D.penno-alto-protocol] proposes
ALTO Information Redistribution as one technique. Using ALTO
Information Redistribution, ALTO Clients may distribute ALTO
information to each other instead of requesting directly from the
ALTO Server. For example, a P2P infrastructure can be used to
distribute ALTO information to a large number of ALTO Clients with
small load on the ALTO Server.
This document serves three primary purposes:
1) Defines basic requirements for redistributing ALTO information,
and considerations for developing a redistribution scheme.
2) Propose extensions to the ALTO Protocol to support ALTO
Information redistribution to meet the defined requirements.
3) Provide use cases showing how redistribution may be applied in
practice.
This document contains informational content. We envision that
multiple redistribution schemes are possible, and the design may
depend on the particular setting, such as scalability requirements
and existing application protocols. Thus, standardization of a
Gu, et al. Expires April 29, 2010 [Page 3]
Internet-Draft ALTO Information Redistribution October 2009
redistribution scheme is not currently an objective.
Note that certain design changes during the development of the ALTO
Protocol may affect ALTO information redistribution. This document
will be updated to track the progress of the ALTO Protocol.
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]and [I-D.penno-alto-protocol].
3. Redistribution Framework
Before defining requirements for ALTO Information Redistribution, we
first give a concrete model for ALTO Information Redistribution that
we use in this document:
1. A set of ALTO Servers {S1, S2, S3, ...} are deployed, each
possibly serving a different network region.
2. A set of ALTO Clients are running. We assume that each ALTO
Client can be mapped to one of the available ALTO Servers by the
ALTO discovery process [I-D.song-alto-server-discovery]. Let
Clients(Si) denote the set of ALTO Clients mapped to ALTO Server
Si.
3. An ALTO Client wishes to obtain a particular set of information
from the ALTO Server. The desired information is fully specified
by: (1) the ALTO Server (hostname and port), and (2) the query
and input parameters that would be sent to the ALTO Server. See
Section 6 for a discussion of behavior when criteria other than
the input parameters are used by an ALTO Server to generate a
response.
4. An ALTO Client may obtain the information either directly from
its ALTO Server Si, or it may obtain the information from a
member of Clients(Si).
5. For a particular query to ALTO Server Si, at least one member of
Clients(Si) directly fetches from Si. The remaining members of
Clients(Si) obtain the information from some other member in
Clients(Si).
Gu, et al. Expires April 29, 2010 [Page 4]
Internet-Draft ALTO Information Redistribution October 2009
3.1. Basic Requirements
A redistribution scheme should satisfy some basic requirements in
order to successfully redistribute an ALTO Server's response to a set
of ALTO Client.
1. The ALTO Client should be able to identify the desired
redistributed data based only on the ALTO Server hostname and
port, 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 its ALTO Server.
3.2. ALTO Information Types
In general, it should be possible to redistribute the response from a
particular ALTO Server that does not depend on anything except query
input parameters. 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. The example list the most
obvious examples to our best knowledge, and there might be other
information types that are suitable for redistribution.
o Server Capability which indicates the capabilities implemented by
an ALTO Server.
o Full Network Map which lists the PIDs and IP prefixes that are
contained within each PID.
o Full Path Cost Map among all PIDs, which indicates the Path Cost
between each pair of 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 within the same swarm).
Gu, et al. Expires April 29, 2010 [Page 5]
Internet-Draft ALTO Information Redistribution October 2009
3.3. Redistribution Scheme Design
While this document does not fully specify a particular
redistribution scheme, it provides a set of decisions that should be
considered when implementing a redistribution scheme. This list can
be used as a guide for implementers when designing a redistribution
scheme for a particular setting. Considerations for a redistribution
scheme include:
o Which ALTO Client(s) directly query the ALTO Server?
o What method is used for locating redistributed ALTO information?
o What naming scheme is used to specify the ALTO Server hostname,
port, and 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.
o What protocol is used for retrieving redistributed ALTO
information?
o How is the redistributed information encoded? Note that the
original response from the ALTO Service may be reformatted (e.g.,
compressed) for redistribution. Note that if this approach is
taken and ALTO Clients still wish to verify received information,
ALTO Clients should be able to reconstruct the ALTO Service's
original response (e.g., via decompression). If a lossy
transformation is used (e.g., filtering), ALTO Clients may not be
able to verify the received information.
4. ALTO Protocol Requirements
4.1. Signature and Authentication
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 allow ALTO Clients to verify the information before it
is utilized.
This section proposes a scheme through which ALTO clients can verify
redistributed ALTO information. The signature for a particular piece
of ALTO information (query response) is generated by ALTO Server that
provides the information. The signature is composed of at least two
parts: (1) the input parameters for generating the information (e.g.,
the full request URL used by an ALTO Client), and (2) hash of the
Gu, et al. Expires April 29, 2010 [Page 6]
Internet-Draft ALTO Information Redistribution October 2009
returned ALTO information (i.e., the ALTO Server's response). The
concatenation of the two parts is signed by ALTO server's Private
Key.
+-------------------------------------------+
( | Input parameters | Hash(ALTO information) | ) AS_PrivateKey
+-------------------------------------------+
Signature format
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. Get the public key 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 a particular P2P application will affect the
redistribution mechanism. Generally speaking, there are two kinds of
P2P applications: trackerless, and those using a tracker. 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.
5.1. Tracker-based redistribution
1. The Tracker finds the ALTO server on behalf of a peer, queries
the necessary ALTO information and replies to the peer with the
ALTO information as well as the candidate list.
[I-D.kiesel-alto-3pdisc] describes several methods by which
Gu, et al. Expires April 29, 2010 [Page 7]
Internet-Draft ALTO Information Redistribution October 2009
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 to 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 the first one.
+-------------+
| |
| 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
Gu, et al. Expires April 29, 2010 [Page 8]
Internet-Draft ALTO Information Redistribution October 2009
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.
+------------+
| |
| 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
Information redistribution among peers in Trackerless P2P Overlay
5.2.1. Lookup in DHT
When searching for a piece of data in a DHT, a node constructs an
identifier for the desired data. We propose here a simple naming
scheme that can be used to lookup ALTO Information in a DHT. This is
provided as a suggestion for an implementation technique, and is not
a requirement on redistribution implementations employing a DHT.
Also note that the ALTO Information does not need to be included
directly in the DHT. A mechanism such as the Distributed Tracker
implemented in Vuze [http://www.vuze.com] could be used to locate an
ALTO Client that in turn provides access to the ALTO Information.
Gu, et al. Expires April 29, 2010 [Page 9]
Internet-Draft ALTO Information Redistribution October 2009
This naming 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 ALTO Server hostname and port). Thus, we compute
a hash of the form:
hash("alto:REQUEST_URL")
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 directly. The
resulting string can be used as the lookup key in the DHT.
The following simple examples show how the scheme applies to the
Information Types in Section 3.2:
1) Server Capability
hash("alto:http://alto.example.com:80/capability").
2) Full Network Map.
hash("alto:http://alto.example.com:80/prop/pid/map").
3) Full Path Cost among all PIDs
hash("alto:http://alto.example.com:80/cost/pid/map").
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 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.
Gu, et al. Expires April 29, 2010 [Page 10]
Internet-Draft ALTO Information Redistribution October 2009
Operators of an ALTO Server should be cognizant that ALTO Information
that is distributed may not be able to be "revoked" and replaced
immediately at all ALTO Clients. If the distributed information
includes caching parameters, these parameters may cause the
information to be returned to ALTO Clients by HTTP Caches or via
redistribution mechanisms until the cache parameters indicate that
the data has expired.
7. Security Considerations
ALTO Clients should be able to verify redistributed ALTO Information,
as documented in Section 4.2. Additional support is required in
[I-D.penno-alto-protocol] to support this verification mechanism.
A redistribution mechanism may suffer from a Denial of Service attack
if malicious (or faulty) ALTO Clients are in charge of fetching
updated content from an ALTO Server. In such a case, ALTO Clients
relying on redistributed information may not receive any information
at all, or the received information may not pass the signature
verification process. These ALTO Clients may contact the original
ALTO Service to retrieve ALTO information, or they may continue with
their default behavior without ALTO information.
8. Acknowledgments
The authors would like to give special thanks to Jan Seedorf and many
others for the illuminative discussion in the mailing list. The
authors also thank David Bryan for providing comments on preliminary
versions of the draft.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-alto-problem-statement]
Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement",
draft-ietf-alto-problem-statement-04 (work in progress),
September 2009.
Gu, et al. Expires April 29, 2010 [Page 11]
Internet-Draft ALTO Information Redistribution October 2009
9.2. Informative References
[I-D.penno-alto-protocol]
Penno, R. and Y. Yang, "ALTO Protocol",
draft-penno-alto-protocol-03 (work in progress),
July 2009.
[I-D.kiesel-alto-3pdisc]
Kiesel, S. and M. Tomsu, "Third-party ALTO server
discovery", draft-kiesel-alto-3pdisc-00 (work in
progress), August 2009.
[I-D.song-alto-server-discovery]
Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual,
"ALTO Service Discovery",
draft-song-alto-server-discovery-01 (work in progress),
July 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 University
Email: richard.alimi@yale.edu
Roni Even
Huawei
Email: ron.even.tlv@gmail.com
Gu, et al. Expires April 29, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 20:08:42 |