idnits 2.17.1 draft-kiesel-alto-alto4alto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 85: '... client protocol MUST be designed in a...' RFC 2119 keyword, line 89: '... client protocol MUST be designed in a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2010) is 5038 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-04 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-05 ** Downref: Normative reference to an Informational draft: draft-ietf-alto-reqs (ref. 'I-D.ietf-alto-reqs') ** Downref: Normative reference to an Informational RFC: RFC 5693 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO S. Kiesel 3 Internet-Draft University of Stuttgart 4 Intended status: Standards Track July 5, 2010 5 Expires: January 6, 2011 7 Using ALTO for ALTO server selection 8 draft-kiesel-alto-alto4alto-00 10 Abstract 12 The goal of Application-Layer Traffic Optimization (ALTO) is to 13 provide guidance to applications, which have to select one or several 14 hosts from a set of candidates that are able to provide a desired 15 resource. Entities seeking guidance need to discover and possibly 16 select an ALTO server to ask. 18 This document proposes an ALTO-based scheme to select an ALTO server 19 that can give guidance to a given ALTO client. Unlike some other 20 proposed ALTO discovery mechanisms, this solution works well if the 21 client seeks guidance from a set of ALTO servers that are operated by 22 an entity which is not the operator of the access network. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 6, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 The goal of Application-Layer Traffic Optimization (ALTO) is to 74 provide guidance to applications, which have to select one or several 75 hosts from a set of candidates, that are able to provide a desired 76 resource. ALTO is realized by a client-server protocol. ALTO 77 clients send queries to ALTO servers, in order to solicit guidance. 78 Before sending these queries, ALTO clients need to discover and 79 possibly select an appropriate destination ALTO server. 81 The ALTO requirements document [I-D.ietf-alto-reqs] states two 82 requirements that have an important impact on the ALTO server 83 discovery mechanism: 85 REQ. ARv05-23: The ALTO client protocol MUST be designed in a way 86 that the ALTO service can be provided by an entity which is not the 87 operator of the IP access network. 89 REQ. ARv05-24: The ALTO client protocol MUST be designed in a way 90 that different instances of the ALTO service operated by different 91 providers can coexist. 93 The rationale behind these requirements are trust issues. Users may 94 fear that the "official" ALTO service provided by their respective 95 access network operator only optimizes traffic costs for the operator 96 while penalizing performance. Therefore, users may prefer to seek 97 guidance from an "independent" entity providing ALTO service, e.g., 98 based on performance-related measurements. 100 Simple ALTO server discovery mechanisms, such as having the network 101 operator provide the ALTO server names (or IP addresses) by means of 102 a DHCP option, are not in line with these requirements, as the user 103 cannot influence the selection and switch to an independent entity's 104 ALTO servers. 106 Giving the user the ability to configure the name (or IP address) of 107 an ALTO server in the ALTO client would solve this problem. However, 108 it is not a good solution, either: providers of ALTO service may wish 109 to operate several regional ALTO servers, each being able to give 110 guidance only to ALTO clients in its respective (topological) 111 vicinity. Requiring the user to know the "best" ALTO server for his 112 client's topological position would be an inacceptable burden. On 113 the other hand, selecting the "best" server for a given client is 114 very similar (see remark below) to the problem ALTO tries to solve. 115 Therefore, we propose an ALTO-based scheme for selecting an ALTO 116 server. 118 Remark: in the normal mode of operation, ALTO gives guidance on 119 selecting among providers of an identical (copy of a) resource, based 120 on connectivity-related parameters. Here, in contrast, ALTO would 121 give guidance on selecting the best resource (i.e., ALTO server that 122 can give guidance to the client). Giving guidance based on 123 application knowledge is beyond the scope of ALTO for the general 124 case with arbitrary applications. However, in this special case 125 where the application is ALTO, this approach seem feasible. 127 Comments and discussions about this document should be directed to 128 the ALTO working group: alto@ietf.org. 130 2. Terminology 132 This document uses the terminology introduced in [RFC5693]. 134 Furthermore, we define the term "ALTO service instance" as the ALTO 135 service that is provided by one (legal) entity, such as a network 136 operator, a CDN operator, an "independent" organization, etc. This 137 ALTO service instance is provided by one or more ALTO servers, which 138 are under the control of this entity. It is assumed that several 139 ALTO service instance can coexist (see ARv05-24) and users should be 140 able to select which ALTO service instance to ask for guidance. 142 3. Proposed Solution 144 The proposed solution requires 3 steps: 146 Step 1 Get complete list of all ALTO servers that belong to the 147 desired ALTO service instance. 149 Thereto, ask user (may be a configuration file item, etc.) for the 150 URI of a file with a list of addresses of all ALTO servers that 151 constitute the desired ALTO service instance. If the user has no 152 specific wish, use as default choice the ALTO service provided by 153 his access network operator. 155 Because the ALTO client protocol [I-D.ietf-alto-protocol] itself 156 is HTTP based, and because of the close interaction with Step 2 it 157 seems advisable to host the abovementioned URI on an ALTO server. 159 TBD: specify automatic retrieval of addresses for the default 160 choice, maybe similar to the mechanism described in BEP 22 161 [bep22]. 163 Step 2 Ask for ALTO guidance on that list. 165 Randomly select an ALTO server from the list. Ask for guidance, 166 specify "ALTO server guidance quality" as the rating criterion. 168 It is assumed that every ALTO server on the list knows the 169 competences (wrt. giving guidance to specific clients) of all ALTO 170 servers on the list. That is, we assume that every ALTO server in 171 one ALTO service instance can give guidance on which ALTO server 172 from the same ALTO service instance can give the best guidance to 173 a given client, for arbitrary ALTO queries. 175 Step 3 Ask the recommended ALTO servers for guidance with respect to 176 the resource provider selection the actual user application needs 177 to make. 179 4. IANA Considerations 181 This document proposes a new ALTO rating criterion "ALTO server 182 guidance quality". The ALTO requirements document mandates a 183 registration procedure for such new rating criteria. However, at 184 this point in time it is unclear how these procedures will look like. 185 If they will be implemented by an IANA registry, the proposed rating 186 criterion will have to be registered there. 188 5. Security Considerations 190 This early version of this memo does not yet have any security 191 considerations, but they will be added in future revision. 193 6. References 195 [I-D.ietf-alto-protocol] 196 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 197 draft-ietf-alto-protocol-04 (work in progress), May 2010. 199 [I-D.ietf-alto-reqs] 200 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 201 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 202 Requirements", draft-ietf-alto-reqs-05 (work in progress), 203 June 2010. 205 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 206 Optimization (ALTO) Problem Statement", RFC 5693, 207 October 2009. 209 [bep22] Harrison, D., Shalunov, S., and G. Greg Hazel, "BitTorrent 210 Local Tracker Discovery Protocol", 211 BEP http://bittorrent.org/beps/bep_0022.html. 213 Author's Address 215 Sebastian Kiesel 216 University of Stuttgart Computing Center 217 Allmandring 30 218 Stuttgart 70550 219 Germany 221 Email: ietf-alto@skiesel.de 222 URI: http://www.rus.uni-stuttgart.de/nks/