Network Working Group S. Randriamasy, Ed.
Internet-Draft Alcatel-Lucent Bell Labs
Intended status: Experimental N. Schwan
Expires: January 12, 2012 July 11, 2011
Multi-Cost ALTO
draft-randriamasy-alto-multi-cost-03
Abstract
IETF is designing a new service called ALTO (Application Layer
traffic Optimization) that includes a "Network Map Service", an
"Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and
thus incentives for application clients to connect to ISP preferred
Endpoints. These services provide a view of the Network Provider
(NP) topology to overlay clients.
The present draft proposes a light way to extend the information
provided by the current ALTO protocol. The purpose is to broaden the
possibilities of the Application Clients in two ways: firstly by
providing a better mapping of the Selected Endpoints to needs of the
growing diversity of Content Networking Applications and to the
network conditions, secondly by producing a more robust choice of
multiple Endpoints, helping thus out for efficient Multi-Path
transfer.
There are 2 parts in this draft: the first part initiates protocol
extensions to support requests on multiple Cost Types in one single
transaction. These first extensions also integrate the discussions
within the ALTO Working Group and focus on the Endpoint Cost Service.
The second part proposes two use cases motivating further definitions
of additional CostTypes and Cost Attributes related to timeframe and
validity period.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
Randriamasy & Schwan Expires January 12, 2012 [Page 1]
Internet-Draft multi-cost ALTO July 2011
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 12, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Randriamasy & Schwan Expires January 12, 2012 [Page 2]
Internet-Draft multi-cost ALTO July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Proposed ALTO protocol updates for multi-cost transactions . . 6
4.1. Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 6
4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7
4.1.3. Input Parameters . . . . . . . . . . . . . . . . . . . 7
4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 7
4.1.5. Response . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.6. Example . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 7
4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7
4.2.3. Input Parameters . . . . . . . . . . . . . . . . . . . 7
4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 8
4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.6. Example . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. ALTO Status Codes for Multi-Cost ALTO . . . . . . . . . . 8
5. Use cases for further Cost Types and Endpoint Properties . . . 8
5.1. Delay Sensitive Overlay Applications . . . . . . . . . . . 9
5.2. CDN Surrogate Selection . . . . . . . . . . . . . . . . . 10
6. Proposed additional Properties and Costs . . . . . . . . . . . 10
6.1. Scoping ALTO information . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Information for IANA on proposed Cost Types . . . . . . . 11
7.2. Information for IANA on proposed Endpoint Propeeries . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Randriamasy & Schwan Expires January 12, 2012 [Page 3]
Internet-Draft multi-cost ALTO July 2011
1. Introduction
IETF is designing a new service called ALTO that provides guidance to
P2P applications, which have to select one or several hosts from a
set of candidates that are able to provide a desired resource. This
guidance shall be based on parameters that affect performance and
efficiency of the data transmission between the hosts, e.g., the
topological distance. The ultimate goal is to improve Quality of
Experience (QoE) in the application while reducing resource
consumption in the underlying network infrastructure. The ALTO
protocol conveys the Internet View from the perspective of a Provider
Network region that spans from a region to one or more Autonomous
System (AS). Together with this Network Map, it provides the
Provider determined Cost Map between locations of the Network Map.
Last, it provides the Ranking of Endpoints w.r.t. their routing cost.
The term Network Provider in this document includes both ISPs, who
provide means to transport the data and Content Delivery Network
(CDN) operators who care for the dissemination, persistent storage
and possibly identification of the best/closest content copy.
The last ALTO protocol draft see [ID-alto-protocol], gives the
possibility to query multiple Endpoint properties at once (see
S.7.7.4.1). However section 7.7.3.2 on Cost Map states about both
parameters Cost Type and Cost Mode that: "This parameter MUST NOT be
specified multiple times". The ALTO requirements draft, see
[ID-ALTO-Requirements7] also states in REQ. ARv05-14: "The ALTO
client protocol MUST support the usage of several different rating
criteria types". In the current protocol draft, there is no
specified way to get values for several Cost Types altogether.
Currently, the costs are provided in a scalar form, one by one. So
that an ALTO Client wanting information for several Cost Types must
place a request and receive a response as many times as desired Cost
Types. However, vector costs provide a robust and natural input to
multi-path connections and getting all costs in one single query/
response transaction saves time and ALTO traffic, thus ressources,
thus energy.
The ALTO Problem Statement, see [RFC5693] and the ALTO requirements
draft, see [RFC5693] stress that: "information that can change very
rapidly, such as transport-layer congestion, is out of scope for an
ALTO service. Such information is better suited to be transferred
through an in-band technique at the transport layer instead", as
"ALTO is not an admission control system "and does not necessarily
know about the instant load of endpoints and links. However, longer
term statistics or empirical ratings on performance oriented
information may still be useful for a reliable choice of candidate
endpoints. In addition, given the QoE requirements of nowadays and
Randriamasy & Schwan Expires January 12, 2012 [Page 4]
Internet-Draft multi-cost ALTO July 2011
future Internet applications, more and more NPs compute and store
such information to optimize their traffic. Last, specific ALTO
servers can be specified for mobile core networks, which have a
smaller scale and can afford and take advantage of using smaller
time-scale network information.
Adding QoE-enabling metrics to the Network Provider established
routing cost could meet the interests of both the end users and the
Providers. Besides, keeping the shortest or cheapest possible path,
in addition, saves resources, time and energy.
2. Scope
This draft generalizes the case of a P2P client to include the case
of a CDN client, a GRID application client and any Client having the
choice in several connection points for data or resource exchange.
To do so, it uses the term "Application Client" (AC).
This draft focuses on the use case where the ALTO client is embedded
in the Application Client. For P2P applications, the use case where
the ALTO Client is embedded in the P2P tracker is also applicable.
It is assumed that Applications likely to use the ALTO service have a
choice in connection endpoints as it is the case for most of them.
The ALTO service is managed by the Network Provider and reflects its
preferences for the choice of endpoints. The NP defines in
particular the network map, the routing cost among Network Locations,
and which ALTO services are available at a given ALTO server.
The solution proposed in this draft is applicable to fixed networks.
It is also meant for smaller networks such as mobile networks.
3. Terminology
Endpoint (EP): can be a Peer, a CDN storage location, a Party in a
resource sharing swarm such as a computation Grid or an online multi-
party game.
Endpoint Discovery (EP Discovery) : this term covers the different
types of processes used to discover different types of endpoints.
Network Service Provider: includes both ISPs, who provide means to
transport the data and Content Delivery Network (CDN) who care for
the dissemination, persistent storage and possibly identification of
the best/closest content copy.
Randriamasy & Schwan Expires January 12, 2012 [Page 5]
Internet-Draft multi-cost ALTO July 2011
Application Client (AC): this term generalizes the case of a P2P
client to include the case of a CDN client and of any Client having
the choice in several connection points for data or resource
exchange.
4. Proposed ALTO protocol updates for multi-cost transactions
This section is to be completed and proposes first updates of the
ALTO protocol to support Multi Cost ALTO Services or provide
additional ALTO information. It integrates discussions on he ALTO
mailing list and its goal is to initiate further discussions and
protocol update proposals.
If an ALTO client desires several Cost Types, instead of placing as
many requests as costs, it may request and receive all the desired
cost types in one single transaction. The correspondence between the
components and the cost types MUST be indicated in the ALTO request.
The ALTO server then, provided it supports the desired cost, and
provided it supports multi-cost ALTO transactions, sends one single
response where for each {source, destination} pair. The cost values
are arranged in a vector, whose component each corresponds to a
specified Cost Type. The correspondence between the components and
the cost types MUST be indicated either in the ALTO response or
available via the resource directory.
The ALTO services impacted by the Multi-Cost extensions are:
o Information Resources Directory,
o Cost Map Service,
o Cost Map Filtering Service,
o Endpoint Cost Lookup Service.
This draft focuses on the case of the Endpoint Cost Lookup Service
4.1. Multi-Cost Map Service
To be completed
4.1.1. Media Type
Randriamasy & Schwan Expires January 12, 2012 [Page 6]
Internet-Draft multi-cost ALTO July 2011
4.1.2. HTTP Method
This resource is requested using the HTTP POST method
4.1.3. Input Parameters
4.1.4. Capabilities
4.1.5. Response
4.1.6. Example
4.2. Endpoint Multi-Cost Service
4.2.1. Media Type
4.2.2. HTTP Method
This resource is requested using the HTTP POST method
4.2.3. Input Parameters
Input parameters are supplied in the entity body of the POST request.
This document specifies input parameters with a data format indicated
by media type "application/alto-endpointcostparams+json", which is a
JSON Object of type ReqEndpointCostMap:
object {
TypedEndpointAddr srcs<0..*>; [OPTIONAL]
TypedEndpointAddr dsts<1..*>;
} EndpointFilter;
object {
CostMode cost-mode;
CostType cost-type<1..*>;
JSONString constraints; [OPTIONAL]
EndpointFilter endpoints;
} ReqEndpointCostMap;
with members:
Randriamasy & Schwan Expires January 12, 2012 [Page 7]
Internet-Draft multi-cost ALTO July 2011
cost-mode The Cost Mode ( Section 5.1.2) to use for returned costs.
For Multi-Cost requests this Cost Mode SHOULD be numerical.
cost-type The Cost Type ( Section 5.1.1) to use for returned costs.
All the listed the Cost Types MUST be indicated in this resource's
capabilities ( Section 7.7.5.1.4).
constraints Defined equivalently to the "constraints" input parameter
of a Filtered Cost Map (see Section 7.7.3.2).
endpoints A list of Source Endpoints and Destination Endpoints for
which Path Costs are to be returned. If the list of Source Endpoints
is empty (or not included), the ALTO Server MUST interpret it as if
it contained the Endpoint Address corresponding Alimi, et al.
Expires December 29, 2011 [Page 50] Internet-Draft ALTO Protocol June
2011 to the client IP address from the incoming connection (see
Section 10.3 for discussion and considerations regarding this mode).
The list of destination Endpoints MUST NOT be empty. The ALTO Server
MUST interpret entries appearing multiple times in a list as if they
appeared only once.
4.2.4. Capabilities
4.2.5. Response
4.2.6. Example
4.3. ALTO Status Codes for Multi-Cost ALTO
If the Multi-cost Service is not supported for either the Cost Map or
the Endpoint Service, then the ALTO server sends an ALTO status code
7 corresponding to HTTP status code 501 indicating "Invalid cost
structure". The ALTO client may then needs to place as many requests
as needed Cost Types, and the ALTO server sends as many cost maps or
EP cost as needed.
To the attribute Cost Mode in S.5.1 should be associated a rule
stipulating that when multiple cost types are requested, then the
requested Cost Mode SHOULD be numerical.
5. Use cases for further Cost Types and Endpoint Properties
The current ALTO protocol [ID-alto-protocol] specification requests
the creation of two registries maintained by IANA. The ALTO Cost
Type registry ensures that the Cost Types that are represented by an
ALTO Cost Map are unique identifiers, and it further contains
references to the semantics of the Cost Type. The current
Randriamasy & Schwan Expires January 12, 2012 [Page 8]
Internet-Draft multi-cost ALTO July 2011
specification registers 'routingcost' as a generic measure for
routing traffic from a source to a destination. In a similar way the
ALTO Endpoint Property Registry ensures uniquenes of ALTO Endpoint
Property identifiers and provides references to particular semantics
of the allocated Enpoint Properties. Currently the 'pid' identifier
is registered, which serves as an identifier that allows aggregation
of network endpoints into network regions. Both registries accept
new entries after Expert Review [[ID-alto-protocol]]. New entries
are requested to be conform to the respective syntactical
requirements, and must include information about the new identifier,
the intended semantics as well as security considerations.
The current protocol specification concentrates on the basic use case
of optimizing routing costs in NSPs networks. Upcoming use cases
however will require both, new Cost Types and new Endpoint
Properties. The goal of this section is to describe further forward
looking use case scenarios that are likely to benefit from ALTO, and,
in future iterations, to convey new Cost Types and Endpoint
Properties that are likely to be beneficial for ALTO clients in these
scenarios.
5.1. Delay Sensitive Overlay Applications
The ALTO working group has been created to allow P2P applications and
NSPs a mutual cooperation, in particular because P2P bulk file-
transfer applications have created a huge amount of intra-domain
traffic. By aligning overlay topologies according to the
'routingcost' of the underlying network both layers are expected to
benefit in terms of reduced costs and improved Quality-of-Experience.
However other types of overlay applications might benefit from a
different set of path metrics. In particular for real-time sensitive
applications, such as gaming, interactive video conferencing or
medical services, creating an overlay topology with respect to a
minimized delay is preferable. However it is very hard for a NSP to
give accurate guidance for this kind of realtime information, instead
probing through end-to-end measurements on the application layer has
proven to be the superior mechanism. Still, a NSP might give some
guidance to the overlay application, for example by providing
statisically preferable paths with respect to the time of a day.
Also static information like hopcount can be seen as an indicator for
the delay that can be expected. In the following iterations this
draft will thus analyse which metrics can realisticaly be provided
through ALTO to give delay sensitive applications guidance for peer
selection.
Randriamasy & Schwan Expires January 12, 2012 [Page 9]
Internet-Draft multi-cost ALTO July 2011
5.2. CDN Surrogate Selection
A second use case is motivated through draft
[draft-jenkins-alto-cdn-use-cases-01]. The request router in today's
CDNs makes a decision about to which surrogate or cache node a
content request should be forwarded to. Typically this decision is
based on locality aspects, i.e. the surrogate node which is closest
to the client is preferred by the request router. An ALTO server
hereby is one promising option to allow NSPs to give guidance to the
CDN about which cache node would be preferable according to the view
of the network by the 'routingcost' Cost Type. Providing this kind
of information is in particular important as one trend is to place
cache nodes deeper into the network, which results in the need for
finer grained information.
While distance today is the predominant metric used for routing
decisions, other metrics might allow sophisticated request routing
strategies. For example the load a cache node sees in terms of CPU
utilization, memory usage or bandwidth utilization might influence
routing decisions for load-balancing reasons. There exist numerous
ways of gathering and feeding this kind of information into the
request routing mechanism. As ALTO is likely to become a
standardized interface to provide network topology information, for
simplicity other information that is used by a request router could
be provided by the ALTO server as well. In the next iterations of
this draft we will analyse which of these metrics is suitable to be
provided as Cost Type or Endpoint Property for the use case of CDN
Surrogate Selection and propose to register them in the respective
registries.
6. Proposed additional Properties and Costs
To be further specified
6.1. Scoping ALTO information
One way for the NSP to provide guidance on highly dynamic network
state information such as delay and load is to provide them in the
form of statistics or as a numerical coarse grain indicator. It is
important to have the possibility to reflect that the provided values
are applicable for a given time period, for example business hours,
and are subject to changes over time.
The following attributes can be associated to the applicable ALTO
information:
Randriamasy & Schwan Expires January 12, 2012 [Page 10]
Internet-Draft multi-cost ALTO July 2011
o an age attribute indicating when the information was generated.
o for statistical costs a time period attribute indicating over
which duration the statistics were collected.
o a validity attribute indicating when the provided values should be
refreshed. By defaut, this parameter can be set to infinity.
7. IANA Considerations
Information for the ALTO Endpoint property registry maintained by the
IANA and related to the new Endpoints supported by the acting ALTO
server. These definitions will be formulated according to the syntax
defined in Section on "ALTO Endpoint Property Registry" of
[ID-alto-protocol],
Information for the ALTO Cost Type Registry maintained by the IANA
and related to the new Cost Types supported by the acting ALTO
server. These definitions will be formulated according to the syntax
defined in Section on "ALTO Cost Type Registry" of
[ID-alto-protocol],
7.1. Information for IANA on proposed Cost Types
When a new ALTO Cost Type is defined, accepted by the ALTO working
group and requests for IANA registration MUST include the following
information, detailed in Section 11.2: Identifier, Intended
Semantics, Security Considerations.
7.2. Information for IANA on proposed Endpoint Propeeries
Likewise, an ALTO Endpoint Property Registry could serve the same
purposes as the ALTO Cost Type registry. Application to IANA
registration for Endpoint Properties would follow a similar process.
8. Acknowledgements
Sabine Randriamasy is partially supported by the MEDIEVAL project
(http://www.ict-medieval.eu/), a research project supported by the
European Commission under its 7th Framework Program (contract no.
248565). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the MEDIEVAL project or the European Commission.
Nico Schwan is partially supported by the ENVISION project
Randriamasy & Schwan Expires January 12, 2012 [Page 11]
Internet-Draft multi-cost ALTO July 2011
(http://www.envision-project.org), a research project supported by
the European Commission under its 7th Framework Program (contract no.
248565). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the ENVISION project or the European Commission.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5693] "Application Layer Traffic Optimization (ALTO) Problem
Statement", October 2009.
9.2. Informative References
[ID-ALTO-Requirements7]
"draft-ietf-alto-reqs-07.txt", January 2011.
[ID-alto-protocol]
, Eds., ""ALTO Protocol" draft-ietf-alto-protocol-09.txt",
June 2011.
[draft-jenkins-alto-cdn-use-cases-01]
""Use Cases for ALTO within CDNs"
draft-jenkins-alto-cdn-use-cases-01", June 2011.
Authors' Addresses
Sabine Randriamasy (editor)
Alcatel-Lucent Bell Labs
Route de Villejust
NOZAY 91460
FRANCE
Email: Sabine.Randriamasy@alcatel-lucent.com
Randriamasy & Schwan Expires January 12, 2012 [Page 12]
Internet-Draft multi-cost ALTO July 2011
Nico Schwan
Phone:
Fax:
Email:
URI:
Randriamasy & Schwan Expires January 12, 2012 [Page 13]