Internet Engineering Task Force D. Saucez Internet-Draft Universite catholique de Louvain Intended status: Informational D. Papadimitriou Expires: January 8, 2009 Alcatel Bell July 7, 2008 Why should the Traffic Optimization not be restricted to the Application-Layer? draft-saucez-alto-generalized-alto-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 8, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Application-Layer Traffic Optimization (ALTO) problem is being discussed within the IETF and more globally by the research community and some enterprises. In this memo, we argue that it is important to conceive general-purpose mechanisms to solve this problem. By general-purpose we say not only application independent but also layer independent mechanism. The generality can be obtained because Saucez & Papadimitriou Expires January 8, 2009 [Page 1] Internet-Draft Generalize ALTO problem statement July 2008 the underlying problem is the same regardless the application or the layer. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Generalize ALTO to a generic traffic optimization problem . . . 3 3. Application-Network Cooperation for Generic Path Selection . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Saucez & Papadimitriou Expires January 8, 2009 [Page 2] Internet-Draft Generalize ALTO problem statement July 2008 1. Introduction The Application-Layer Traffic Optimization (ALTO) topic is being discussed within the IETF and more globally by the research community and some enterprises. As described in [1], traditional techniques to solve the problem are network coordinate systems, path selection algorithms or cross layer cooperation. We could also add the use of looking glasses or host active probing like traceroutes. In this memo, we argue that it is important to conceive general- purpose mechanisms for traffic optimization as discussed on the P2Pi mailing list By general-purpose we say not only application independent but also layer independent mechanism. The generality can be obtained because the underlying problem is the same regardless the application or the layer. This mechanism can be conceived as a generic service that works in any context requiring a path selection so as to better suits both applicative needs and service provider needs. Such distributed path selection service would be queried by hosts and would allow ranking paths based on policies and performance metrics defined by the network operator to meet its objectives, e.g. in terms of traffic engineering. The introduction of such service requires minimal changes into the service providers network architecture. Thus, we also argue that making both applications and service providers cooperating for the path selection process can lead to a win-win situation as both will meet their requirements. 2. Generalize ALTO to a generic traffic optimization problem Instead of solving the ALTO problem for P2P as proposed by [1], we suggest to open the discussion to the traffic optimization problem in general (i.e., ALTO become TO). Indeed, we believe that the traffic optimization is not restricted to P2P and that the community should focus on a way to optimize traffic regardless of the traffic purpose. Furthermore, traffic optimization in P2P mostly comes from the multiplicity of peers providing a given content. Multiply the peers often mean multiply the network paths to get a content and different paths give different performances (for any definition of performance like bw or cost). This problem also exists for FTP replicas, HTTP replicas or any CDN. In addition, the same issue appears in lower- layers. For instance, for dual-stack hosts, the choice of IPv6 instead IPv4 can dramatically influence the traffic performances [2]. Moreover, the Locator Identifiers Separation Protocol (LISP) [3] allows to associate several locators to an identifier leading to the Saucez & Papadimitriou Expires January 8, 2009 [Page 3] Internet-Draft Generalize ALTO problem statement July 2008 possibility to optimize traffic by selecting the best locator. A more precise description of the generalization problem can be found in [4]. The key point in IP flow traffic optimization is the path selection algorithm. Basically, for a high level definition of a source S and a destination D, at a time T, a good traffic optimizer should be able to influence the path (whatever definition of path) to follow. For peer-to-peer it means selecting a (set of) peer(s) in the swarm. For LISP, it means the selection of a source and a destination locator and for the IPv4 vs IPv6 choice, it means selecting IPv4 instead of IPv6 or vice versa. 3. Application-Network Cooperation for Generic Path Selection A generic information path selection aims at simplifying the path selection process while allowing both service providers and applications to meet their requirements (that are initially of different nature e.g. self-fish vs common resource sharing). It is an instantiation of application-network cooperation so as address the traffic optimization objective in scope of ALTO. Such system works as distributed request/response service in which a client sends a request to the service. The service is used to rank path(s) among a set of candidate paths by relying on information that is usually available in ISP network: o Routing information (e.g., BGP, OSPF/ISIS) to compare different paths based on routing metrics but also based on path costs. o Traffic information via e.g. active or passive measurements to compare different paths based on quantitative performance metrics. o Network policies allows for selecting paths based on resource performance metrics. A request will contain one or more source addresses (or prefixes), one or more destination addresses (or prefixes), and a set of criteria. Upon reception of a request, the Path Selection Service builds a list of all the possible paths between the source(s) and the destination(s). It then ranks the remaining paths (using the metrics and policy information). Ranked paths are listed as part of the response to the client. Figure 1 illustrates this request/response path selection service. Saucez & Papadimitriou Expires January 8, 2009 [Page 4] Internet-Draft Generalize ALTO problem statement July 2008 Routing Traffic | | v v | | Req. ------------ --->---| Path | Client | Selection |--<-- Policy (Network Resource Perf.) ---<---| Service | Resp. | (ranking) | ------------ Path Selection Service Overview Figure 1 The noticeable properties of such system are the following: o the service and the protocols it involves are application independent o the resulting path information/ranking keeps the ultimate selection decision at the end-user (the PS system does not arbitrarily constrain but only combines end-users objectives with the network objectives). o the service does not rely on closed loop that would increase global system convergence, as long as it is able to direct the traffic over the selected path and predict the future paths behavior in order to divert traffic to the most appropriated paths. o the information on which the system relies is also application independent. But more importantly neither its obtention or its usage incur any change in the network topology and network properties (scaling, efficiency, security, etc.) and operations Also, it does not impede the organic network deployment nor imposes any centralization of network operations (hence meeting the deployability requirement) Thus, to address a general purpose mechanisms for traffic optimization we believe that the community should make an effort to propose a generic protocol able to give information about paths. First, the protocol should be application independent. This does not mean that the information cannot be related to a particular application but it means that the infrastructure required to provide the information must be able to support any kind of application. Only the way to inject information into the infrastructure can be application related. Second, the protocol should be layer Saucez & Papadimitriou Expires January 8, 2009 [Page 5] Internet-Draft Generalize ALTO problem statement July 2008 independent. In today's Internet, if an application needs to know the performance of a path, it has to reverse engineer the network. This technique is painful and does often not lead to the optimal solution. The issues comes from the opacity of the lowest layers to the higher layers. Being layer independent should allow layer cooperation and thus fill the gap between the "clients" and the "operators". However, the cooperation must not rely on the dissemination of the exact lower layers to the higher layers but must rely on an abstraction of the different layers information in order to be understandable by any layer without having to know from where comes the information. By construction, the protocol should be able to run at any level and should be operable by the clients themselves, the network providers or any third party. The difference would only be on the accuracy and the granularity of the information provided. [5] and [6] introduce the problem and suggest a first iteration of such a protocol. 4. Security Considerations As we propose to influence the paths followed by the traffic, we induce many security concerns (e.g., eavesdropping, DoS, etc). An important effort must therefore be devoted to security when designing such a mechanism. 5. Conclusion In this memo, we have seen that the Application-Layer Traffic Optimization can be generalized in a path selection problem. This generalization shows that the problem is not limited to P2P and application-layer but can be extended to any application and any layer. We thus suggest, to design a generic application/layer independent path selection protocol able to tackle the ALTO problem and able to support future traffic and application requirements. 6. Informative References [1] Marocco, E. and V. Gurbani, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-marocco-alto-problem-statement-01 (work in progress), June 2008. [2] Zhou, X., Jacobsson, M., Uijterwaal, H., and P. Van Mieghem, "IPv6 delay and loss performance evolution", International Journal of Communication Systems DOI: 10.1002/dac.916, 2007. Saucez & Papadimitriou Expires January 8, 2009 [Page 6] Internet-Draft Generalize ALTO problem statement July 2008 [3] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-07 (work in progress), April 2008. [4] Saucez, D., Donnet, B., Bonaventure, O., and D. Papadimitriou, "Towards an Open Path Selection Architecture", Position paper available on http://inl.info.ucl.ac.be/idips, 2008. [5] Bonaventure, O., Saucez, D., and B. Donnet, "The case for an informed path selection service", Internet-Draft draft-bonaventure-informed-path-selection-00, February 2008. [6] Saucez, D., Donnet, B., and O. Bonaventure, "IDIPS : ISP-Driven Informed Path Selection", Internet-Draft draft-saucez-idips-00, February 2008. Authors' Addresses Damien Saucez Universite catholique de Louvain Place Sainte Barbe 2 Louvain-la-Neuve, 1348 Belgium Email: damien.saucez@uclouvain.be URI: http://inl.info.ucl.ac.be Dimitri Papadimitriou Alcatel Bell Francis Wellesplein 1 Antwerpen, 2018 Belgium Email: dimitri.papadimitriou@alcatel.be Saucez & Papadimitriou Expires January 8, 2009 [Page 7] Internet-Draft Generalize ALTO problem statement July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Saucez & Papadimitriou Expires January 8, 2009 [Page 8]