Network Working Group S. Das
Internet-Draft V. Narayanan
Intended status: Standards Track Qualcomm, Inc.
Expires: September 5, 2009 March 4, 2009
A Client to Service Query Response Protocol for ALTO
draft-saumitra-alto-queryresponse-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 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
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
Das & Narayanan Expires September 5, 2009 [Page 1]
Internet-Draft multisource March 2009
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
ALTO aims to improve the peer selection in applications that have a
choice to transfer data from multiple data resources. This draft
presents a protocol for a flexible and extensible query response
protocol between an ALTO aware client and ALTO service provider.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ALTO Query Response Protocol . . . . . . . . . . . . . . . . . 4
3.1. ALTO Service Configuration . . . . . . . . . . . . . . . . 5
3.2. ALTO Service Discovery . . . . . . . . . . . . . . . . . . 7
3.3. ALTO Service Contact . . . . . . . . . . . . . . . . . . . 8
3.4. ALTO Message Formats . . . . . . . . . . . . . . . . . . . 8
3.4.1. Presentation Language . . . . . . . . . . . . . . . . 9
3.4.2. Common Header . . . . . . . . . . . . . . . . . . . . 9
3.4.3. Message Contents Format . . . . . . . . . . . . . . . 10
3.4.4. Response Codes and Response Errors . . . . . . . . . . 11
3.4.5. Location Context Query and Response . . . . . . . . . 12
3.4.6. Guidance Query and Response . . . . . . . . . . . . . 15
4. Example Use By An Application . . . . . . . . . . . . . . . . 18
5. Requirements Matching . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Das & Narayanan Expires September 5, 2009 [Page 2]
Internet-Draft multisource March 2009
1. Introduction
Internet traffic is dominated today by P2P (peer-to-peer)
applications used for file transfer, voice communication and live
streaming. Such an architecture for data transfer is attractive
because it reduces the bandwidth costs of the content provider since
they simply need to seed the content to a few nodes in the network
which would then contribute upload bandwidth to assist the content
provider's servers in the data transfer. Thus, the single point
bottleneck at the content provider is eliminated and both users and
content providers benefit.
However such an approach is detrimental to the other important entity
in the system: the ISPs. While p2p has led to the increased
popularity of broadband connections and arguably increased
subscribers for ISPs; it has also increased traffic costs for the
ISPs. This is because P2P application's peer selection does not
consider underlying network topology and link costs in that topology.
Most p2p applications typically are only interested in improving
their data transfer performance which is satisfied if the download
link of the user is saturated. As shown in [10], traffic generated
by popular P2P applications often cross network boundaries multiple
times, overloading links which are frequently subject to congestion
[11]. This happens because most p2p applications simply use random
peer selection followed by monitoring and reevaluation. Even if p2p
applications perform some network measurements, these typically tend
to be round trip time estimation which may or may not lead to peer
selection conducive to ISP interests.
This led to ISPs efforts at shaping or blocking P2P traffic on
specific ports. In response, p2p applictions started using dynamic
ports to transfer data following whcih ISPs had to use deep packet
protocol specific information to shape p2p flows. In response, p2p
applications have started encrypting their connections. The use of
TCP RST messages to deter costly p2p application data transfer has
led to the network neutrality debate as well. It is in the ISPs
interests to avoid the cat-and-mouse games of protocol-specific
detection and mitigation while still not having to increase costs
significantly to accomodate p2p traffic.
One way to reduce the impact on ISPs would be the deployment of
caching entities in the networks to reduce cross-ISP traffic and
network distance of data transfer. However such an approach has
several issues: (1) It is not clear who would deploy these high-
bandwidth large-storage capable caches since it can be argued that
caching pushes the costs from the content provider to the ISPs and.
(2) The caches would need to be able to cache data from all p2p
applications and consequently become complicated to deploy and
Das & Narayanan Expires September 5, 2009 [Page 3]
Internet-Draft multisource March 2009
maintain over time as p2p application evolve. This is specially
difficult due to the heavy tailed nature of p2p content. (3) The use
of caches opens up the issue of storage of illegal and copyrighted
content. Thus, a solution is needed that can allow for peer
selection by the p2p application themselves that is friendly to the
ISPs network costs while being friendly to the application's
objective of good performance for the user.
Recent studies [12], [13], [14] have suggested that it may be
possible to reduce the impact that P2P applications have on ISPs
traffic costs. This is mainly achieved by informed peer selection in
the P2P applications guided by network level metrics instead of
random selection. However, p2p applications do not have a trust
relationship with network operators and what may be good for the ISP
is not necessarily good for the performance of the p2p applications.
This creates a tension between these two competing interests and a
solution for peer selection needs to address the interests of both
the entities in the system. The ALTO working group aims to enable
solutions that addresses this tension. It improves peer selection
while being ISP friendly. The problem statement of ALTO is described
in [1]. The current set of requirements is discussed in [2].
This document describes an ALTO client to service query response
protocol optimizing traffic generated by P2P applications using
information provided by third parties, i.e. the other peers in the
network (through an aggregator ALTO service) or the network operator.
The overall goal of optimizing the P2P application is for them to
become more network-friendly, while at the same time allowing the
networks to remain application-friendly.
The client query response protocol is designed to be flexible and
extensible for multiple aspects of the peer selection problem. such
as FTP and HTTP replicas, locality aware neighbor selection in DHTs
etc. It is also designed to be able to address peer selection that
is ISP-centric as well as peer-centric.
2. Terminology
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 RFC 2119 [3].
3. ALTO Query Response Protocol
The basic setting for the query response protocol is as follows: The
ALTO ecosystem addressed by this draft includes an ALTO client that
Das & Narayanan Expires September 5, 2009 [Page 4]
Internet-Draft multisource March 2009
makes a query and an ALTO service running on an ALTO server that
provides a response. Note that the ALTO client can make a query for
itself or another client.
In the remaining sections we discuss how to discover an ALTO service,
communicate with an ALTO service; message formats for querying an
ALTO service and for responding to an ALTO query
The protocol operates over a single given interface at a time. The
whole procedure can be repeated for a different interface. Each
interface on a multihomed host may require the discovery of a
different ALTO service (since the ISPs on each interface may be
different). The peer selection is also dependent on the interface.
Hence the protocol is meant to operate per interface. Any peer
selection algorithms that work across interfaces would need to
perform ALTO query reponse on each interface and use its own
algorithm to decide which peer to connect to on which interface.
OPEN ISSUE: detecting interfaces with Internet connectivity.
3.1. ALTO Service Configuration
Some mechanisms for ALTO service discovery are described in this
section.
This specification defines a new content type "application/
p2p-alto+xml" for an MIME entity that contains alto information. An
example document is shown below.
<?xml version="1.0" encoding="UTF-8"?>
<alto instance-name="alto.isp.com" expiration="86400">
<alto-server uri="http://192.168.1.19:75"/>
<location-context value="false"/>
<metric-supported name="latency"/>
<metric-supported name="pDistance"/>
<metric-supported name="bandwidth"/>
</alto>
Figure 1: ALTO Service Configuration Document
The file MUST be a well formed XML document and it SHOULD contain an
encoding declaration in the XML declaration. If the charset
parameter of the MIME content type declaration is present and it is
different from the encoding declaration, the charset parameter takes
precedence. Every application conforment to this specification MUST
accept the UTF-8 character encoding to ensure minimal
interoperability. The namespace for the elements defined in this
Das & Narayanan Expires September 5, 2009 [Page 5]
Internet-Draft multisource March 2009
specification is urn:ietf:params:xml:ns:p2p:alto.
The file can contain multiple "alto" elements where each one contains
the configuration information for a different ALTO service. Each
"alto" has the following attributes:
o instance-name: name of the overlay
o expiration: time in future at which this alto configuration is no
longer valid and need to be retrieved again. This is expressed in
seconds from the current time.
o Inside each alto element, the following elements can occur:
* alto-server This element contains the URI at which the ALTO
server can be reached in a "uri" element. This URI is based on
the syntax defined in [4]. More than one alto-server element
may be present for load balance. The client can choose any one
at random. The ALTO server may be running on a public IP
address or be accessible via an overlay.
* OPEN ISSUE: Make p2p URIs flexible enough to allow the ALTO
service to be pointed to by an ip address and port number as
well as a node id on an overlay. This enables an overlay based
ALTO server as well as a more traditional model of a publicly
available ALTO server. Draft [4] revisions will address this
issue.
* location-context This element represents (if set to true) that
the ALTO service mandates a location context query (defined in
Section Section 3.4.5) prior to a guidance query.
* metric-supported This element represents a metric supported by
the ALTO service. It has an attribute called "name" that
represents the name of the metric such as latency, bandwidth,
reliability). A set of metrics and their units should be
standardized and MUST be understood by ALTO clients. More than
one metric-supported element may be present.
OPEN ISSUE: Which metrics should be standardized and what units
should be used for referring to them as well as an accepted
definition of what the units mean. Some important ones are listed
below as a starting point. Applications MUST understand these basic
set of metrics as well as typical values to use in queries.
o name = "bandwidth", unit = "kbps"
Das & Narayanan Expires September 5, 2009 [Page 6]
Internet-Draft multisource March 2009
o name = "latency", unit = "msec", description = "A measure of the
round trip time that is likely between client and a peer"
o name = "pDistance", unit = "scalar"
o name = "uptime", unit = "sec"
o name = "loss", unit = "scalar"
o name = "ASDistance", unit = "scalar"
TODO: Sync these metrics with what is defined for p2psip diagnostics
([5] as well as the various proposals on ISP aided peer selection.
For example having support for a metric such as pDistance would be
useful for many different proposals on ISP aided peer selection. The
metrics used in p2psip diagnostics may be metrics that are useful to
aggregate at an ALTO service in an overlay. This service can then
provide ALTO clients with peer selection guidance.
3.2. ALTO Service Discovery
When a client first wishes to use an ALTO service, it starts with a
discovery process to find a server for the ALTO service. The peer
first determines the ALTO service name. This value is provided by
the user or some other out of band provisioning mechanism. If the
name is an IP address, that is directly used otherwise the peer MUST
do a DNS SRV query using a Service name of "alto_discover" and a
protocol of tcp to find an ALTO server.
Once an address for the ALTO server is determined, the peer forms an
HTTPS connection to that IP address. The certificate MUST match the
overlay name as described in [6].
Whenever a peer contacts the ALTO server, it MUST fetch a new copy of
the ALTO configuration file. To do this, the peer performs a GET to
the URL formed by appending a path of "/alto/enroll" to the alto
service URI. For example, if the ALTO service name was example.com,
the URL would be "https://example.com/alto/enroll". The result is an
XML configuration file described above, which replaces any previously
learned configuration file for this ALTO service.
OPEN ISSUE: performing ALTO service discovery in the context of a
overlay (.e. using p2psip). This could be similar to the mechanisms
presented for TURN server discovery in [7].
Das & Narayanan Expires September 5, 2009 [Page 7]
Internet-Draft multisource March 2009
3.3. ALTO Service Contact
ALTO client and server MUST use TLS for their communication. The
ALTO client contacts the ALTO server using the URI in the ALTO
configuration document.
The following modes can be used for ALTO client-server communication
Method 1: use a shared key between the ALTO client and ALTO server to
set up the TLS session.
Method 2: use server side authentication.
Method 3: use TLS-PSK with an out of band provisioned password. This
allows tiered guidance delivery to different clients. Using this
method, ALTO servers can limit participation, provide QoS to
different levels of users, and prevent misuse and overuse of the ALTO
service
TODO: Including service contact method information in the ALTO
configuration document.
3.4. ALTO Message Formats
The ALTO client to service protocol is a message-oriented request/
response protocol. The messages are encoded using binary fields.
All integers are represented in network byte order.
Each message has three parts, concatenated as shown below:
+-------------------------+
| Common Header |
+-------------------------+
| Message Contents |
+-------------------------+
Figure 2: ALTO Packet
The contents of these parts are as follows:
o Common Header: Each message has a generic header.
o Message Contents: The message being delivered between the client
and the ALTO service.
The following sections describe the format of each part of the
message.
Das & Narayanan Expires September 5, 2009 [Page 8]
Internet-Draft multisource March 2009
3.4.1. Presentation Language
The structures defined in this document are defined using a C-like
syntax based on the presentation language used to define TLS. This
notation is borrwed from the p2psip reload draft [7].
o All lengths are denoted in bytes, not objects.
o Variable length values are denoted like arrays with angle
brackets.
o "select" is used to indicate variant structures.
For instance, "uint16 array(0..2^8-2)" represents up to 254 bytes but
only up to 127 values of two bytes (16 bits) each.
An enum represents an enumerated type. The values associated with
each possibility are represented in parentheses and the maximum value
is represented as a nameless value, for purposes of describing the
width of the containing integral type. For instance, Boolean
represents a true or false:
enum { false (0), true(1), (255)} Boolean;
A boolean value is either a 1 or a 0 and is represented as a single
byte on the wire.
3.4.2. Common Header
struct {
uint8 version;
uint24 length;
CommonOptions options[options_length];
} CommonHeader;
Figure 3: ALTO Common Header
The contents of the structure are:
o version The version of the ALTO protocol being used. This
document describes version 0.1, with a value of 0x01.
o length The count in bytes of the size of the message, including
the header.
o options Contains a series of CommonOptions entries
Das & Narayanan Expires September 5, 2009 [Page 9]
Internet-Draft multisource March 2009
3.4.2.1. Common Header Options
The common header can be extended with forwarding header options,
which are a series of CommonOptions structures:
enum { (255) } CommonOptionsType;
struct {
CommonOptionsType type;
uint16 length;
select (type) { /* Option values go here */ } option;
} CommonOption;
Figure 4: ALTO Common Header Options
The contents of the structure are:
o type The type of the option.
o length The length of the rest of the structure.
o option The option value
3.4.3. Message Contents Format
struct {
MessageCode message_code;
opaque payload<0..2^24-1>;
} MessageContents;
Figure 5: ALTO Message Payload
The contents of this structure are as follows:
o message_code This indicates the message that is being sent. The
code space is broken up as follows.
* 0 Reserved
* 1 .. 0x7fff Requests and responses. These code points are
always paired, with requests being odd and the corresponding
response being the request code plus 1. Thus, "location_query"
(the query) has value 1 and "location_answer" (the response)
has value 2
Das & Narayanan Expires September 5, 2009 [Page 10]
Internet-Draft multisource March 2009
* 0xffff Error
o message_body The message body itself, represented as a variable-
length string of bytes. The bytes themselves are dependent on the
code value. The next few sections describe the different ALTO
methods used in the payload definition.
3.4.4. Response Codes and Response Errors
An ALTO server processing a request returns its status in the
message_code field. If the request was a success, then the message
code is the response code that matches the request (i.e., the next
code up). The response payload is then as defined in the request/
response descriptions.
If the request failed, then the message code is set to 0xffff (error)
and the payload MUST be an error_response PDU, as shown below.
When the message code is 0xffff, the payload MUST be an
ErrorResponse.
struct {
uint16 error_code;
opaque error_info<0..2^16-1>;
} ErrorResponse;
Figure 6: ALTO Response Error
The contents of this structure are as follows:
o error_code A numeric error code indicating the error that
occurred.
o error_info A free form text string indicating the reason for the
response for diagnostic purposes.
The following error code values are defined.
o Error_unauthorized: The client was not authorized to use the ALTO
service.
o Error_hla_not_found: The host location attribute (client location
context) provided was invalid.
o Error_overload: The ALTO service is currently overloaded with
requests and cannot respond. Clients SHOULD implement an
Das & Narayanan Expires September 5, 2009 [Page 11]
Internet-Draft multisource March 2009
algorithm such as binary exponental backoff when restablishing
contact with the ALTO service.
o Error_option_not_found: An option header was not found.
o Error_metric_not_found: A metric requested in the query was not
understood by the ALTO service.
o Error_no_matches: No peers matched the query.
TODO: Make sure the list of errors are comprehensive.
3.4.5. Location Context Query and Response
An ALTO service may need to set a location context for a client prior
to the client sending a guidance query. ALTO services MUST choose
whether to require a location context query or not in the ALTO
configuration document. If the ALTO location-context filled in the
configuration document is set to true, then a querying host MUST
perform a location context query.
3.4.5.1. Location Context Query
The location query message MUST contain a precision value specifying
high precision (0x01), medium precision (0x02) or low precision
(0x03). The ALTO service MAY choose to use this precision in
determining a location context for the querying host. For example
higher precision query would assign a more accurate location context
to the querying host possibly consuming more resources in making that
determination at the ALTO service.
struct {
uint8 precision;
} LocationQuery;
Figure 7: ALTO Query
3.4.5.2. Location Context Response
A response to an ALTO location context query contains the
HostLocationAtttribute of the querying host. This host location
attribute identifies the querying host in the topology. It is
flexible enough to allow an ALTO service to determine the parition id
of a host in P4P and return it, determine the external IP address and
return it etc.
Das & Narayanan Expires September 5, 2009 [Page 12]
Internet-Draft multisource March 2009
The host location attribute MUST be used in a guidance query.
struct {
HostLocationAttribute hla;
} Response;
Figure 8: ALTO Response
The host location attribute is represented as shown below and can be
either an ipv4 address, ipv6 address, overlay node identifer or
partition identifier. This allows for referring to nodes in a
flexible manner. For example, a host can perform an ALTO query to an
overlay based ALTO service and refer to the peers to obtain guidance
for, using node identifiers that make sense on the overlay.
Das & Narayanan Expires September 5, 2009 [Page 13]
Internet-Draft multisource March 2009
enum {reserved_addr(0), ipv4_address (1), ipv6_address (2), node_address (3), partition_id(4),
(255)} HostLocationAttributeType;
struct {
uint32 addr;
} IPv4Addr;
struct {
uint128 addr;
} IPv6Addr;
typedef opaque OverlayNodeAddr[16];
typedef opaque ISPPartitionAddr[16];
struct {
AddressType type;
uint8 length;
select (type) {
case ipv4_address:
IPv4Addr v4addr;
case ipv6_address:
IPv6Addr v6addr;
case node_address:
OverlayNodeAddr nodeaddr;
case partition:
ISPPartitionAddr partitionaddr;
/* This structure can be extended */
} HostLocationAttribute;
Figure 9: Host Location Attribute Representation
As shown in the Figure Figure 9, a host location attribute can encode
ip addresses, node addresses or partition ids.
OverlayNodeAddr and ISPPartitionAddr are fixed-length 128-bit
structures represented as a series of bytes, most significant byte
first.
TODO: Make sure this is extensible enough to accomodate the needs to
different ALTO proposals.
Das & Narayanan Expires September 5, 2009 [Page 14]
Internet-Draft multisource March 2009
3.4.5.3. Obtaining the external address on an interface
If the ALTO location-context filled in the configuration document is
set to false, a querying host MUST obtain the external address on the
interface for which the host needs guidance using either of the two
methods defined below.
Method 1: The querying host SHOULD use the Session Traversal
Utilities for NAT (STUN) [8] to determine a public IP address. If
using this method, the host MUST the "Binding Request" message and
the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the
response. Using STUN requires cooperation from a publicly accessible
STUN server. Thus, the host also requires configuration information
that identifies the STUN server, or a domain name that can be used
for STUN server discovery. To be selected for this purpose, the STUN
server needs to provide the public reflexive transport address of the
host.
Method 2: The querying host may contact a predefined publicly
accessible host configured to respond to a UDP packet on a predefined
port; the data of the response could contain the source IP address
that was in the request. Alternatively, a HTTP server at a
particular URL could be configured to respond to a GET request with a
"text/plain" body containing the IP address of the requester.
However, transparent HTTP proxies can reduce the effectiveness of
this method.
3.4.6. Guidance Query and Response
Once a host location attribute is obtained either using external
address discovery or a location context query, a guidance query can
now be issued to the ALTO server.
Das & Narayanan Expires September 5, 2009 [Page 15]
Internet-Draft multisource March 2009
3.4.6.1. Guidance Query
typedef opaque ObjectId[16];
struct{
uint8 metricname;
uint8 operator;
uint16 value;
}MetricData;
struct {
ObjectId oid;
HostLocationAttribute clienthla;
uint8 precision;
MetricData metrics<0..2^32-1>
HostLocationAttribute destinations<0..2^32-1>;
} Query;
Figure 10: ALTO Guidance Query
The ALTO guidance query is structured as follows:
o clienthla: The host location attribute of the client. This need
not be the same as the actual query host. This allows a third
party to query on behalf on another host. This MUST be specified
in the query.
o precision: This defines the precision of ALTO guidance required by
the client. Current this supports three values: 0x01 for high,
0x02 for medium, 0x03 for low. ALTO server MAY choose to use more
complex or less complex guidance algorithms on the backend for
different precisions requested. The ALTO client MUST define a
value for this field.
o metrics: This is a ranked list of constraints that denotes the
interest of the client. Each metric constraint contains a metric,
operator and value. The metricname is one of the standardized
metric names supported by the specific ALTO service as defined in
the ALTO configuration document. The operator field defines four
values: 0x01 for less than, 0x02 for approximately equal to
(within 10% of), 0x03 for greater than, 0x04 for NA. An operator
of NA means that the querying host wants guidance on the metric
but has no constraint on the metric value.
Das & Narayanan Expires September 5, 2009 [Page 16]
Internet-Draft multisource March 2009
o destinations: This is a list of peers the querying host wishes to
select from. The destinations are a list of host location
attributes.
o oid: This is an optional field containing the object identifier
the query host is aiming to transfer over the network. The
querying host MAY choose to include this field and the ALTO server
MAY choose to use it. This field allows ALTO services that manage
object caches to include them in the guidance response by matching
the oid. For example a querying host may only know 5 sources of
an objects that are all interdomain sources of an object. If the
oid is specified, the ALTO server could include network caches
that match the query constraints in the list of peers returned to
the querying host.
OPEN ISSUE: can we have a widely accepted method of generating the
oid which makes referencing objects and identifying additional peers
with the object easier. One method to use for generating the oid is
content-based naming where the oid is the cryptographic hash of the
object data. Similar techniques have been proposed for data oriented
data transfer recently (e.g. Data Oriented Transfer and Data
Oriented Network Architecture)
3.4.6.2. Guidance Response
The ALTO guidance response contains a ranked list of peers (resource
owners) matching the query contrainsts. The query constraints MUST
take preference in terms of their order in the query. Each item in
the list MUST be the host location attribute of the peer, its
associated metric and a lifetime value corresponding to the number of
seconds this information is valid. This allows caching of peer
selection guidance for repeated accesses to the same object by the
client applications on the querying host. The ALTO service MAY
choose to simply provide a ranking preserving the query constraints
without revealing metric values.
struct {
HostLocationAttribute hla;
MetricData metrics<0..2^8-1>;
uint16 lifetime;
} ResourceOwnerMetric;
struct {
ResourceOwnerMetric selection<0..2^32-1>
} Response;
Das & Narayanan Expires September 5, 2009 [Page 17]
Internet-Draft multisource March 2009
Figure 11: ALTO Guidance Response
4. Example Use By An Application
This section extends a use case and example proposed in [9] and shows
how the use case fits this proposed protocol.
Consider a BitTorrent client that wishes to use the ALTO information.
The client will have a list of perhaps up to 200 initial candidate
peers, out of which it will select perhaps 50 peers to try to connect
to. In an initial implementation, the client could:
Use the ALTO query protocol with metric of latency less than 50ms as
the first metric constraint and pDistance NA as the second query
constraint. This query can be sent out to the ALTO service and a
response received which will contain all peers ranked in terms of
their latency followed by their pDistance.
Split the candidates into three sets: preferred (those with low
latency and high pDistance values), to-be-avoided (those with low
latency and low pDistance values), and default (high latency and high
pDistance values)
Select up to 25 candidates randomly from the preferred set. In
particular, if there are fewer than 25 in the preferred set, select
them all.
Fill remaining slots up to 50 with candidates from the default set.
If this didn't fill the slots (i.e., fewer than 50 of the candidates
were in the union of preferred and default sets), fill the rest by
candidates from the to-be-avoided set.
When establishing connections after the initial startup, continue
using the policy of giving up to half the slots to preferred with the
rest for default and to-be-avoided only as last resort.
When selecting a peer to optimistically unchoke, half the time select
a preferred peer if there is one.
(The particular numbers could be different.) If the preferred peers
perform better than default ones, they will dominate the transfers.
To-be-avoided peers are largely not contacted, unless the prohibitive
policy is broad enough or the swarm is small enough that it is
necessary to contact them to fill the slots.
Das & Narayanan Expires September 5, 2009 [Page 18]
Internet-Draft multisource March 2009
5. Requirements Matching
This section outlines how the proposed protocol meets ALTO query
response requirements.
o REQ. 1: The ALTO service MUST implement one or several well-
defined interfaces, which can be queried from ALTO clients. - This
draft present one defined query response interface.
o REQ. 2: The ALTO clients MUST be able to query information from
the ALTO service, which provides guidance for selecting
appropriate resource providers. - This draft allows the ALTO
service to provide guidance on selecting resource providers.
o REQ. 3: ALTO clients MUST be able to find out where to send ALTO
queries - This draft defines some mechanisms for ALTO service
discovery.
o REQ. 4: One mode of ALTO operation is that ALTO clients may be
embedded directly in the resource consumer (e.g., peer of an
unstructured P2P application), which wants to access a resource. -
This draft does not mandate anything about the locations of ALTO
clients and servers. The goal of the draft is to allow ALTO
client and servers to be servers in the cloud, peers in an overlay
or just IP endpoints.
o REQ. 5: The syntax and semantics of the ALTO protocol MUST be
extensible to allow the requirements of future applications to be
adopted. - This draft attempts to make the query and response
mechanisms generic to achieve this.
o The information available from the ALTO service is not a
replacement for congestion control mechanisms. Applications using
ALTO MUST ensure that they do not cause congestion in the network,
e.g., by using TCP transport, which includes congestion control
mechanisms. - This draft specifies the use of TCP.
o REQ. 7: Any application designed to use ALTO MUST also work
reasonably if no ALTO servers can be found or if no responses to
ALTO queries are received. - No requirement that ALTO be used or
responses received in this draft.
o REQ. 8: An overloaded ALTO server receiving too many requests MAY
silently discard excess requests.- Server endpoint behavior is not
included in this version of the draft. There is not requirement
to respond.
Das & Narayanan Expires September 5, 2009 [Page 19]
Internet-Draft multisource March 2009
o REQ. 9: An ALTO client MAY retransmit an unanswered ALTO query
after a reasonable amount of time, or it MAY query a different
server. - Client endpoint behavior is not included in this version
of the draft.
o REQ. 10: An ALTO client MUST limit the total number of unanswered
ALTO queries on a per-server basis. - Client endpoint behavior is
not included in this version of the draft.
o REQ. 11: If an ALTO query cannot be sent because the maximum
number of outstanding queries is reached, the ALTO client MAY wait
for some time. Then, if it is still not possible to send the
query, it MUST report to the application that no ALTO information
is available. - This is an implementation detail of the ALTO
client. An error response exists to specify overload.
o REQ. 12: An ALTO server, which is operating close to its capacity
limit, SHOULD be able to inform clients about its impending
overload situation, even if it has not yet to discard excess query
messages. - The overload error response achieves this purpose.
o REQ. 13: The ALTO protocol MAY have a mechanism by which the ALTO
client can specify the required level of precision. - This draft
allows a coarse level of precision requested to be included in the
query. The ALTO service MAY choose to use the precision.
o REQ. 14: The ALTO protocol SHOULD support lifetime attributes, to
enable caching of recommendations at ALTO clients.- This draft has
support for lifetime attributes.
o REQ. 15: The ALTO protocol MUST be designed in a way that the ALTO
service can be provided by an operator which is not the operator
of the IP access network. - There is no requirement for the ALTO
service to be tied to the querying host's ISP although they are
likely to have the best information from a network impact point of
view.
o REQ. 16: Different instances of the ALTO service operated by
different providers must be able to coexist. - Any ALTO service
that can understand the query and provide an ALTO configuration
document can provide an ALTO service.
o REQ. 17: The ALTO protocol MUST support mechanisms for mutual
authentication and authorization of ALTO clients and servers. -
This draft specifies some mechanisms to achieve this.
o REQ. 18: The ALTO protocol MUST support different levels of detail
in queries and responses, in order for the operator of an ALTO
Das & Narayanan Expires September 5, 2009 [Page 20]
Internet-Draft multisource March 2009
service to be able to control how much information (e.g., about
the network topology) is disclosed. - The ALTO service need only
provide a ranking without specifying metrics in the guidance
response it is chooses to.
o REQ. 19: The ALTO protocol MUST support different levels of detail
in queries and responses, in order to protect the privacy of
users, to ensure that the operators of ALTO servers and other
users of the same application cannot derive sensitive information.
- This requirement is not very clearly defined.
o REQ. 20: One ALTO interface SHOULD be defined in a way, that the
operator of one ALTO server cannot easily deduce the resource
identifier (e.g., file name in P2P file sharing) which the
resource consumer seeking ALTO guidance wants to access. - The
object id is an optional field in the query. If an ALTO service
provider is deploying caches and p2p applications wish to gain
from using them, they can optinally specify the object id.
o REQ. 21: If the ALTO protocol supports including privacy-sensitive
information (such as resource identifiers or transport addresses)
in the ALTO queries or replies, the protocol MUST also support
encryption, in order to protect the privacy of users with respect
to third parties. - This draft proposes using TLS to secure the
channel between the client and server.
o REQ. 22: The ALTO protocol MUST include appropriate mechanisms to
protect the ALTO service against DoS attacks - This issue is still
open. If clients cooperate with the overlay error response DoS
should not be a threat. Generic DoS mitigation for an ALTO server
is a much bigger problem and out of scope of this draft.
6. Security Considerations
An entity could use the ALTO service to map out and ISPs preferences
and potentially reverse engineer some information about its topology.
This would require querying the ISP ALTO service from multiple
vantage points. An ISP could limit queries made on behalf of other
nodes from an entity to a smaller amount or slightly obfuscate/
randomize its responses to sometimes give higher metric values to
peers in order to thwart such efforts.
This initial draft does not look in detail at security considerations
apart from that mentioned above. Future revisions will contain more
details.
Das & Narayanan Expires September 5, 2009 [Page 21]
Internet-Draft multisource March 2009
7. IANA Considerations
TODO.
8. Acknowledgments
The author would like to thank Vidya Narayanan, Lakshminath Dondeti,
Enrico Marocco, Vijay Gurbani, Jon Peterson for discussions that
helped this draft. The draft was influenced by work being done in
the P2PSIP WG.
9. References
9.1. Normative References
[1] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement",
draft-marocco-alto-problem-statement-04 (work in progress),
February 2009.
[2] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang,
"Application-Layer Traffic Optimization (ALTO) Requirements",
draft-kiesel-alto-reqs-01 (work in progress), November 2008.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Hardie, T., "Mechanisms for use in pointing to overlay
networks, nodes, or resources",
draft-hardie-p2poverlay-pointers-00 (work in progress),
January 2008.
[5] Yongchao, S. and X. Jiang, "Diagnose P2PSIP Overlay Network",
draft-ietf-p2psip-diagnostics-00 (work in progress),
January 2009.
[6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[7] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H.
Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base
Protocol", draft-ietf-p2psip-base-01 (work in progress),
December 2008.
[8] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-18 (work in progress), July 2008.
Das & Narayanan Expires September 5, 2009 [Page 22]
Internet-Draft multisource March 2009
[9] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information
Export Service", draft-shalunov-alto-infoexport-00 (work in
progress), October 2008.
9.2. Informative References
[10] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should
ISPs fear Peer-Assisted Content Distribution?", IMC Proceedings
of the Internet Measurement Conference, 2005.
[11] Akella, A., Seshan, S., and A. Shaikh, "An Empirical Evaluation
of WideArea Internet Bottlenecks", Proceedings of ACM SIGCOMM,
2003.
[12] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and
P2P systems co-operate for improved performance?", ACM SIGCOMM
Computer Communications Review (CCR), 37:3, pp. 29-40, 2006.
[13] Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang,
"P4P: Explicit Communications for Cooperative Control Between
P2P and Network Providers", Proceedings of ACM SIGCOMM, 2008.
[14] Choffnes, D. and F. Bustamante, "Taming the Torrent: A
practical approach to reducing cross-ISP traffic in P2P
systems", Proceedings of ACM SIGCOMM, 2008.
[15] Madhyastha, H., Isdal, T., Piatek, M., Dixon, C., Anderson, T.,
Krishnamurthy, A., and A. Venkataramani, "iPlane: an
information plane for distributed services", Proceedings of
USENIX OSDI, 2006.
Authors' Addresses
Saumitra M. Das
Qualcomm, Inc.
3195 Kifer Road
Santa Clara, CA
USA
Phone: +1 408-533-9529
Email: saumitra@qualcomm.com
Das & Narayanan Expires September 5, 2009 [Page 23]
Internet-Draft multisource March 2009
Vidya Narayanan
Qualcomm, Inc.
5775 Morehouse Dr
San Deigo, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Das & Narayanan Expires September 5, 2009 [Page 24]