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]