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]