ALTO S. Kiesel
Internet-Draft University of Stuttgart
Intended status: Informational M. Tomsu
Expires: September 9, 2010 N. Schwan
M. Scharf
Alcatel-Lucent Bell Labs
March 8, 2010
Third-party ALTO server discovery
draft-kiesel-alto-3pdisc-02
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.
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.
Kiesel, et al. Expires September 9, 2010 [Page 1]
Internet-Draft Third-party ALTO server discovery March 2010
Copyright Notice
Copyright (c) 2010 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
(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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The need for third-party ALTO queries . . . . . . . . . . 4
2.2. The need for third-party ALTO server discovery . . . . . . 6
3. Peer-to-peer application scenario . . . . . . . . . . . . . . 8
4. Classification of solution approaches . . . . . . . . . . . . 10
4.1. Solutions that do not require an update of the
application protocol . . . . . . . . . . . . . . . . . . . 10
4.2. Solutions that do require an update of the application
protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Approach #1 . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Approach #2 . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Approach #3 . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Approach #4 . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Approach #5 . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Approach #6 . . . . . . . . . . . . . . . . . . . . . . . 17
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Kiesel, et al. Expires September 9, 2010 [Page 2]
Internet-Draft Third-party ALTO server discovery March 2010
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. In
some specific peer-to-peer application protocols these resource
directories are called "trackers". ALTO queries, which are issued by
a resource directory on behalf of a resource consumer, will be
referred 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 [RFC5693] 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, et al. Expires September 9, 2010 [Page 3]
Internet-Draft Third-party ALTO server discovery March 2010
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
("peer") asks the resource directory for a list of candidate 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.
Several ALTO client protocol proposals exist (e.g.,
[I-D.ietf-alto-protocol], [I-D.kiesel-alto-h12]), which specify how
an ALTO client can query an ALTO server for guiding information and
receive the corresponding replies. However, in the considered
scenario of a tracker-based P2P application, there are two
fundamentally different possibilities where to place the ALTO client:
1. ALTO client in the resource consumer ("peer")
2. ALTO client in the resource directory ("tracker")
In the following, both scenarios are compared in order to explain the
need for third-party ALTO queries.
In the first scenario (see Figure 1), the resource consumer queries
the resource directory for the desired resource (F1). The resource
directory returns a list of potential resource providers without
considering ALTO (F2). It is then the duty of the resource consumer
to invoke ALTO (F3/F4), in order to solicit guidance regarding this
list.
In the second scenario (see Figure 2), the resource directory has an
embedded ALTO client, which we will refer to as RDAC in this
document. After receiving a query for a given resource (F1) the
resource directory invokes the RDAC to evaluate all resource
providers it knows (F2/F3). Then it returns a, possibly shortened,
list containing the "best" resource providers to the resource
consumer (F4).
Kiesel, et al. Expires September 9, 2010 [Page 4]
Internet-Draft Third-party ALTO server discovery March 2010
Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| F2 Tracker reply | |
|<======================| |
| F3 ALTO client protocol query |
|---------------------------------------------->|
| F4 ALTO client protocol reply |
|<----------------------------------------------|
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
Figure 1: Basic message sequence chart for resource consumer-
initiated ALTO query
Peer Tracker w. RDAC ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| | F2 ALTO cli. p. query |
| |---------------------->|
| | F3 ALTO cli. p. reply |
| |<----------------------|
| F4 Tracker reply | |
|<======================| |
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
Figure 2: Basic message sequence chart for third-party ALTO query
Note: the message sequences depicted in Figure 1 and Figure 2 may
occur both in the target-aware and the target-independent query mode
(c.f. [I-D.ietf-alto-reqs]). In the target-independent query mode
no message exchange with the ALTO server might be needed after the
tracker query, because the candidate resource providers could be
evaluated using a locally cached "map", which has been retrieved from
the ALTO server some time ago.
The problem with the first 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)
Kiesel, et al. Expires September 9, 2010 [Page 5]
Internet-Draft Third-party ALTO server discovery March 2010
potential resource providers might not be contained in that list
anymore, even before ALTO can consider them.
For example, consider a swarm with 10,000 peers known to the tracker.
A new peer wants to join the swarm and therefore asks the tracker for
a list of peers. For simplicity, we assume that 100 peers would be
desirable neighbors for the new peer (in the sense of better-than-
random peer selection) while the other 9,900 are less favorable.
Assume that the tracker randomly selects 100 peers out of the 10,000
known peers and returns them to the new peer. With a probability of
approx. 36% this list does not contain a single favorable peer, and
with 99% probability there are only four or less of the favorable
peers on the list. Processing this list with the guiding ALTO
information will ensure that the few favorable peers are ranked to
the top of the list; however, the benefit is rather limited as the
number of favorable peers in the list is just too small. Much better
traffic optimization could be achieved if the tracker would evaluate
all 10,000 peers using ALTO, and return a list of 100 peers
afterwards. This list would then include a significantly higher
fraction of favorable peers. (Note, that if the tracker returned
favorable peers only, there would be a risk that the swarm might
disconnect and split into several partitions. However, finding the
right mix of ALTO-biased and random peer selection is out of the
scope of this document.)
Therefore, from an overall optimization perspective, the second
scenario with the ALTO client embedded in the resource directory 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.
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.
One potential 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,
respectively. Directing a third-party ALTO query to one of these
Kiesel, et al. Expires September 9, 2010 [Page 6]
Internet-Draft Third-party ALTO server discovery March 2010
servers would be a rather simple task.
However, it is likely that there will be deployment 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.
We will identify and assess several approaches for finding the
"right" ALTO server, which has the knowledge to give guidance to the
resource consumer on behalf of which a third-party ALTO query is to
be sent.
Kiesel, et al. Expires September 9, 2010 [Page 7]
Internet-Draft Third-party ALTO server discovery March 2010
3. Peer-to-peer application scenario
For illustration purposes the following chapters provide several
examples, which all refer to the scenario presented in Figure 3.
However, the evaluations and conclusions presented in this document
do not only consider this scenario, but they are much more general.
+------+ +---------+
| ALTO |---+---| Tracker |
| Srv3 | | +---------+
+------+ |
|RTR| ISP 3
|
**** | ***********
*** ********************** *******
* Internet Backbone Networks *
*************** ******************
| ****** ** |
|RTR| ISP 1 ****** |RTR| ISP 2
| | +------+
+-------+ | +------+ +--------| ALTO |
|Peer 1a|----+---| ALTO | | | Srv2 |
+-------+ | | Srv1 | |NAT| +------+
| +------+ |
+-------+ | +-------+ | +---------+
|Peer 1b|----+ |Peer 2a|----+------|ConfigSrv|
+-------+ | +-------+ | +---------+
|RTR| |
+-------+ | +-------+ | +-------+
|Peer 1c|----+ |Peer 2b|----+-|RTR|--|Peer 2c|
+-------+ +-------+ +-------+
Figure 3: ALTO scenario
Figure 3 shows three networks with connected end hosts, which are
operated by different Internet Service Provides, identified as ISP1,
ISP2, and ISP3, respectively. These networks are interconnected by
Internet backbone networks.
ISP1's network connects to (amongst others) three hosts that run the
peers of a P2P application, identified as peers 1a, 1b, and 1c,
respectively. Peers 1a and 1b are in topological vicinity, while 1c
is more distant from them, because of the additional router (RTR) in
between. ISP1 operates an ALTO server, identified as ALTO Srv1,
which can give guidance to resource consumers in ISP1's network,
i.e., to peers 1a, 1b, and 1c.
Kiesel, et al. Expires September 9, 2010 [Page 8]
Internet-Draft Third-party ALTO server discovery March 2010
ISP2's network has a very similar structure as described above, and
it contains peers 2a, 2b, and 2c, as well as ALTO Srv2. The main
difference to ISP1's network is that ISP2 uses a carrier grade NAT
device, in order to masquerade peers 2a, 2b, and 2c "behind" one
single "external" (globally unique) IPv4 address. ALTO server 2 is
assumed to have a globally unique IPv4 address, i.e., it can be
queried from other hosts in the Internet without any special NAT
traversal mechanisms.
ISP3's network contains a resource directory ("tracker") for a
tracker-based P2P application. ISP3 operates ALTO Srv3, which is
populated with information that could be used for giving guidance to
resource consumers in ISP3's network.
We assume that the tracker already knows that peers 1b, 1c, 2b, and
2c are taking part in a specific P2P overlay. If peer 1a wishes to
join the overlay, it sends an application protocol specific message
to the tracker, asking for other peer's addresses. Because of the
reasons outlined in Section 2.1 the tracker should ask ALTO for
guidance prior to replying. More specifically, it should query ALTO
server 1, because this ALTO server can give guidance to peer 1a.
Analogical to that, if peer 2a sends a query to the tracker, the
tracker needs to ask ALTO server 2 for guidance. The procedures for
identifying this ALTO server and conveying the guiding information to
the tracker are the scope of this document.
Kiesel, et al. Expires September 9, 2010 [Page 9]
Internet-Draft Third-party ALTO server discovery March 2010
4. 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.
4.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 resource 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 (see Figure 4).
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
forwards (see Figure 5) or redirects (see Figure 6) the query to
the "right" ALTO server. This implies that ALTO servers must know
each other, based on some discovery mechanism or manual
configuration.
Kiesel, et al. Expires September 9, 2010 [Page 10]
Internet-Draft Third-party ALTO server discovery March 2010
Peer 1a Tracker ALTO Srv1 DNS
----+---- ----+---- ----+---- ----+----
| | | |
| F1 Tracker Q | | |
|==============>| F2 ALTO disc. Q (peer1a) |
| |******************************>|
| | F3 ALTO disc. R: ALTO Srv1 |
| |<******************************|
| | F4 ALTO cp Q | |
| |-------------->| |
| | F5 ALTO cp R | |
| F6 Tracker R |<--------------| |
|<==============| | |
| | | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
**** ALTO discovery protocol (e.g., based on DNS queries)
Figure 4: Message sequence chart for Approach 1
Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3
----+---- ----+---- ----+---- ----+---- ----+----
| | | F1/2 HELLO | |
| | |<###########>| F3/4 HELLO |
| | | F5/6 HELLO |<###########>|
| | |<#########################>|
| F7 Tracker Q | | | |
|==============>| | | |
| | F8 ALTO cp Q | | |
| |------------------------------------------>|
| | | F9 ALTO cp Q |
| | |<--------------------------|
| | | F10 ALTO cp R |
| | |-------------------------->|
| | F11 ALTO cp R | | |
| F12 Tracker R |<------------------------------------------|
|<==============| | | |
| | | | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
#### Inter-ALTO server protocol
Figure 5: Message sequence chart for Approach 2 (query forwarding)
Kiesel, et al. Expires September 9, 2010 [Page 11]
Internet-Draft Third-party ALTO server discovery March 2010
Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3
----+---- ----+---- ----+---- ----+---- ----+----
| | | F1/2 HELLO | |
| | |<###########>| F3/4 HELLO |
| | | F5/6 HELLO |<###########>|
| | |<#########################>|
| F7 Tracker Q | | | |
|==============>| | | |
| | F8 ALTO cp Q | | |
| |------------------------------------------>|
| | F9 ALTO cp redirect | |
| |<------------------------------------------|
| | F10 ALTO cp Q | | |
| |-------------->| | |
| | F11 ALTO cp R | | |
| F12 Tracker R |<--------------| | |
|<==============| | | |
| | | | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
#### Inter-ALTO server protocol
Figure 6: Message sequence chart for Approach 2 (query redirection)
4.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.
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 in addition to or instead of the
resource consumer's IP address (see Figure 7). 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
Kiesel, et al. Expires September 9, 2010 [Page 12]
Internet-Draft Third-party ALTO server discovery March 2010
there.
o Approach #6: The resource consumer retrieves guiding information
on its own, e.g., by discovering and querying an ALTO server or by
doing measurements. Using the extended application protocol it
sends this information to the tracker, which can perform peer
selection based on it.
Peer 2a ConfigSrv Tracker ALTO Srv2 DNS
----+---- ----+---- ----+---- ----+---- ----+---
| F1 Config Q | | | |
|;;;;;;;;;;;;;;>| | | |
| | | | |
| F2 Config R | | | |
| + LocalID LID | | | |
|<;;;;;;;;;;;;;;| | | |
| | | | |
| F3 Tracker Q (LID) | | |
|===========================>| F4 ALTO disc. Q (ext.IP+LID) |
| | |******************************>|
| | | F5 ALTO disc. R: ALTO Srv2 |
| | |<******************************|
| | | F6 ALTO cp Q | |
| | |-------------->| |
| | | F7 ALTO cp R | |
| F8 Tracker R | |<--------------| |
|<===========================| | |
| | | | |
;;;; Configuration protocol (e.g., DHCP)
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
**** ALTO discovery protocol (e.g., based on DNS queries)
Figure 7: Message sequence chart for Approach 3
Kiesel, et al. Expires September 9, 2010 [Page 13]
Internet-Draft Third-party ALTO server discovery March 2010
Peer 2a ConfigSrv Tracker ALTO Srv2
----+---- ----+---- ----+---- ----+----
| F1 Config Q | | |
|;;;;;;;;;;;;;;>| | |
| | | |
| F2 Config R | | |
| + Addr. of ALTO Srv2 | |
|<;;;;;;;;;;;;;;| | |
| | | |
| F3 Tracker Q (Addr. of ALTO Srv2) |
|==============================>| |
| | | F4 ALTO cp Q |
| | |-------------->|
| | | F5 ALTO cp R |
| F6 Tracker R | |<--------------|
|<==============================| |
| | | |
;;;; Configuration protocol (e.g., DHCP)
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
Figure 8: Message sequence chart for Approach 5
Kiesel, et al. Expires September 9, 2010 [Page 14]
Internet-Draft Third-party ALTO server discovery March 2010
Peer 2a ConfigSrv Tracker ALTO Srv2
----+---- ----+---- ----+---- ----+----
| F1 Config Q | | |
|;;;;;;;;;;;;;;>| | |
| | | |
| F2 Config R | | |
| + Addr. of ALTO Srv2 | |
|<;;;;;;;;;;;;;;| | |
| | | |
| F3 ALTO cp Q | | |
|---------------------------------------------->|
| F4 ALTO cp R | | |
|<----------------------------------------------|
optional: perform | | |
measurements | | |
| | | |
| F5 Tracker Q (Info from ALTO reply + meas'mt.)|
|==============================>| |
| F6 Tracker R | | |
|<==============================| |
| | | |
;;;; Configuration protocol (e.g., DHCP)
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO client protocol
Figure 9: Message sequence chart for Approach 6
Kiesel, et al. Expires September 9, 2010 [Page 15]
Internet-Draft Third-party ALTO server discovery March 2010
5. 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.
5.1. Approach #1
The existence of a mechanism according to approach #1 is assumed by
[I-D.ietf-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.
5.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.
5.3. Approach #3
This approach requires changes to all existing (P2P) application
protocols that want to benefit from ALTO.
Kiesel, et al. Expires September 9, 2010 [Page 16]
Internet-Draft Third-party ALTO server discovery March 2010
This approach supports intra-domain traffic optimization for large
domains behind a NAT.
Except for the above mentioned statements, the same results as for
approach #1 apply.
5.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 above mentioned statements, the same results as for
approach #2 apply.
5.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].
Unlike approaches #1 .. #4 this approach supports scenarios, in which
there is not exactly one "right" ALTO server for any given resource
consumer. Instead of sending the address of the ALTO server
provisioned by the ISP, the resource consumer can also send the
address of another ALTO server of its choice to the RDAC.
5.6. Approach #6
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].
Unlike approaches #1 .. #4 this approach supports scenarios, in which
there is not exactly one "right" ALTO server for any given resource
consumer. Instead of querying the ALTO server provisioned by the ISP
and forwarding that information to the resource directory, the
resource consumer can also query any other ALTO server of its choice.
Kiesel, et al. Expires September 9, 2010 [Page 17]
Internet-Draft Third-party ALTO server discovery March 2010
This approach allows the resource consumer to augment the ALTO
server's reply with local preferences (e.g., from measurements). It
is also possible not to query an ALTO server at all.
Kiesel, et al. Expires September 9, 2010 [Page 18]
Internet-Draft Third-party ALTO server discovery March 2010
6. 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 application 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.ietf-alto-protocol].
Further action is required to standardize a protocol and procedures
according to "Approach #1".
Kiesel, et al. Expires September 9, 2010 [Page 19]
Internet-Draft Third-party ALTO server discovery March 2010
7. 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, et al. Expires September 9, 2010 [Page 20]
Internet-Draft Third-party ALTO server discovery March 2010
8. Security Considerations
This early version of this memo does not yet have any security
considerations, but they will be added in future revision.
Kiesel, et al. Expires September 9, 2010 [Page 21]
Internet-Draft Third-party ALTO server discovery March 2010
9. References
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-02 (work in progress),
March 2010.
[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-03 (work in progress),
February 2010.
[I-D.kiesel-alto-h12]
Kiesel, S. and M. Stiemerling, "ALTO H12",
draft-kiesel-alto-h12-01 (work in progress), March 2010.
[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.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
Kiesel, et al. Expires September 9, 2010 [Page 22]
Internet-Draft Third-party ALTO server discovery March 2010
Appendix A. Acknowledgments
The authors would like to thank Haibin Song, Richard Alimi, and Roni
Even for fruitful discussions during the 75th IETF meeting.
Marco Tomsu and Nico Schwan are partially supported by the ENVISION
project (http://www.envision-project.org), a research project
supported by the European Commission under its 7th Framework Program
(contract no. 248565). 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 ENVISION project or the European Commission.
Michael Scharf is supported by the German-Lab project
(http://www.german-lab.de) funded by the German Federal Ministry of
Education and Research (BMBF).
Kiesel, et al. Expires September 9, 2010 [Page 23]
Internet-Draft Third-party ALTO server discovery March 2010
Authors' Addresses
Sebastian Kiesel
University of Stuttgart Computing Center
Allmandring 30
Stuttgart 70550
Germany
Email: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/
Marco Tomsu
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: marco.tomsu@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs
Nico Schwan
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: nico.schwan@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs
Michael Scharf
Alcatel-Lucent Bell Labs
Lorenzstrasse 10
Stuttgart 70435
Germany
Email: michael.scharf@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs
Kiesel, et al. Expires September 9, 2010 [Page 24]