ALTO S. Kiesel
Internet-Draft NEC Europe Ltd.
Intended status: Informational M. Tomsu
Expires: February 27, 2010 Alcatel-Lucent Bell Labs
August 26, 2009
Third-party ALTO server discovery
draft-kiesel-alto-3pdisc-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 February 27, 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.
Kiesel & Tomsu Expires February 27, 2010 [Page 1]
Internet-Draft Third-party ALTO server discovery August 2009
Abstract
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 document describes why a third-party ALTO server discovery
mechanism is required for an important class of applications, namely
tracker-based P2P applications. Several solution approaches are
classified and evaluated. The conclusion is that further work is
required to standardize a protocol and procedures that follow one
specific approach.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The need for third-party ALTO queries . . . . . . . . . . 4
2.2. The need for third-party ALTO server discovery . . . . . . 4
3. Classification of solution approaches . . . . . . . . . . . . 6
3.1. Solutions that do not require an update of the
application protocol . . . . . . . . . . . . . . . . . . . 6
3.2. Solutions that do require an update of the application
protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Approach #1 . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Approach #2 . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Approach #3 . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Approach #4 . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Approach #5 . . . . . . . . . . . . . . . . . . . . . . . 9
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Kiesel & Tomsu Expires February 27, 2010 [Page 2]
Internet-Draft Third-party ALTO server discovery August 2009
1. Introduction
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. ALTO is realized by a client-server protocol. ALTO
clients send queries to ALTO servers, in order to solicit guidance.
The ALTO client can be embedded in the resource consumer, which will
eventually access the desired resource. As an alternative, the ALTO
client can be embedded in a resource directory, which assists
resource consumers in finding appropriate resource providers. ALTO
queries in the latter case will be refered to as third-party ALTO
queries.
The challenge for third-party ALTO queries is that they have to be
answered by the "right" ALTO server, i.e., the ALTO server which has
the knowledge to give guidance to the resource consumer on behalf of
which the query is sent.
This document uses the terminology introduced in
[I-D.ietf-alto-problem-statement] and it investigates solution
approaches that fulfill the requirements for ALTO server discovery
documented in [I-D.ietf-alto-reqs].
Comments and discussions about this document should be directed to
the ALTO working group: alto@ietf.org.
Kiesel & Tomsu Expires February 27, 2010 [Page 3]
Internet-Draft Third-party ALTO server discovery August 2009
2. Problem statement
2.1. The need for third-party ALTO queries
The scope of this document is the interaction of peer-to-peer
applications, that use a centralized resource directory ("tracker"),
with the ALTO service. In this scenario, the resource consumer asks
the resource directory for a list of potential resource providers,
which can provide the desired resource. Usually, only a subset of
all resource providers known to the resource directory will
eventually be contacted by the resource consumer for accessing the
resource. The purpose of ALTO is giving guidance on this peer
selection, which is supposed to yield better-than-random results.
There are two possibilities where to apply the ALTO guidance, in the
resource consumer or in the resource directory:
In the first scenario, the resource directory returns a list of
potential resource providers without considering ALTO. It is then
the duty of the resource consumer to invoke ALTO, in order to solicit
guidance regarding this list. The problem with this approach is,
that while the resource directory might know thousands of peers
taking part in a swarm, the list returned to the resource consumer is
usually shortened for efficiency reasons. Therefore, the "best" (in
the sense of ALTO) potential resource providers might not be
contained in that list anymore, even before ALTO can consider them.
In the second scenario, the resource directory has an embedded ALTO
client, which we will refer to as RDAC in this document. The
resource directory invokes the RDAC to evaluate all resource
providers it knows. Then it returns a, possibly shortened, list
containing the "best" resource providers to the resource consumer.
From an overall optimization perspective, this scenario is
advantageous, because it is ensured that the addresses of the "best"
resource providers are actually delivered to the resource consumer.
2.2. The need for third-party ALTO server discovery
The previous section has shown why it is advantageous that entities
such as resource directories can perform ALTO queries on behalf of
resource consumers. We will refer to this kind of ALTO query as
"third-party ALTO query".
ALTO queries are sent to ALTO servers, which have knowledge of
network topology and other information on which the ALTO guidance is
based. One deployment scenario for ALTO is to establish a group of
centralized ALTO servers which have complete knowledge and therefore
can evaluate any pair of resource consumers and providers,
Kiesel & Tomsu Expires February 27, 2010 [Page 4]
Internet-Draft Third-party ALTO server discovery August 2009
respectively.
However, it is likely that there will be deplopyment scenarios with
many ALTO servers, each having only partial knowledge and therefore
being able to give guidance regarding only a defined group of
resource consumers (e.g., those in its topological vicinity, or those
connected to the same network operator). The reasons for
partitioning the overall knowledge include scalability and separate
administrative responsibilities. For the remainder of this document,
we assume that the second scenario has to be supported. The first
scenario can be seen as special case of it, i.e., a solution that
supports the second scenario will support the first scenario as well.
The challenge for third-party ALTO queries is that they have to be
answered by the "right" ALTO server, i.e,, the ALTO server which has
the knowledge to give guidance to the resource consumer on behalf of
which the query is sent.
Kiesel & Tomsu Expires February 27, 2010 [Page 5]
Internet-Draft Third-party ALTO server discovery August 2009
3. Classification of solution approaches
There are several approaches for directing a third-party ALTO query
from the RDAC to the "right" ALTO server. The selection of the
"right" ALTO server needs to consider the resource consumer, on
behalf of which the query will be performed. The set of available
options therefore depends on the available information about the
resource consumer,
The primary criterion in the following classification is whether ALTO
must work together with all existing (P2P) application protocols, or
whether we can assume that these protocols can be augmented with new
ALTO-specific information fields.
3.1. Solutions that do not require an update of the application
protocol
If we do not want to make specific assumptions on the (P2P)
application protocol, we cannot assume that there are any other peer
identifiers apart from IP addresses. Therefore, we assume that the
only information identifying the resource consumer is the source IP
address of messages sent from the resouce consumer to the resource
directory. This address may be the (public) IP address of the
resource consumer, or it may be the external address of the last NAT
on the path between resource consumer and resource directory.
The RDAC that wants to perform the third-party ALTO query has two
options:
o Approach #1: The RDAC invokes a discovery mechanism external to
the ALTO client protocol, in order to map from the resource
consumer's IP address to the "right" ALTO server. The ALTO query
will then be sent there directly.
o Approach #2: Independent of the resource consumer's identity, the
RDAC uses the ALTO client protocol to send the ALTO query to one
preconfigured ALTO server. The resource consumer's IP address is
included in the query message. Based on this IP address and using
mechanisms of the ALTO client protocol the first ALTO server
redirects or forwards the query to the "right" ALTO server. This
implies that ALTO servers must know each other, based on some
discovery mechanism or manual configuration.
3.2. Solutions that do require an update of the application protocol
If we assume that applications can be upgraded in order to support
ALTO, the resource consumer can provide additional information to the
RDAC in order to assist the process of ALTO server discovery.
Kiesel & Tomsu Expires February 27, 2010 [Page 6]
Internet-Draft Third-party ALTO server discovery August 2009
o Approach #3: Using the extended application protocol, the resource
consumer sends an additional peer-ID, which can be understood by
ALTO, to the resource directory. This peer-ID could be used to
uniquely identify resource consumers and providers located behind
NATs. The RDAC uses this peer-ID instead of the resource
consumer's IP address. In all other aspects this approach is
identical to approach #1.
o Approach #4: This approach is identical to approach #2, except
that the peer-ID is used instead of the IP address, as described
in approach #3.
o Approach #5: The resource consumer discovers its ALTO server on
its own (i.e., not a third-party discovery). Using the extended
application protocol it sends the ALTO server's address to the
RDAC. The RDAC can use it for sending third-party ALTO queries
there.
Kiesel & Tomsu Expires February 27, 2010 [Page 7]
Internet-Draft Third-party ALTO server discovery August 2009
4. Discussion
This section assesses and compares the different approaches
introduced above, regarding trust, scalability, integration into
existing ISP infrastructure and management processes, modification of
existing applications, and ongoing ALTO architecture specification
works.
4.1. Approach #1
The existence of a mechanism according to approach #1 is assumed by
[I-D.penno-alto-protocol].
This approach does not require any changes of existing (P2P)
application protocols. However, the RDAC needs to implement an
additional protocol for performing third-party ALTO server discovery.
One possible way of implementing this approach would be based on DNS,
providing a mapping from the resource consumer's IP address to the IP
address of the corresponding "right" ALTO server. DNS is proven to
be scalable and has well-understood mechanisms for delegating
authority. Network operators are used to DNS management.
This approach does not support intra-domain traffic optimization for
large domains behind a NAT.
4.2. Approach #2
This approach does not require any changes of existing (P2P)
application protocols.
Furthermore, the RDAC does not need to implement an additional
protocol besides the ALTO client protocol. However, this approach
relocates the discovery problem from the RDAC to the first ALTO
server.
This first ALTO server, when preconfigured in the RDAC of a large
resource directory, would raise serious concerns about scalability
and trust/security issues.
This approach does not support intra-domain traffic optimization for
large domains behind a NAT.
4.3. Approach #3
This approach requires changes to all existing (P2P) application
protocols that want to benefit from ALTO.
Kiesel & Tomsu Expires February 27, 2010 [Page 8]
Internet-Draft Third-party ALTO server discovery August 2009
This approach supports intra-domain traffic optimization for large
domains behind a NAT.
Except for the abovementioned statements, the same results as for
approach #1 apply.
4.4. Approach #4
This approach requires changes to all existing (P2P) application
protocols that want to benefit from ALTO.
This approach supports intra-domain traffic optimization for large
domains behind a NAT.
Except for the abovementioned statements, the same results as for
approach #2 apply.
4.5. Approach #5
This approach requires changes to all existing (P2P) application
protocols that want to benefit from ALTO.
This approach does not need a mechanism for third-party ALTO server
discovery, as the ALTO server is discovered by the resource consumer.
However, a mechanism for this kind of discovery is needed, see, e.g.,
[I-D.song-alto-server-discovery].
Kiesel & Tomsu Expires February 27, 2010 [Page 9]
Internet-Draft Third-party ALTO server discovery August 2009
5. Conclusion
This document describes why a third-party ALTO server discovery
mechanism is required for an important class of applications, namely
tracker-based P2P applications. Several solution approaches are
classified and evaluated. Assuming that ALTO should work together
with already deployed appliction protocols, "Approach #1" seems to be
most promising. In this approach, the resource directory invokes a
discovery mechanism external to the ALTO client protocol, in order to
map from the resource consumer's IP address to the "right" ALTO
server.
The existence of such a mechanism according to "Approach #1" is
assumed by [I-D.penno-alto-protocol].
Further action is required to standardize a protocol and procedures
according to "Approach #1".
Kiesel & Tomsu Expires February 27, 2010 [Page 10]
Internet-Draft Third-party ALTO server discovery August 2009
6. IANA Considerations
This document does not mandate any immediate IANA actions. However,
such IANA considerations may arise from future ALTO discovery
specification documents which try to meet the requirements given
here.
Kiesel & Tomsu Expires February 27, 2010 [Page 11]
Internet-Draft Third-party ALTO server discovery August 2009
7. Security Considerations
This initial version of this memo does not yet have any security
considerations, but they will be added in future revision.
Kiesel & Tomsu Expires February 27, 2010 [Page 12]
Internet-Draft Third-party ALTO server discovery August 2009
8. Informative References
[I-D.ietf-alto-problem-statement]
Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement",
draft-ietf-alto-problem-statement-02 (work in progress),
July 2009.
[I-D.ietf-alto-reqs]
Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.
Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-01 (work in progress),
July 2009.
[I-D.penno-alto-protocol]
Penno, R. and Y. Yang, "ALTO Protocol",
draft-penno-alto-protocol-03 (work in progress),
July 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.
Kiesel & Tomsu Expires February 27, 2010 [Page 13]
Internet-Draft Third-party ALTO server discovery August 2009
Appendix A. Acknowledgments
The authors would like to thank Haibin Song, Richard Alimi, and Roni
Even for fruitful discussions during the 75th IETF meeting.
Sebastian Kiesel 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.
Marco Tomsu is partially supported by the 4WARD project
(http://www.4ward-project.eu), a research project supported by the
European Commission under its 7th Framework Program (contract no.
216041). 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 4WARD project or the European Commission.
Kiesel & Tomsu Expires February 27, 2010 [Page 14]
Internet-Draft Third-party ALTO server discovery August 2009
Authors' Addresses
Sebastian Kiesel
NEC Laboratories Europe
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Email: kiesel@nw.neclab.eu
URI: http://www.nw.neclab.eu/
Marco Tomsu
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: marco.tomsu@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs
Kiesel & Tomsu Expires February 27, 2010 [Page 15]