ALTO S. Kiesel
Internet-Draft University of Stuttgart
Intended status: Standards Track M. Stiemerling
Expires: September 9, 2010 NEC Europe Ltd.
March 8, 2010
ALTO H12
draft-kiesel-alto-h12-02
Abstract
Many Internet applications are used to access resources, such as
pieces of information or server processes, which are available in
several equivalent replicas on different hosts. This includes, but
is not limited to, peer-to-peer file sharing applications. The goal
of Application-Layer Traffic Optimization (ALTO) is to provide
guidance to applications, which have to select one or several hosts
from a set of candidates, that are able to provide a desired
resource. This memo proposes the Simple ALTO (H12) protocol.
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 9, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kiesel & Stiemerling Expires September 9, 2010 [Page 1]
Internet-Draft SALTO March 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 4
3. H12 Operational Model . . . . . . . . . . . . . . . . . . . . 6
4. Proposed Protocol Semantics . . . . . . . . . . . . . . . . . 8
4.1. Locating the H12 Server Capabilities . . . . . . . . . . . 8
4.2. Learning the H12 Server Capabilities . . . . . . . . . . . 8
4.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Querying the ALTO Server . . . . . . . . . . . . . . . . . 9
4.5. ALTO Server Response . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix 1. Full XML-Response . . . . . . . . . . . . . . . . . . 17
Appendix 2. Acknowledgments . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Kiesel & Stiemerling Expires September 9, 2010 [Page 2]
Internet-Draft SALTO March 2010
1. Introduction
Many Internet applications are used to access resources, such as
pieces of information or server processes, which are available in
several equivalent replicas on different hosts. This includes, but
is not limited to, peer-to-peer file sharing applications. The goal
of Application-Layer Traffic Optimization (ALTO) is to provide
guidance to applications, which have to select one or several hosts
from a set of candidates, that are able to provide a desired
resource. This memo proposes the Simple ALTO (H12) protocol. The
H12 protocol is a client/server protocol between ALTO clients and
ALTO servers, where ALTO clients can be either peer-to-peer
applications residing on end hosts or peer-to-peer tracker servers.
The basic ideas of ALTO are described in the problem space of ALTO is
described in [RFC5693] and the set of requirements is discussed in
[I-D.kiesel-alto-reqs].
Comments and discussions about this protocol proposal should be
directed to the ALTO working group: alto@ietf.org.
Kiesel & Stiemerling Expires September 9, 2010 [Page 3]
Internet-Draft SALTO March 2010
2. Protocol Framework
The ALTO protocol is a client/server protocol, operating between a
number of ALTO clients and an ALTO server, as sketched in Figure 1
+----------+
| ALTO |
| Server |
+----------+
^
_.-----|------.
,-'' | `--.
,' | `.
( Network | )
`. | ,'
`--. | _.-'
`------|-----''
v
+----------+ +----------+ +----------+
| ALTO | | ALTO |...| ALTO |
| Client | | Client | | Client |
+----------+ +----------+ +----------+
Figure 1: Network Overview of ALTO Protocol
An ALTO server stores information about preferences (e.g., a list of
preferred autonomous systems, IP ranges, etc) and ALTO clients can
retrieve these preferences. However, there are basically two
different approaches on where the preferences are actually processed:
1. The ALTO server has a list of preferences and clients can
retrieve this list via the ALTO protocol. This preference list
can be partially updated by the server. The actual processing of
the data is done on the client and thus there is no data of the
client's operation revealed to the ALTO server . This approach
has been proposed by [I-D.shalunov-alto-infoexport].
2. The ALTO server has a list of preferences or preferences
calculated during runtime and the ALTO client is sending
information of its operation (e.g., a list of IP addresses) to
the server. The server is using this operational information to
determine its preferences and returns these preferences (e.g., a
sorted list of the IP addresses) back to the ALTO client. This
approach has been initially described in [ACM.ispp2p], but never
been described on the protocol level.
Approach 1 (we call it H1) has the advantage (seen from the client)
that all operational information stays within the client and is not
Kiesel & Stiemerling Expires September 9, 2010 [Page 4]
Internet-Draft SALTO March 2010
revealed to the provider of the server. On the other hand, does
approach 1 require that the provider of the ALTO server, i.e., the
network operator, reveals information about its network structure
(e.g., AS numbers, IP ranges, topology information in general) to the
ALTO client.
Approach 2 (we call it H2) has the advantage (seen from the operator)
that all operational information stays with the ALTO server and is
not revealed to the ALTO client. On the other hand, does approach 2
require that the clients send their operational information to the
server.
Both approaches have their pros and cons and are extensively
discussed on the ALTO mailing list. But there is basically a
dilemma: Approach 1 is seen as the only working solution by peer-to-
peer software vendors and approach 2 is seen as the only working by
the network operators. But neither the software vendors nor the
operators seem to willing to change their position. However, there
is the need to get both sides on board, to come to a solution.
Therefore, this does memo proposes to integrate both approaches in
one protocol and offer a way for clients and servers to learn each
preferred way of operating.
Kiesel & Stiemerling Expires September 9, 2010 [Page 5]
Internet-Draft SALTO March 2010
3. H12 Operational Model
The P4P protocol proposal [I-D.penno-alto-protocol] assumes that the
ALTO server maintains two different databases that store the server-
side information necessary to guide ALTO clients. There is the
network map that provides a mapping between network prefixes and a
macro called partition ID (PID) and the cost map that relates PIDs to
costs.
H12 assumes also that the H12 server internally maintains two maps,
one for the network partitioning and the other for the associated
costs, but does not need that the information stored in these maps is
also conveyed to the H12 client in one piece. However, this memo is
not specifying how the server is implemented, it is only specifying
the ALTO protocol.
The client puts one or several host location attributes, about which
it wants to receive a rating, in the query message.
The server replies with a list of network location attributes, in the
same format as in the query, and the respective ratings for the
requested attributes. However, the number of lines in this list may
be shorter or longer than in the query, and the prefix lengths may be
different:
o The server may decide not to give any rating for a specific
location attribute. In this case, a default value applies.
o Instead of rating several location attributes with long prefix
lengths (in particular: individual IP addresses) individually, the
server may decide to give only one rating for a broader address
range (i.e., prefix length is shorter).
o Instead of giving one rating for a large address range, the server
may decide to give several ratings for smaller ranges (i.e., i.e.,
each returned entry has a prefix length that is longer that
requested).
The actual rating is given for each rating criterion as a signed
integer value. A value of zero (0) means "default value". This
value is to be used if the server has no information regarding this
(network location attribute, rating criteria) tuple, or if it does
not want to disclose it. Positive values mean that this location is
"better" than default and therefore should be preferred for peer
selection, while negative values indicate the location to be "worse"
than default and therefore that it should be avoided. The meaning of
"better" and "worse", as well as the scale has to be defined
individually for each rating criterion.
Kiesel & Stiemerling Expires September 9, 2010 [Page 6]
Internet-Draft SALTO March 2010
This approach gives both sides, i.e., server and clients, to still
exchange their desired information and level of precision, but also
gives the chance to hide information if necessary and desired.
Kiesel & Stiemerling Expires September 9, 2010 [Page 7]
Internet-Draft SALTO March 2010
4. Proposed Protocol Semantics
H12 uses HTTP/1.1 and TCP as transport protocol between H12 clients
and H12 servers. The encoding of the message body is done with XML.
The usage of HTTP is similar to [I-D.penno-alto-protocol] also with
the intention to reuse existing HTTP software and deployments.
H12 is aiming at keeping the level of involvement of the application
that is using ALTO as low as possible. I.e., requiring an
application, such as p2p file sharing, to use ALTO is already a
considerable step. The implementers of the application must be able
to use ALTO with a very low effort. It is assumed that the
complexity of ALTO, in terms of implementation and operational
effort, is mainly handled at the server.
Unlike the H1H2 protocol[I-D.stiemerling-alto-h1h2-protocol] the H12
protocol does not have several modes of operation, which have to be
negotiated at the startup. Instead it allows the client and the
server some flexibility in the requests and the responses while using
only on mode of operation.
4.1. Locating the H12 Server Capabilities
H12 clients initially need to locate the right H12 server that is in
charge of serving them. This step and the technical solution to
locate such ALTO server is currently discussed within the ALTO
working group. This memo does not yet define such H12 server
discovery.
4.2. Learning the H12 Server Capabilities
This section describes how an ALTO client can learn about the
capabilities of the ALTO server.
H12 clients initially need to locate the right H12 server that is in
charge of serving them. This step and the technical solution to
locate such ALTO server is currently discussed within the ALTO
working group. This memo does not yet define such H12 server
discovery.
The first step for a H12 client, before it can start querying for
ALTO guidance, is to request the H12 server capabilities. The server
capabilities are, e.g., administrative information (operator of the
server, contact addresses, etc), the supported host location
attributes (IP addresses or IP prefixes), the supported rating
criteria, and the URIs to query for ALTO guidance. The H12 protocol
uses only a single static URI path for retrieving the capability
information. All other query URIs are announced by the server during
Kiesel & Stiemerling Expires September 9, 2010 [Page 8]
Internet-Draft SALTO March 2010
the capability retrieval.
4.3. Redirection
There are basically two cases where a H12 server has to redirect
request to other locations:
a. the queried H12 server is overload and can tell about other H12
server;
b. the queried H12 server is overload and cannot tell about other
H12 server;
c. the queried H12 server is solely used as entry point and
redirects the actual H12 server;
d. the querying host in not allowed to use this ALTO server (e.g.,
host in ISP1 is querying ALTO server in ISP2) (which is a sub
case of (a)).
4.4. Querying the ALTO Server
An ALTO client can query on its own or on behalf of other peers
(e.g., a tracker). This is indicated in the resource consumer host
location attribute rc_hla in the ALTO query. The query body itself
contains the list of IP addresses or IP prefixes the ALTO client is
asking guidance for. This shows a example list Figure 2 of IP
addresses queried for
Kiesel & Stiemerling Expires September 9, 2010 [Page 9]
Internet-Draft SALTO March 2010
195.37.70.39/32 # mito.netlab.nec.de
193.141.139.237/32 # www.nec.de
58.89.210.171/32 # www.nec.co.jp
122.224.8.143/32 # www.huawei.cn
202.103.147.132/32 # www.zte.com.cn
135.245.1.29/32 # www.alcatel.de
139.15.248.12/32 # www.bosch.de
141.113.97.34/32 # www.daimler.de
129.206.0.0/16 # university of heidelberg
129.13.0.0/16 # university of karlsruhe
129.69.0.0/16 # university of stuttgart
130.83.0.0/16 # university of darmstadt
130.149.0.0/16 # university of berlin (TU)
171.67.0.0/16 # stanford university
129.78.64.24 # university of sidney
12.110.110.204/32 # www.nsa.gov
85.180.57.61/32 # some random residential DSL user (ALICE)
84.56.180.139/32 # some random residential DSL user (Arcor)
62.227.16.206/32 # some random residential DSL user (DTAG)
80.238.206.25/32 # some random residential DSL user in .ch
Figure 2: Example Candidate IPs for Query
The query is constructed as show in the below exampleFigure 3. The
client requests guidance for the IP prefixes out of Figure 2 for its
own IP address (prefix='195.37.70.39/32') stated in the rc_hla.
Kiesel & Stiemerling Expires September 9, 2010 [Page 10]
Internet-Draft SALTO March 2010
Figure 3: XML encoded Query
This ipprefix tag carries a full IP address or an IP address prefix,
leaving the client the choice how much of an IP address it wants to
reveal to the server. That is, the client can request information
for one or several specific IP addresses (prefix length equal 32 or
128), for address ranges, or for "the whole Internet" (prefix length
equal 0). However, the "whole Internet" is not really referring to
the whole Internet as such, as no single entity can have such a big
knowledge, but to whatever broader scope the server can give guidance
about. This scope can include, for instance, its own complete
network.
Furthermore, the client specifies one or several rating criteria,
such as operator preference, lower bound for delay, etc. Here is a
work-in-progress list of such rating criteria, consisting of two
levels of rating criteria offered to the client are:
Kiesel & Stiemerling Expires September 9, 2010 [Page 11]
Internet-Draft SALTO March 2010
o Primary rating criterion
o Further rating criteria
The offered rating criteria are:
o operator's relative preference
o Topological distance (Number of AS hops)
o minimum boundary for upload bandwidth
4.5. ALTO Server Response
This section discussions at this of point of time only a positive
reply. All other cases are TBD in this write-up. The listed
response is shortened, see Section 1 for the full answer. The
examplatory answer is listed for the IP address 193.141.139.237/32
and 202.103.147.132/32, and for the IP prefix 129.13.0.0/16.
The rating response given in the candidate host location attributes
(cnd_hla) is different for the single requests, depending on what
information can be delivered by the server. For 193.141.139.237/32,
the server replies with two prefixes belonging to the same ISP. For
202.103.147.132/32, the server replies with even more details about
other prefixes belonging to the same operator. The ensures that the
client automatically learns even more prefixes the operator gives the
same guidance for. A simple response is shown for the query about
129.13.0.0/16, where the response contains only the same prefixes as
in the request.
Kiesel & Stiemerling Expires September 9, 2010 [Page 12]
Internet-Draft SALTO March 2010
Figure 4: XML encoded Query
The response contains also a resource consumer host location
attribute (rc_hla). This rc_hla echos partially the information from
the request, but gives actually guidance to the ALTO client in what
scope this information can be distributed amongst other peers. In
this response, the server allows the redistribution of the received
guidance to peers with the IP prefix 195.37.0.0/16.
Kiesel & Stiemerling Expires September 9, 2010 [Page 13]
Internet-Draft SALTO March 2010
5. Security Considerations
This initial version of this memo does not yet a full security
considerations, but they will be added in future revision.
minimum boundary for upload bandwidth (AKA provisioned upload
bandwidth): criminal suspects can easily re-use the geographical
coordinates of an IP address (taken from whois) and google maps to
correlate IP addresses and wealth of subscribers of that IP address.
Kiesel & Stiemerling Expires September 9, 2010 [Page 14]
Internet-Draft SALTO March 2010
6. Conclusion
This memo presents a very basic protocol, for sure work in progress,
and is requesting feedback from the ALTO working group. Sebastian
Kiesel is implementing the herein proposed protocol.
Kiesel & Stiemerling Expires September 9, 2010 [Page 15]
Internet-Draft SALTO March 2010
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[ACM.ispp2p]
Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs
and P2P systems co-operate for improved performance?", In
ACM SIGCOMM Computer Communications Review
(CCR), 37:3, pp. 29-40.
[I-D.kiesel-alto-reqs]
Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.
Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-kiesel-alto-reqs-02 (work in
progress), March 2009.
[I-D.penno-alto-protocol]
Penno, R. and Y. Yang, "ALTO Protocol",
draft-penno-alto-protocol-04 (work in progress),
October 2009.
[I-D.shalunov-alto-infoexport]
Shalunov, S., Penno, R., and R. Woundy, "ALTO Information
Export Service", draft-shalunov-alto-infoexport-00 (work
in progress), October 2008.
[I-D.stiemerling-alto-h1h2-protocol]
Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol",
draft-stiemerling-alto-h1h2-protocol-00 (work in
progress), March 2009.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
Kiesel & Stiemerling Expires September 9, 2010 [Page 16]
Internet-Draft SALTO March 2010
1. Full XML-Response
Kiesel & Stiemerling Expires September 9, 2010 [Page 17]
Internet-Draft SALTO March 2010
Kiesel & Stiemerling Expires September 9, 2010 [Page 18]
Internet-Draft SALTO March 2010
Kiesel & Stiemerling Expires September 9, 2010 [Page 19]
Internet-Draft SALTO March 2010
Figure 5: XML encoded Query
Kiesel & Stiemerling Expires September 9, 2010 [Page 20]
Internet-Draft SALTO March 2010
2. Acknowledgments
Martin Stiemerling is partially supported by the NAPA-WINE project
(Network-Aware P2P-TV Application over Wise Networks,
http://www.napa-wine.org), a research project supported by the
European Commission under its 7th Framework Program (contract no.
214412). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the NAPA-WINE project or the European Commission.
Kiesel & Stiemerling Expires September 9, 2010 [Page 21]
Internet-Draft SALTO March 2010
Authors' Addresses
Sebastian Kiesel
University of Stuttgart, Computing Center
Allmandring 30
Stuttgart 70550
Germany
Email: ietf-alto@skiesel.de
Martin Stiemerling
NEC Laboratories Europe/University of Goettingen
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 113
Fax: +49 6221 4342 155
Email: stiemerling@cs.uni-goettingen.de
Kiesel & Stiemerling Expires September 9, 2010 [Page 22]