ALTO S. Kiesel
Internet-Draft University of Stuttgart
Intended status: Standards Track July 5, 2010
Expires: January 6, 2011
Using ALTO for ALTO server selection
draft-kiesel-alto-alto4alto-00
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. Entities seeking guidance need to discover and possibly
select an ALTO server to ask.
This document proposes an ALTO-based scheme to select an ALTO server
that can give guidance to a given ALTO client. Unlike some other
proposed ALTO discovery mechanisms, this solution works well if the
client seeks guidance from a set of ALTO servers that are operated by
an entity which is not the operator of the access network.
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 January 6, 2011.
Copyright Notice
Kiesel Expires January 6, 2011 [Page 1]
Internet-Draft Using ALTO for ALTO server selection July 2010
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Kiesel Expires January 6, 2011 [Page 2]
Internet-Draft Using ALTO for ALTO server selection July 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.
Before sending these queries, ALTO clients need to discover and
possibly select an appropriate destination ALTO server.
The ALTO requirements document [I-D.ietf-alto-reqs] states two
requirements that have an important impact on the ALTO server
discovery mechanism:
REQ. ARv05-23: The ALTO client protocol MUST be designed in a way
that the ALTO service can be provided by an entity which is not the
operator of the IP access network.
REQ. ARv05-24: The ALTO client protocol MUST be designed in a way
that different instances of the ALTO service operated by different
providers can coexist.
The rationale behind these requirements are trust issues. Users may
fear that the "official" ALTO service provided by their respective
access network operator only optimizes traffic costs for the operator
while penalizing performance. Therefore, users may prefer to seek
guidance from an "independent" entity providing ALTO service, e.g.,
based on performance-related measurements.
Simple ALTO server discovery mechanisms, such as having the network
operator provide the ALTO server names (or IP addresses) by means of
a DHCP option, are not in line with these requirements, as the user
cannot influence the selection and switch to an independent entity's
ALTO servers.
Giving the user the ability to configure the name (or IP address) of
an ALTO server in the ALTO client would solve this problem. However,
it is not a good solution, either: providers of ALTO service may wish
to operate several regional ALTO servers, each being able to give
guidance only to ALTO clients in its respective (topological)
vicinity. Requiring the user to know the "best" ALTO server for his
client's topological position would be an inacceptable burden. On
the other hand, selecting the "best" server for a given client is
very similar (see remark below) to the problem ALTO tries to solve.
Therefore, we propose an ALTO-based scheme for selecting an ALTO
server.
Remark: in the normal mode of operation, ALTO gives guidance on
Kiesel Expires January 6, 2011 [Page 3]
Internet-Draft Using ALTO for ALTO server selection July 2010
selecting among providers of an identical (copy of a) resource, based
on connectivity-related parameters. Here, in contrast, ALTO would
give guidance on selecting the best resource (i.e., ALTO server that
can give guidance to the client). Giving guidance based on
application knowledge is beyond the scope of ALTO for the general
case with arbitrary applications. However, in this special case
where the application is ALTO, this approach seem feasible.
Comments and discussions about this document should be directed to
the ALTO working group: alto@ietf.org.
Kiesel Expires January 6, 2011 [Page 4]
Internet-Draft Using ALTO for ALTO server selection July 2010
2. Terminology
This document uses the terminology introduced in [RFC5693].
Furthermore, we define the term "ALTO service instance" as the ALTO
service that is provided by one (legal) entity, such as a network
operator, a CDN operator, an "independent" organization, etc. This
ALTO service instance is provided by one or more ALTO servers, which
are under the control of this entity. It is assumed that several
ALTO service instance can coexist (see ARv05-24) and users should be
able to select which ALTO service instance to ask for guidance.
Kiesel Expires January 6, 2011 [Page 5]
Internet-Draft Using ALTO for ALTO server selection July 2010
3. Proposed Solution
The proposed solution requires 3 steps:
Step 1 Get complete list of all ALTO servers that belong to the
desired ALTO service instance.
Thereto, ask user (may be a configuration file item, etc.) for the
URI of a file with a list of addresses of all ALTO servers that
constitute the desired ALTO service instance. If the user has no
specific wish, use as default choice the ALTO service provided by
his access network operator.
Because the ALTO client protocol [I-D.ietf-alto-protocol] itself
is HTTP based, and because of the close interaction with Step 2 it
seems advisable to host the abovementioned URI on an ALTO server.
TBD: specify automatic retrieval of addresses for the default
choice, maybe similar to the mechanism described in BEP 22
[bep22].
Step 2 Ask for ALTO guidance on that list.
Randomly select an ALTO server from the list. Ask for guidance,
specify "ALTO server guidance quality" as the rating criterion.
It is assumed that every ALTO server on the list knows the
competences (wrt. giving guidance to specific clients) of all ALTO
servers on the list. That is, we assume that every ALTO server in
one ALTO service instance can give guidance on which ALTO server
from the same ALTO service instance can give the best guidance to
a given client, for arbitrary ALTO queries.
Step 3 Ask the recommended ALTO servers for guidance with respect to
the resource provider selection the actual user application needs
to make.
Kiesel Expires January 6, 2011 [Page 6]
Internet-Draft Using ALTO for ALTO server selection July 2010
4. IANA Considerations
This document proposes a new ALTO rating criterion "ALTO server
guidance quality". The ALTO requirements document mandates a
registration procedure for such new rating criteria. However, at
this point in time it is unclear how these procedures will look like.
If they will be implemented by an IANA registry, the proposed rating
criterion will have to be registered there.
Kiesel Expires January 6, 2011 [Page 7]
Internet-Draft Using ALTO for ALTO server selection July 2010
5. Security Considerations
This early version of this memo does not yet have any security
considerations, but they will be added in future revision.
Kiesel Expires January 6, 2011 [Page 8]
Internet-Draft Using ALTO for ALTO server selection July 2010
6. References
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-04 (work in progress), May 2010.
[I-D.ietf-alto-reqs]
Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-05 (work in progress),
June 2010.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[bep22] Harrison, D., Shalunov, S., and G. Greg Hazel, "BitTorrent
Local Tracker Discovery Protocol",
BEP http://bittorrent.org/beps/bep_0022.html.
Kiesel Expires January 6, 2011 [Page 9]
Internet-Draft Using ALTO for ALTO server selection July 2010
Author's Address
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/
Kiesel Expires January 6, 2011 [Page 10]