Internet DRAFT - draft-despotovic-alto-feedback-cp
draft-despotovic-alto-feedback-cp
ALTO Working Group Z. Despotovic, W. Kellerer
Internet Draft DOCOMO Euro-Labs
Intended status: Standards Track S. Spirou
Expires: January 2010 Intracom Telecom
D. Staehle
University of Wuerzburg
M. A. C. Rodriguez
Telefonica I+D
I. Papafili
AUEB
July 6, 2009
ALTO-FCP: Application Layer Traffic Optimization Feedback-Based
Client Protocol
draft-despotovic-alto-feedback-cp-00.txt
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, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
Despotovic, et al. Expires January 6, 2010 [Page 1]
Internet-Draft ALTO-FCP July 2009
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Despotovic, et al. Expires January 6, 2010 [Page 2]
Internet-Draft ALTO-FCP July 2009
Abstract
In some networked applications, such as peer-to-peer file sharing,
the same resource (e.g., a file or a server process) is available at
several potential resource providers. Resource consumers typically
try to select providers so that application performance is improved,
establishing an overlay topology of direct logical links in the
process. However, lack of reliable information about the underlying
network can lead to poor choices and suboptimal application
performance. In addition, resulting application traffic is largely
oblivious to technical, economical, and political constraints at the
network level, causing problems for network operators.
This document describes a protocol that facilitates the exchange of
information between an overlay and the underlying network. Such
information can be used at each layer to make decisions that are not
detrimental to the other layer or, ideally, are beneficial to both.
Despotovic, et al. Expires January 6, 2010 [Page 3]
Internet-Draft ALTO-FCP July 2009
Table of Contents
1. Introduction ................................................ 5
2. Conventions ................................................. 7
3. Architecture ................................................ 8
4. Protocol ................................................... 10
4.1. Messages .............................................. 10
4.1.1. Capabilities ..................................... 10
4.1.2. Guidance ......................................... 11
4.1.3. Evaluation........................................ 12
4.2. Additional capabilities of an ALTO server ............. 13
5. Security Considerations .................................... 14
6. IANA Considerations ........................................ 15
7. References ................................................. 16
7.1. Normative References .................................. 16
7.2. Informative References ................................ 16
8. Acknowledgments ............................................ 17
Despotovic, et al. Expires January 6, 2010 [Page 4]
Internet-Draft ALTO-FCP July 2009
1. Introduction
Overlay Applications such as P2P file sharing and video streaming
generate a significant portion of today's Internet traffic and will
most likely remain dominant consumers of network resources in the
Future Internet as well. Such applications pose a problem for the
network operators (equivalently, Internet service providers - ISPs)
as they do not take into account the underlying network topology in
their overlay connection establishment and overlay routing decisions.
The continuous change of P2P traffic matrices renders such traffic
very expensive for ISPs, since it affects the interconnection
relations with other ISPs. Traditional traffic management approaches
usually fail for P2P traffic, since overlays establish multiple
connections between peers, change their structure dynamically, span
across several ISPs, and masquerade their presence. Facing these
facts, ISPs do whatever they can to lower the costs imposed by P2P
applications. Some of these attempts are not efficient and also not
well received by the public.
Operating an overlay network unaware of the underlying network has
also negative impact on the users of overlay applications. For
example, users of P2P file distribution applications might experience
shorter download times if overlay network connections are established
with the physical network topology in mind. Users of P2P video
streaming applications might experience shorter stall times if
overlay network connections are established along physical links with
shorter delays.
This document assumes a framework where an ALTO Service running in
the network allows both overlay application users and ISPs to benefit
from exchanging relevant information they own. It further proposes
that ISPs should operate an ALTO Service through which they should
increase both the performance of P2P applications and the efficiency
of their own operation. As suggested in [I-D.ietf-alto-problem-
statement], revealing (at least in part) the underlying network
information to the P2P overlay applications allows a range of
operating points in which both ISPs and overlay application users are
better off than before, i.e., when overlay applications operate
oblivious of the underlying network.
This document describes a protocol that facilitates the exchange of
information between overlay application entities and the ISPs. Such
information can be used at each side to make decisions that are
beneficial to both, or at least do not harm the other one.
The key aspects of the protocol are the following:
Despotovic, et al. Expires January 6, 2010 [Page 5]
Internet-Draft ALTO-FCP July 2009
o Negotiation between the ALTO Client and the ALTO Server allowing
the two parties to gradually reveal more information and find
their best tradeoffs between the revealed information and
performance gains.
o Feedback submission from an ALTO Client to an ALTO Server with the
goal of improving the ALTO Server's operation in the future. More
precisely, performance reporting from the ALTO Client to the ALTO
Server should give the Server an opportunity to learn about
conditions in remote parts of the Internet and thus improve its
recommendations with time. Equally important, the ALTO Server can
through these performance reports learn about new applications,
i.e., how to guide the Clients running these applications.
The rest of the document is structured as follows: section 3 provides
the architectural context and section 4 discusses the protocol.
Despotovic, et al. Expires January 6, 2010 [Page 6]
Internet-Draft ALTO-FCP July 2009
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Several terms used in this document have special meaning in the
context of ALTO. These terms are defined in [I-D.ietf-alto-problem-
statement].
Despotovic, et al. Expires January 6, 2010 [Page 7]
Internet-Draft ALTO-FCP July 2009
3. Architecture
In order to provide information about the underlying network, the
ALTO Service can access and expose to ALTO Clients (parts of) the
routing information available for example within the BGP routing
protocol executed by the ISP running the service. This is what [I-
D.bgp-based-alto-service], an informational draft accompanying this
document, proposes. BGP routing tables can be used to provide
locality indications to the Peers. Other policies found in the BGP
tables are also used. In summary, [I-D.bgp-based-alto-service] uses
all information available in BGP routing tables to rate IP addresses
sent by the ALTO Client and guide the overlay connection
establishment so that both the ISP and the overlay application
benefit. Extensions that further use intra-domain information
available in the BGP protocol are also possible, although they are
not considered at the moment.
ALTO +------+
SERVER 1 +-----+ | Peers
+-----+ +------+ +=====| |--+
| |........| |====+ +--*--+
+-----+ +------+ | *
Source 1 of / | *
topological / | +--*--+
information / +=====| | Resource Directory
/ +-----+ (Tracker, proxy)
/
/ +------+
/ +-----+ | Peers
+-----+ +------+ +=====| |--+
| |........| |====+ +--*--+
+-----+ +------+ | *
Source 2 of ALTO | *
topological SERVER 2 | +--*--+
information +=====| | Resource Directory
+-----+ (Tracker, proxy)
Legend:
=== ALTO Client protocol
*** Application protocol (out of scope)
... Provisioning or initialization (out of scope)
/// Inter-ALTO Server protocol
Figure 1: ALTO Protocol Architecture
Despotovic, et al. Expires January 6, 2010 [Page 8]
Internet-Draft ALTO-FCP July 2009
Figure 1 illustrates the architecture that this document follows.
Apart from proposing a specific ALTO Client-Server protocol, a side
goal of this document is to also emphasize the importance of
communication between ALTO Servers. From this perspective, the
information BGP and other IGP routing protocols provide can be seen
here as an important ingredient of such a future inter-ALTO Server
protocol.
The introduction of the ALTO Service requires the voluntary
participation of both the overlay application user and the ALTO
Service provider. As pointed out in Section 1, the ISP's incentive to
run an ALTO service is an optimized traffic pattern that reduces
costs for inter-domain and maybe also for intra-domain traffic. A
user's incentive to install an ALTO Client is an improved application
performance. However, studies [ChBu08, BiCa06] show that the
advantages of an ALTO Service are more on the ISP than on the Client
side. In case of BitTorrent, a significant improvement in the Client
performance is only observed if the bottleneck is in the inter-domain
links. However, when this is not the case, ISPs must look for
alternative sources of incentives for the users to follow the
guidance suggested by the ALTO Service. One such source might be the
ISP's promise to prioritize the traffic of those users who follow the
ALTO Service guidance. As such, the ALTO Service can be used not only
for providing information about the underlying network (closest
resources, congested links, etc.) but it could also enforce different
policies in the network in order to improve the network performance
guarantees for specific flows or for intra-domain traffic. The
principle idea is to have a normal ALTO Server that assists the users
in choosing their resource providers (Peers or mirror servers) such
that the selection is better than random and also in the interest of
the ISP running the ALTO Service. In exchange for the Client's
following the suggested guidance, the ISP may introduce a traffic
class "compliant best effort" which comprises all the traffic that
follows the guidance of the ALTO Server and is prioritized versus
best effort traffic or it could provide more bandwidth. For these
purposes, the ALTO Server could be enhanced by interfacing with the
Network Management Systems (NMS) of the ISP's network that are
usually able to enforce such policies.
Despotovic, et al. Expires January 6, 2010 [Page 9]
Internet-Draft ALTO-FCP July 2009
4. Protocol
The main contribution of this draft is an ALTO Client-Server
protocol, termed Application Layer Traffic Optimization Feedback-
Enhanced Client Protocol (ALTO-FCP) and specifically designed to fit
the architecture just presented and fulfill the goals set in the
Introduction. ALTO-FCP follows the request/response message exchange
pattern between ALTO Clients and ALTO Servers. The eight main ALTO-
FCP messages are: the Capabilities Query, the Capabilities Response,
the Guidance Query, the Guidance Response, the Evaluation Request,
the Evaluation Offer, the Evaluation Query, and the Evaluation
Report.
Given a choice of ALTO Services, an ALTO Client MAY send a
Capabilities Query to each Service for discovering how much it can
assist in Resource Provider selection. ALTO Servers which are in a
position to reply MAY send back a Capabilities Response, providing
details of their rating skills. The Client selects an appropriate
subset of Servers and MUST then send a Guidance Query to each for
requesting ratings on a set of HLAs (Host Location Attribute, see [I-
D.ietf-alto-problem-statement]) transmitted with the Query. The
Client MAY also submit information that could guide the Server in
generating more specific ratings. Each Server considers the request
and SHOULD reply with a Guidance Response that mainly includes
ratings on the HLAs. A Server MAY send an Evaluation Request to a
subset of previously guided Clients for discovering if and how they
can provide feedback. Contacted Clients SHOULD respond to the Server
with Evaluation Offers, detailing their feedback skills in terms of
application performance metrics. A Server SHOULD then respond with an
Evaluation Query, specifying the interesting performance metrics.
Clients SHOULD send back an Evaluation Report with the measured
performance metrics for previously rated HLAs.
4.1. Messages
4.1.1. Capabilities
Capabilities Query (CQ):
An ALTO Client seeking guidance in Resource Provider selection
sends a CQ to one or more ALTO Servers to discover which rating
criteria are supported and at which accuracy level. Each contacted
Server SHOULD belong to a different ALTO Service. Servers belonging
to the same Service SHOULD be contacted through the ALTO Service.
ALTO Services and Servers are discovered through mechanisms
external to ALTO-FCP (e.g., [I-D.song-alto-server-discovery]). A CQ
Despotovic, et al. Expires January 6, 2010 [Page 10]
Internet-Draft ALTO-FCP July 2009
MAY include desired rating criteria and accuracy levels, so that
the ALTO Client can make a more informed selection among Servers.
Capabilities Response (CR):
An ALTO Server sends a CR to an ALTO Client as a normal response to
an earlier CQ. If the CQ was minimal, the CR SHOULD include all
supported rating criteria and maximum accuracy levels. If the CQ
identified options, the CR MUST NOT include supported rating
criteria that were not identified in the CQ options. Similarly, the
CR MUST NOT include supported rating criteria with maximum accuracy
levels that are below those identified in the CQ options.
4.1.2. Guidance
Guidance Query (GQ):
An ALTO Client sends a GQ to an ALTO Server to request guidance in
Resource Provider selection. A GQ MUST include a set of HLAs (Host
Location Attribute, see [I-D.ietf-alto-problem-statement]) that the
Client has obtained through Application mechanisms. This HLA set
represents potential Resource Providers for which the Client seeks
ratings. To direct the Server in generating the ratings, a GQ MAY
include a set of rating criteria. In this case, a GQ MAY in
addition identify the desired accuracy level and the relative
importance of each criterion.
A Client MAY also request rating criteria values to be provided for
each HLA, so that Resource Provider selection can be more informed.
In further assistance of rating generation, a GQ MAY include the
Application type, e.g., file sharing, media streaming, etc.
A Client MAY send a GQ for the same HLA set to a subset of the
Servers identified earlier through a Capabilities Query/Response
conversation, but possibly with different options.
A Client MAY also request the Server to rate HLAs for each of the
provided rating criteria separately. In that case the Server MUST
send back a list of ratings for each criterion. The Client's
rationale for doing so can be better optimization or to keep the
application objective shielded from the Server.
When an ALTO Client is not satisfied with the response from an ALTO
Server and it believes that the source of problem was too broad
HLAs or missing options, the Client MAY send a refinement of the
previously sent GQ. This can lead to a sequence of GQ/GR messages.
Despotovic, et al. Expires January 6, 2010 [Page 11]
Internet-Draft ALTO-FCP July 2009
Guidance Response (GR):
A GR is sent from an ALTO Server to an ALTO Client as a normal
response to an earlier GQ. A GR SHOULD provide a rating for each
HLA in the associated GQ. If the Server is unable to provide a
rating for an HLA then any information about that HLA MUST be
omitted from the GR. A Server MAY include in the GR the values of
the rating criteria used during rating generation in order to
further assist the Client in using the guidance.
4.1.3. Evaluation
Client evaluation reporting is an OPTIONAL part of ALTO-FCP. The
intention is to allow the ALTO Server to obtain feedback on the rated
HLAs. This feedback is in the form of performance metrics (e.g.,
bandwidth estimates, round trip times, connection stability, etc.)
that the Client measures while communicating with Peers at rated
HLAs. The ALTO Server obtains evaluation reports from different
Clients and can aggregate them to get a picture of HLA-HLA
communication performance as seen by the Clients. The ALTO Server may
then offer these HLA-HLA performance metrics as additional rating
criteria to the ALTO Clients.
The Client evaluation reporting messages are:
Evaluation Request (ERQ):
Possibly after a successful exchange of GQ/GR messages, an ALTO
Server MAY send an ERQ to an ALTO Client requesting information on
the Client's evaluation reporting capabilities.
Evaluation Offer (EO):
An ALTO Client SHOULD send an EO message to an ALTO Server as a
normal response to an ERQ message. The EO identifies performance
metrics that the Client can evaluate. An empty EO indicates that
the Client does not support or is not willing to provide any
performance metrics.
Evaluation Query (EQ):
An ALTO Server SHOULD send an EQ message as a normal response to a
non-empty EO message. The ALTO Server MUST NOT send an EQ message
following an empty EO message. The EQ identifies those performance
metrics that the Server is actually interested in. The requested
performance metrics MUST be a subset of the performance metrics
offered in the EO message.
Despotovic, et al. Expires January 6, 2010 [Page 12]
Internet-Draft ALTO-FCP July 2009
Evaluation Report (ER):
An ALTO Client SHOULD send an ER to an ALTO Server as a normal
response to an earlier EQ message. The ER contains a list of HLAs
and each HLA entry is associated with the evaluation of one or more
performance metrics. The ALTO Server SHALL only consider the HLAs
contained in earlier GRs. The reported performance metrics MUST be
a subset of the performance metrics requested in the prior EQ.
4.2. Additional capabilities of an ALTO Server
In case the ALTO Server also provides additional capabilities by
interfacing the NMS (as explained in section 3) to, e.g., enforce a
specific policy in the network, the ALTO server will build the GR
considering the policies already applied in the network and it can
also include an additional tag to show them. Moreover, the ALTO
could offer all those capabilities as an additional service.
Therefore, a new query-response transaction should be defined in
order to allow the ALTO Client to identify the selected HLAs and
the requested capacities and the ALTO Server should provide a
response to show the result of the application of the new policies
in the network (e.g., bandwidth available and guaranteed for the
HLA-HLA connection).
Despotovic, et al. Expires January 6, 2010 [Page 13]
Internet-Draft ALTO-FCP July 2009
5. Security Considerations
Queries, such as the CQ and the GQ, sent from ALTO Clients to ALTO
Servers can become the vehicle for Denial of Service attacks. This
may also hold for the EQ, sent from Servers to Clients. The ALTO
Service and Application providers should consider these possibilities
and strive for appropriate measures at each end.
To prevent such attacks or also to ease privacy concerns that
Applications and ISPs might have in revealing information, protocols
such as SSL/TLS could be used orthogonally to ALTO-FCP, for security,
integrity, and bilateral authentication. This might though require
agreements and mechanisms at the business level.
Despotovic, et al. Expires January 6, 2010 [Page 14]
Internet-Draft ALTO-FCP July 2009
6. IANA Considerations
None yet.
Despotovic, et al. Expires January 6, 2010 [Page 15]
Internet-Draft ALTO-FCP July 2009
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.ietf-alto-problem-statement] Seedorf, J. and E. Burger,
"Application-Layer Traffic Optimization (ALTO) Problem
Statement", draft-ietf-alto-problem-statement-01 (work in
progress), May 2009.
[I-D.ietf-alto-reqs] Kiesel, S., Popkin, L., Previdi, S., Woundy, R.,
and Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-00 (work in progress),
April 2009.
[I-D.song-alto-server-discovery] Song, H., Even, R., Pascual, V., and
R. Zhang, "Application-Layer Traffic Optimization (ALTO):
Discover ALTO Servers", draft-song-alto-server-discovery-00
(work in progress), March 2009.
[I-D.bgp-based-alto-service] Racz, P. and Z. Despotovic, "An ALTO
Service based on BGP Routing Information", draft-racz-bgp-
based-alto-service-00.txt (work in progress), May 2009.
[BiCa06] Ruchir Bindal, Pei Cao, William Chan, Jan Medval, George
Suwala, Tony Bates, and Amy Zhang, Improving Traffic
Locality in BitTorrent via Biased Neighbor Selection,
Proceedings of the 26th IEEE International Conference on
Distributed Computing Systems, 2006
[ChBu08] David R. Choffnes and Fabian E. Bustamante, Taming the
torrent: a practical approach to reducing cross-ISP traffic
in Peer-to-Peer systems, SIGCOMM Comput. Commun. Rev., vol
38(4), 2008
Despotovic, et al. Expires January 6, 2010 [Page 16]
Internet-Draft ALTO-FCP July 2009
8. Acknowledgments
The authors are partially supported by the European Commission with
the research project SmoothIT (Simple Economic Management Approaches
of Overlay Traffic in Heterogeneous Internet Topologies) under the
7th Framework Programme.
The authors are grateful to Fabio Hecht, Marcin Niemiec, and
Krzysztof Wajda for their contribution and comments during the early
stages of this work.
Spiros Spirou would like to thank Michalis Makidis for fruitful
discussions on the protocol messages.
This document was prepared using 2-Word-v2.0.template.dot.
Despotovic, et al. Expires January 6, 2010 [Page 17]
Internet-Draft ALTO-FCP July 2009
Authors' Addresses
Zoran Despotovic
DOCOMO Euro-Labs
Landsberger Strasse 312
Munich
Germany
Email: despotovic@docomolab-euro.com
Wolfgang Kellerer
DOCOMO Euro-Labs
Landsberger Strasse 312
Munich
Germany
Email: kellerer@docomolab-euro.com
Spiros Spirou
Intracom Telecom
19.7 km Markopoulou Avenue
19002 Peania
Greece
Email: spis@intracom.com
Dirk Staehle
University of Wuerzburg
Chair of Distributed Systems
Am Hubland
Wuerzburg 97074
Germany
Email: dstaehle@informatik.uni-wuerzburg.de
Maria Rodriguez
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
28043 Madrid
Spain
Email: macr@tid.es
Ioanna Papafili
Athens University of Economics and Business
Patission str. 76
10434 Athens
Greece
Email: iopapafi@aueb.gr
Despotovic, et al. Expires January 6, 2010 [Page 18]
