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 <mailto: p2pi@ietf.org> 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]