idnits 2.17.1 draft-saucez-alto-generalized-alto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 262 has weird spacing: '...t-Draft draft...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2008) is 5771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-marocco-alto-problem-statement-01 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-07 == Outdated reference: A later version (-01) exists of draft-saucez-idips-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Saucez 3 Internet-Draft Universite catholique de Louvain 4 Intended status: Informational D. Papadimitriou 5 Expires: January 8, 2009 Alcatel Bell 6 July 7, 2008 8 Why should the Traffic Optimization not be restricted to the 9 Application-Layer? 10 draft-saucez-alto-generalized-alto-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 8, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The Application-Layer Traffic Optimization (ALTO) problem is being 44 discussed within the IETF and more globally by the research community 45 and some enterprises. In this memo, we argue that it is important to 46 conceive general-purpose mechanisms to solve this problem. By 47 general-purpose we say not only application independent but also 48 layer independent mechanism. The generality can be obtained because 49 the underlying problem is the same regardless the application or the 50 layer. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Generalize ALTO to a generic traffic optimization problem . . . 3 56 3. Application-Network Cooperation for Generic Path Selection . . 4 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 58 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . . . 8 63 1. Introduction 65 The Application-Layer Traffic Optimization (ALTO) topic is being 66 discussed within the IETF and more globally by the research community 67 and some enterprises. As described in [1], traditional techniques to 68 solve the problem are network coordinate systems, path selection 69 algorithms or cross layer cooperation. We could also add the use of 70 looking glasses or host active probing like traceroutes. 72 In this memo, we argue that it is important to conceive general- 73 purpose mechanisms for traffic optimization as discussed on the P2Pi 74 mailing list By general-purpose we say not 75 only application independent but also layer independent mechanism. 76 The generality can be obtained because the underlying problem is the 77 same regardless the application or the layer. 79 This mechanism can be conceived as a generic service that works in 80 any context requiring a path selection so as to better suits both 81 applicative needs and service provider needs. Such distributed path 82 selection service would be queried by hosts and would allow ranking 83 paths based on policies and performance metrics defined by the 84 network operator to meet its objectives, e.g. in terms of traffic 85 engineering. The introduction of such service requires minimal 86 changes into the service providers network architecture. 88 Thus, we also argue that making both applications and service 89 providers cooperating for the path selection process can lead to a 90 win-win situation as both will meet their requirements. 92 2. Generalize ALTO to a generic traffic optimization problem 94 Instead of solving the ALTO problem for P2P as proposed by [1], we 95 suggest to open the discussion to the traffic optimization problem in 96 general (i.e., ALTO become TO). Indeed, we believe that the traffic 97 optimization is not restricted to P2P and that the community should 98 focus on a way to optimize traffic regardless of the traffic purpose. 100 Furthermore, traffic optimization in P2P mostly comes from the 101 multiplicity of peers providing a given content. Multiply the peers 102 often mean multiply the network paths to get a content and different 103 paths give different performances (for any definition of performance 104 like bw or cost). This problem also exists for FTP replicas, HTTP 105 replicas or any CDN. In addition, the same issue appears in lower- 106 layers. For instance, for dual-stack hosts, the choice of IPv6 107 instead IPv4 can dramatically influence the traffic performances [2]. 108 Moreover, the Locator Identifiers Separation Protocol (LISP) [3] 109 allows to associate several locators to an identifier leading to the 110 possibility to optimize traffic by selecting the best locator. A 111 more precise description of the generalization problem can be found 112 in [4]. 114 The key point in IP flow traffic optimization is the path selection 115 algorithm. Basically, for a high level definition of a source S and 116 a destination D, at a time T, a good traffic optimizer should be able 117 to influence the path (whatever definition of path) to follow. For 118 peer-to-peer it means selecting a (set of) peer(s) in the swarm. For 119 LISP, it means the selection of a source and a destination locator 120 and for the IPv4 vs IPv6 choice, it means selecting IPv4 instead of 121 IPv6 or vice versa. 123 3. Application-Network Cooperation for Generic Path Selection 125 A generic information path selection aims at simplifying the path 126 selection process while allowing both service providers and 127 applications to meet their requirements (that are initially of 128 different nature e.g. self-fish vs common resource sharing). It is 129 an instantiation of application-network cooperation so as address the 130 traffic optimization objective in scope of ALTO. 132 Such system works as distributed request/response service in which a 133 client sends a request to the service. The service is used to rank 134 path(s) among a set of candidate paths by relying on information that 135 is usually available in ISP network: 137 o Routing information (e.g., BGP, OSPF/ISIS) to compare different 138 paths based on routing metrics but also based on path costs. 140 o Traffic information via e.g. active or passive measurements to 141 compare different paths based on quantitative performance metrics. 143 o Network policies allows for selecting paths based on resource 144 performance metrics. 146 A request will contain one or more source addresses (or prefixes), 147 one or more destination addresses (or prefixes), and a set of 148 criteria. Upon reception of a request, the Path Selection Service 149 builds a list of all the possible paths between the source(s) and the 150 destination(s). It then ranks the remaining paths (using the metrics 151 and policy information). Ranked paths are listed as part of the 152 response to the client. Figure 1 illustrates this request/response 153 path selection service. 155 Routing Traffic 156 | | 157 v v 158 | | 159 Req. ------------ 160 --->---| Path | 161 Client | Selection |--<-- Policy (Network Resource Perf.) 162 ---<---| Service | 163 Resp. | (ranking) | 164 ------------ 166 Path Selection Service Overview 168 Figure 1 170 The noticeable properties of such system are the following: 172 o the service and the protocols it involves are application 173 independent 175 o the resulting path information/ranking keeps the ultimate 176 selection decision at the end-user (the PS system does not 177 arbitrarily constrain but only combines end-users objectives with 178 the network objectives). 180 o the service does not rely on closed loop that would increase 181 global system convergence, as long as it is able to direct the 182 traffic over the selected path and predict the future paths 183 behavior in order to divert traffic to the most appropriated 184 paths. 186 o the information on which the system relies is also application 187 independent. But more importantly neither its obtention or its 188 usage incur any change in the network topology and network 189 properties (scaling, efficiency, security, etc.) and operations 190 Also, it does not impede the organic network deployment nor 191 imposes any centralization of network operations (hence meeting 192 the deployability requirement) 194 Thus, to address a general purpose mechanisms for traffic 195 optimization we believe that the community should make an effort to 196 propose a generic protocol able to give information about paths. 197 First, the protocol should be application independent. This does not 198 mean that the information cannot be related to a particular 199 application but it means that the infrastructure required to provide 200 the information must be able to support any kind of application. 201 Only the way to inject information into the infrastructure can be 202 application related. Second, the protocol should be layer 203 independent. In today's Internet, if an application needs to know 204 the performance of a path, it has to reverse engineer the network. 205 This technique is painful and does often not lead to the optimal 206 solution. The issues comes from the opacity of the lowest layers to 207 the higher layers. Being layer independent should allow layer 208 cooperation and thus fill the gap between the "clients" and the 209 "operators". However, the cooperation must not rely on the 210 dissemination of the exact lower layers to the higher layers but must 211 rely on an abstraction of the different layers information in order 212 to be understandable by any layer without having to know from where 213 comes the information. 215 By construction, the protocol should be able to run at any level and 216 should be operable by the clients themselves, the network providers 217 or any third party. The difference would only be on the accuracy and 218 the granularity of the information provided. [5] and [6] introduce 219 the problem and suggest a first iteration of such a protocol. 221 4. Security Considerations 223 As we propose to influence the paths followed by the traffic, we 224 induce many security concerns (e.g., eavesdropping, DoS, etc). An 225 important effort must therefore be devoted to security when designing 226 such a mechanism. 228 5. Conclusion 230 In this memo, we have seen that the Application-Layer Traffic 231 Optimization can be generalized in a path selection problem. This 232 generalization shows that the problem is not limited to P2P and 233 application-layer but can be extended to any application and any 234 layer. We thus suggest, to design a generic application/layer 235 independent path selection protocol able to tackle the ALTO problem 236 and able to support future traffic and application requirements. 238 6. Informative References 240 [1] Marocco, E. and V. Gurbani, "Application-Layer Traffic 241 Optimization (ALTO) Problem Statement", 242 draft-marocco-alto-problem-statement-01 (work in progress), 243 June 2008. 245 [2] Zhou, X., Jacobsson, M., Uijterwaal, H., and P. Van Mieghem, 246 "IPv6 delay and loss performance evolution", International 247 Journal of Communication Systems DOI: 10.1002/dac.916, 2007. 249 [3] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, "Locator/ID 250 Separation Protocol (LISP)", draft-farinacci-lisp-07 (work in 251 progress), April 2008. 253 [4] Saucez, D., Donnet, B., Bonaventure, O., and D. Papadimitriou, 254 "Towards an Open Path Selection Architecture", Position 255 paper available on http://inl.info.ucl.ac.be/idips, 2008. 257 [5] Bonaventure, O., Saucez, D., and B. Donnet, "The case for an 258 informed path selection service", Internet-Draft 259 draft-bonaventure-informed-path-selection-00, February 2008. 261 [6] Saucez, D., Donnet, B., and O. Bonaventure, "IDIPS : ISP-Driven 262 Informed Path Selection", Internet-Draft draft-saucez-idips-00, 263 February 2008. 265 Authors' Addresses 267 Damien Saucez 268 Universite catholique de Louvain 269 Place Sainte Barbe 2 270 Louvain-la-Neuve, 1348 271 Belgium 273 Email: damien.saucez@uclouvain.be 274 URI: http://inl.info.ucl.ac.be 276 Dimitri Papadimitriou 277 Alcatel Bell 278 Francis Wellesplein 1 279 Antwerpen, 2018 280 Belgium 282 Email: dimitri.papadimitriou@alcatel.be 284 Full Copyright Statement 286 Copyright (C) The IETF Trust (2008). 288 This document is subject to the rights, licenses and restrictions 289 contained in BCP 78, and except as set forth therein, the authors 290 retain all their rights. 292 This document and the information contained herein are provided on an 293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 295 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 296 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 297 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 Intellectual Property 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed to 304 pertain to the implementation or use of the technology described in 305 this document or the extent to which any license under such rights 306 might or might not be available; nor does it represent that it has 307 made any independent effort to identify any such rights. Information 308 on the procedures with respect to rights in RFC documents can be 309 found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use of 314 such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository at 316 http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at 322 ietf-ipr@ietf.org. 324 Acknowledgment 326 Funding for the RFC Editor function is provided by the IETF 327 Administrative Support Activity (IASA).