< draft-randriamasy-alto-multi-cost-02.txt		draft-randriamasy-alto-multi-cost-03.txt >
	Network Working Group S. Randriamasy, Ed.		Network Working Group S. Randriamasy, Ed.
	Internet-Draft Alcatel-Lucent Bell Labs		Internet-Draft Alcatel-Lucent Bell Labs
	Intended status: Experimental March 14, 2011		Intended status: Experimental N. Schwan
	Expires: September 15, 2011		Expires: January 12, 2012 July 11, 2011
	Multi-Cost ALTO		Multi-Cost ALTO
	draft-randriamasy-alto-multi-cost-02		draft-randriamasy-alto-multi-cost-03
	Abstract		Abstract
	IETF is designing a new service called ALTO (Application Layer		IETF is designing a new service called ALTO (Application Layer
	traffic Optimization) that includes a "Network Map Service", an		traffic Optimization) that includes a "Network Map Service", an
	"Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and		"Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and
	thus incentives for application clients to connect to ISP preferred		thus incentives for application clients to connect to ISP preferred
	Endpoints. These services provide a view of the Network Provider		Endpoints. These services provide a view of the Network Provider
	(NP) topology to overlay clients.		(NP) topology to overlay clients.
	The present draft proposes a light way to extend the information		The present draft proposes a light way to extend the information
	provided by the current ALTO protocol. The purpose is to broaden the		provided by the current ALTO protocol. The purpose is to broaden the
	possibilities of the Application Clients in two ways: firstly by		possibilities of the Application Clients in two ways: firstly by
	providing a better mapping of the Selected Endpoints to needs of the		providing a better mapping of the Selected Endpoints to needs of the
	growing diversity of Content Networking Applications and to the		growing diversity of Content Networking Applications and to the
	network conditions, secondly by producing a more robust choice of		network conditions, secondly by producing a more robust choice of
	multiple Endpoints, helping thus out for efficient Multi-Path		multiple Endpoints, helping thus out for efficient Multi-Path
	transfer.		transfer.
	There are 2 parts in this draft: the first part proposes protocol		There are 2 parts in this draft: the first part initiates protocol
	extensions to support requests on multiple CostTypes in 1		extensions to support requests on multiple Cost Types in one single
	transaction; the second part proposes additional CostTypes and Cost		transaction. These first extensions also integrate the discussions
	attributes related to timeframe and validity period.		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		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 12 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 15, 2011.		This Internet-Draft will expire on January 12, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Proposed ALTO services updates . . . . . . . . . . . . . . . . 6		4. Proposed ALTO protocol updates for multi-cost transactions . . 6
	4.1. Endpoint Cost Service with multiple Cost Types . . . . . . 6		4.1. Multi-Cost Map Service . . . . . . . . . . . . . . . . . . 6
	4.2. All Costs Types in one response with vector cost values . 6		4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Proposed additional Cost Types . . . . . . . . . . . . . . 7		4.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7
	4.4. Statistical Costs with a timeframe . . . . . . . . . . . . 7		4.1.3. Input Parameters . . . . . . . . . . . . . . . . . . . 7
	5. Proposed ALTO protocol updates . . . . . . . . . . . . . . . . 8		4.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Proposed updates for Multi-Cost ALTO . . . . . . . . . . . 8		4.1.5. Response . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1.1. Multi-Cost related Attributes . . . . . . . . . . . . 9		4.1.6. Example . . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Proposed additional Properties and Costs . . . . . . . . . 9		4.2. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 7
	5.2.1. Proposed additional Endpoints properties . . . . . . . 9		4.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 7
	5.2.2. Scoping ALTO information . . . . . . . . . . . . . . . 10		4.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7
	5.2.3. Proposed additional Cost Types . . . . . . . . . . . . 10		4.2.3. Input Parameters . . . . . . . . . . . . . . . . . . . 7
	5.3. ALTO Status Codes for Multi-Cost ALTO . . . . . . . . . . 11		4.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 8
	5.4. Examples of Multi-Cost ALTO messages . . . . . . . . . . . 11		4.2.5. Response . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.2.6. Example . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.3. ALTO Status Codes for Multi-Cost ALTO . . . . . . . . . . 8
	6.2. Illustrative ALTO use case . . . . . . . . . . . . . . . . 12		5. Use cases for further Cost Types and Endpoint Properties . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		5.1. Delay Sensitive Overlay Applications . . . . . . . . . . . 9
	7.1. Information for IANA on proposed Cost Types . . . . . . . 15		5.2. CDN Surrogate Selection . . . . . . . . . . . . . . . . . 10
	7.2. Information for IANA on proposed Endpoint Propeeries . . . 15		6. Proposed additional Properties and Costs . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. Scoping ALTO information . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 16		7.1. Information for IANA on proposed Cost Types . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . . 16		7.2. Information for IANA on proposed Endpoint Propeeries . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
			9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
			9.2. Informative References . . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	IETF is designing a new service called ALTO that provides guidance to		IETF is designing a new service called ALTO that provides guidance to
	P2P applications, which have to select one or several hosts from a		P2P applications, which have to select one or several hosts from a
	set of candidates that are able to provide a desired resource. This		set of candidates that are able to provide a desired resource. This
	guidance shall be based on parameters that affect performance and		guidance shall be based on parameters that affect performance and
	efficiency of the data transmission between the hosts, e.g., the		efficiency of the data transmission between the hosts, e.g., the
	topological distance. The ultimate goal is to improve Quality of		topological distance. The ultimate goal is to improve Quality of
	Experience (QoE) in the application while reducing resource		Experience (QoE) in the application while reducing resource
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 26 ¶
	Network region that spans from a region to one or more Autonomous		Network region that spans from a region to one or more Autonomous
	System (AS). Together with this Network Map, it provides the		System (AS). Together with this Network Map, it provides the
	Provider determined Cost Map between locations of the Network Map.		Provider determined Cost Map between locations of the Network Map.
	Last, it provides the Ranking of Endpoints w.r.t. their routing cost.		Last, it provides the Ranking of Endpoints w.r.t. their routing cost.
	The term Network Provider in this document includes both ISPs, who		The term Network Provider in this document includes both ISPs, who
	provide means to transport the data and Content Delivery Network		provide means to transport the data and Content Delivery Network
	(CDN) operators who care for the dissemination, persistent storage		(CDN) operators who care for the dissemination, persistent storage
	and possibly identification of the best/closest content copy.		and possibly identification of the best/closest content copy.
	The last ALTO protocol draft see [ID-alto-protocol6], gives the		The last ALTO protocol draft see [ID-alto-protocol], gives the
	possibility to query multiple Endpoint properties at once (see		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		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		parameters Cost Type and Cost Mode that: "This parameter MUST NOT be
	specified multiple times". The ALTO requirements draft, see		specified multiple times". The ALTO requirements draft, see
	[ID-ALTO-Requirements7] also states in REQ. ARv05-14: "The ALTO		[ID-ALTO-Requirements7] also states in REQ. ARv05-14: "The ALTO
	client protocol MUST support the usage of several different rating		client protocol MUST support the usage of several different rating
	criteria types". In the current protocol draft, there is no		criteria types". In the current protocol draft, there is no
	specified way to get values for several Cost Types altogether.		specified way to get values for several Cost Types altogether.
	Currently, the costs are provided in a scalar form, one by one. So		Currently, the costs are provided in a scalar form, one by one. So
	that an ALTO Client wanting information for several Cost Types must		that an ALTO Client wanting information for several Cost Types must
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 38 ¶
	The ALTO service is managed by the Network Provider and reflects its		The ALTO service is managed by the Network Provider and reflects its
	preferences for the choice of endpoints. The NP defines in		preferences for the choice of endpoints. The NP defines in
	particular the network map, the routing cost among Network Locations,		particular the network map, the routing cost among Network Locations,
	and which ALTO services are available at a given ALTO server.		and which ALTO services are available at a given ALTO server.
	The solution proposed in this draft is applicable to fixed networks.		The solution proposed in this draft is applicable to fixed networks.
	It is also meant for smaller networks such as mobile networks.		It is also meant for smaller networks such as mobile networks.
	3. Terminology		3. Terminology
	Endpoint (EP): can be a Peers, a CDN storage location, a Party in a		Endpoint (EP): can be a Peer, a CDN storage location, a Party in a
	resource sharing swarm such as Grid or online gaming.		resource sharing swarm such as a computation Grid or an online multi-
			party game.
	Endpoint Discovery (EP Discovery) : this term embraces the different		Endpoint Discovery (EP Discovery) : this term covers the different
	types of processes used to discover different types of endpoints.		types of processes used to discover different types of endpoints.
	Network provider: includes both ISPs, who provide means to transport		Network Service Provider: includes both ISPs, who provide means to
	the data and Content Delivery Network (CDN) who care for the		transport the data and Content Delivery Network (CDN) who care for
	dissemination, persistent storage and possibly identification of the		the dissemination, persistent storage and possibly identification of
	best/closest content copy.		the best/closest content copy.
	Application Client (AC): this term generalizes the case of a P2P		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		client to include the case of a CDN client and of any Client having
	the choice in several connection points for data or resource		the choice in several connection points for data or resource
	exchange.		exchange.
	Traffic Engineered End Point Optimization Tool (TEEPOT): this is a		4. Proposed ALTO protocol updates for multi-cost transactions
	functional entity introduced in this draft, that is linked to an ALTO
	Client and to an Application Client. Its role is to assist the
	selection of Endpoints upon Allication needs and the ALTO responses.
	It can be a specific group of functions or an already existing
	function.
	4. Proposed ALTO services updates
	The currently available ALTO services supporting Endpoint evaluation
	are: Endpoint Cost Service, Cost Map and Filtered Cost Map. The ALTO
	client may want to simultaneously use a number N>1 of cost metrics
	referred to as Cost Types in ALTO. The only possibility in the
	current ALTO protocol is to sequentially place as many requests as
	desired cost types. This draft proposes to add the following
	features:
	4.1. Endpoint Cost Service with multiple Cost Types
	Some application clients may want to consider several metrics to
	select the endpoints appropriately w.r.t. the application needs.
	Clients may also want to use multiple paths for the transfer of
	particular data bulks, possibly selected with several metrics.
	Therefore the Endpoint Cost Lookup and the Cost Map Services should
	have the possibility to handle several metrics.
	4.2. All Costs Types in one response with vector cost values
	Providing all the numerical costs simultaneously with only one
	request and response exchange saves time, resources and energy. To
	avoid overloading the network with ALTO traffic with multiple
	requests for Cost Types, we propose that the Cost values provided by
	the ALTO server be arranged in a vector. This requires:
	o to put the requested cost values in an array or vector having a
	number N >= 1 of components.
	o to define a canonical order that allows to match values in these
	vectors with Cost Types and Properties.
	As specified in the ALTO Requirements [ID-ALTO-Requirements7] "REQ.
	ARv05-19: The ALTO reply message SHOULD allow the ALTO server to
	express which rating criteria have been considered when generating
	the reply." That is, the ALTO response indicates the mapping between
	vector components and Cost Types.
	Note that in this case, the ALTO client MUST require the Cost Mode
	"numerical" that is the Mode MUST NOT be "ordinal".
	4.3. Proposed additional Cost Types
	The current ALTO protocol draft provides examples of metrics in
	section 5.1.1, that are: air miles, hop-counts or generic routing
	costs. Statistics or longer term ratings on path bandwidth and
	latency may also be considered. Additional Endpoint properties may
	be useful, such as the memory capacity or statistical scores on the
	load and possibilities of an Endpoint.
	4.4. Statistical Costs with a timeframe
	The ALTO Requirements Draft [ID-ALTO-Requirements7] advises against
	instant performance-related cost metrics as they may be easily
	captured by online mechanisms and in addition, the ALTO service does
	not know how a Peer manages its sending rate. Application clients
	however may have good reasons and wise ways to use performance
	related information in the mid to long term ,on Endpoints that they
	don't know in advance and on which they therefore cannot plan
	measurements. Other applications may wisely use static performance
	indicators such as nominal memory capacity.
	Dynamic performance indicators can be represented by scores,
	reflecting some overall performance, in a static way or with values
	periodically updated at intervals typically longer than a network
	layer packet RTT, as assumed in [ID-ALTO-Requirements7].
	If statistical Cost Types are available, the following types of
	information should report on them:
	o their "statistical" nature: for example a mean value, or a median
	value,
	o their timeframe: that is the period over which statistics were
	computed and the age of the information. By default this
	timeframe is supposed permanent , that is, the corresponding EP
	Cost or Property values are permanent. Timeframe information can
	be easily recovered by attributes listed in
	[ID-ALTO-Requirements7] such as 'lifetime' (see REQ. ARv07-29)
	and an aging mechanism (see REQ. ARv07-29), such as a RFC3339
	based TimeStamp.
	o the validity period: indicating the date at which the information
	can be considered obsolete and updated. This can be easily
	reflected by the 'age' reflecting the date at which the
	information was generated and 'lifetime' of this information.
	'Lifetime' and 'age' should be also available to other applicable
	'non statistical' Cost Types, such as 'OccupationLevel' that can be
	used to describe an empirical and restricted set of load value
	ranges.
	5. Proposed ALTO protocol updates
	This section proposes updates or additions to the ALTO protocol to
	support Multi Cost ALTO Services or provide additional ALTO
	information. The applicable ALTO services are:
	o Cost Map Service,
	o Cost Map Filtering Service,
	o Endpoint Property Lookup Service,
	o Endpoint Cost Lookup Service.
	5.1. Proposed updates for Multi-Cost ALTO		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		If an ALTO client desires several Cost Types, instead of placing as
	many requests as costs, it may request and receive all the desired		many requests as costs, it may request and receive all the desired
	cost types in one transaction. The correspondence between the		cost types in one single transaction. The correspondence between the
	components and the cost type MUST be indicated in the ALTO request.		components and the cost types MUST be indicated in the ALTO request.
	The ALTO server then, provided it supports the desired cost, and		The ALTO server then, provided it supports the desired cost, and
	provided it supports the vector cost values, sends one single		provided it supports multi-cost ALTO transactions, sends one single
	response where for each {source, destination} pair, the cost values		response where for each {source, destination} pair. The cost values
	are arranged in a vector, whose component each corresponds to a		are arranged in a vector, whose component each corresponds to a
	specified Cost Type. The correspondence between the components and		specified Cost Type. The correspondence between the components and
	the cost types MUST be indicated in the ALTO response.		the cost types MUST be indicated either in the ALTO response or
			available via the resource directory.
	The following ALTO protocol services and features need to be updated
	to enable Multi Cost ALTO transactions.
	o Endpoint (EP) Property (see [ID-alto-protocol6] )
	o Endpoint (EP) Cost (see [ID-alto-protocol6]).
	o Cost attributes (see [ID-alto-protocol6]).
	o Cost Map (see [ID-alto-protocol6] ):
	* between Network Locations (that are groups of 1 or several
	endpoints).
	o Cost Map filtering: need the same updates as for the Cost Map.
	5.1.1. Multi-Cost related Attributes
	To enable Multi-Cost ALTO Cost Services, we propose the following
	updates to the Cost Attributes, described in [ID-alto-protocol6] .
	o extension of the attribute Cost Type from a single value to a
	vector of N >= 1 values. If N > 1, then the values WILL be
	interpreted as numerical values.
	o addition of definitions that list and identify the Cost Types
	supported by the acting ALTO server. These definitions will be
	formulated according to the syntax defined in Section 7.7 of
	[ID-alto-protocol6],
	o definition of the correspondence between an index "i_typecost" in
	[1,N] in a cost vector and the ID of the defined cost types and
	properties.
	o optional association of a validity timeframe, indicating how long
	the information can be considered as up to date.
	* by default the validity timeframe WILL be considered infinite
	To the attribute Cost Mode in S.5.1: addition of a rule stipulating		The ALTO services impacted by the Multi-Cost extensions are:
	that when multiple cost types are requested, then the requested Cost
	Mode MUST be numerical. If the attribute Cost Length is > 1 and the
	Cost Mode is set to "ordinal", then one option is that the ALTO
	Server returns the 'Sucess' code "E_INVALID_COST_TYPE".
	5.2. Proposed additional Properties and Costs		o Information Resources Directory,
	5.2.1. Proposed additional Endpoints properties		o Cost Map Service,
	The Endpoint Properties given as example in [ID-alto-protocol6]		o Cost Map Filtering Service,
	S.3.2.3 mostly apply to fixed end nodes. We propose to add other
	properties, that are static, contribute to reflect the potential
	physical abilities of end nodes and therefore may guide their
	selection. In addition, these properties apply to end nodes
	connected by any access technology. Example additional properties
	include:
	o EP capacity in memory,		o Endpoint Cost Lookup Service.
	o EP nominal bandwidth,		This draft focuses on the case of the Endpoint Cost Lookup Service
	o EP access technology.		4.1. Multi-Cost Map Service
	Note that if this service is not supported, it is possible although		To be completed
	less convenient to get the information at the overlay level, thus
	without the ALTO server.
	5.2.2. Scoping ALTO information		4.1.1. Media Type
			4.1.2. HTTP Method
	One way to moderate the ALTO traffic load while maintaining some		This resource is requested using the HTTP POST method
	reliability is to associate the following attributes to the
	applicable ALTO information:
	o an age attribute indicating when the information was generated.		4.1.3. Input Parameters
	o for statistical costs a time period attribute indicating over		4.1.4. Capabilities
	which period the statistics were collected.
	o a lifetime attribute as proposed in [ID-ALTO-Requirements7] . By		4.1.5. Response
	defaut, this parameter can be set to infinity.
	The Time related values can be used by the aging mechanism as		4.1.6. Example
	proposed in REQ ARv05-28 of [ID-ALTO-Requirements7] for a better
	synchronization of Cost Information collected at various times and
	places.
	5.2.3. Proposed additional Cost Types		4.2. Endpoint Multi-Cost Service
	Additional Cost Types may be used in either the Cost Map or the		4.2.1. Media Type
	Endpoint Cost Lookup Services and include:
	o Endpoint availability: indicating how often an Endpoint is		4.2.2. HTTP Method
	reachable, preferebly as a percentage. To be further specified.
	Possibly with associated Time frame and Time To Expire.
	o Endpoint reliability: indicating how easily an Endpoint is		This resource is requested using the HTTP POST method
	reachable, and / or the degree of continuity of its reachability,
	preferebly as a percentage. To be further specified.
	o Endpoint Load: indicating the average load, preferably as a		4.2.3. Input Parameters
	percentage, or a quantitative coarse grain index indicating
	whether this Endpoint is in a rush period or calm period. To be
	further specified.
	o Path robustness: one or more timeframed indicators related to		Input parameters are supplied in the entity body of the POST request.
	statistical evaluations of the path performance on bandwidth,		This document specifies input parameters with a data format indicated
	delay, packet loss, or other such metrics. This Cost can also be		by media type "application/alto-endpointcostparams+json", which is a
	represented by a quantitative coarse grain index indicating		JSON Object of type ReqEndpointCostMap:
	whether this Endpoint is in a rush period or calm period. To be
	further specified.
	5.3. ALTO Status Codes for Multi-Cost ALTO		object {
	If the vector cost structure is not supported, then the ALTO server		TypedEndpointAddr srcs<0..*>; [OPTIONAL]
	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		TypedEndpointAddr dsts<1..*>;
	stipulating that when multiple cost types are requested, then the
	requested Cost Mode MUST be numerical. If the attribute Cost Length
	is > 1 and the Cost Mode is set to "ordinal", an option is that the
	ALTO Server returns the 'Sucess' code "E_INVALID_COST_TYPE".
	5.4. Examples of Multi-Cost ALTO messages		} EndpointFilter;
	Request and Response syntax. To be further specified.		object {
	6. Use case		CostMode cost-mode;
	6.1. Scenario		CostType cost-type<1..*>;
	A Multi-Cost ALTO transaction is illustrated in a simple scenario,		JSONString constraints; [OPTIONAL]
	where an application client in a terminal wants to use several paths
	for a data transfer. This scenario applies to a terminal having
	access to the network via one or several interfaces.
	The application client wants for example 3 paths per transfer:		EndpointFilter endpoints;
	o 1 path optimising the Cost Type 'routingcost',		} ReqEndpointCostMap;
	o 2 other paths optimizing 2 metrics: the Cost Type 'routingcost'		with members:
	and an Endpoint property named 'EP memory'.
	* The application client in addition wants these 2 paths to		cost-mode The Cost Mode ( Section 5.1.2) to use for returned costs.
	optimize the first criterion with a weight W_PATH_LENGTH equal		For Multi-Cost requests this Cost Mode SHOULD be numerical.
	for example to 0.4 and the second criterion with a weight
	W_EP_MEMORY equal to 0.6.
	* If the EP Property Service provides the information on Endpoint		cost-type The Cost Type ( Section 5.1.1) to use for returned costs.
	Load, then the application client wants this information in the		All the listed the Cost Types MUST be indicated in this resource's
	available lifetime closest to 1 hour.		capabilities ( Section 7.7.5.1.4).
	A TEEPOT connected with the ALTO Client and the Application Client		constraints Defined equivalently to the "constraints" input parameter
	takes in the list of candidate Endpoints from the Application Client		of a Filtered Cost Map (see Section 7.7.3.2).
	and prepares for the ALTO Client the request to the ALTO Server, in
	particular the following information: vector TimeFrame[EP Cost
	Length], with components equal to either a value or an indication of
	"not applicable".
	o The list of requested EP Cost Types, that are identified by their		endpoints A list of Source Endpoints and Destination Endpoints for
	index I_CostType.		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.
	o		4.2.4. Capabilities
	6.2. Illustrative ALTO use case		4.2.5. Response
	Figure 1 shows the example scenario in the last IETF ALTO protocol		4.2.6. Example
	draft, where the ALTO client is embedded in the P2P Client and
	requires an ALTO server servicing its own ISP to provide the Endpoint
	Cost for a list of gethered peers.
	As written in [ID-alto-protocol6], the use case proceeds as follows:		4.3. ALTO Status Codes for Multi-Cost ALTO
	1. The P2P Client discovers peers from sources such as Peer Exchange		If the Multi-cost Service is not supported for either the Cost Map or
	(PEX) from other P2P Clients, Distributed Hash Tables (DHT), and		the Endpoint Service, then the ALTO server sends an ALTO status code
	P2P Trackers.		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.
	2. The P2P Client queries the ALTO Server's Ranking Service,		To the attribute Cost Mode in S.5.1 should be associated a rule
	including discovered peers as the set of Destination Endpoints,		stipulating that when multiple cost types are requested, then the
	and indicates the 'ordinal' Cost Mode. The response indicates		requested Cost Mode SHOULD be numerical.
	the ranking of the candidate peers.
	3. The P2P Client connects to the peers in the order specified in		5. Use cases for further Cost Types and Endpoint Properties
	the ranking.
	.---------. .---------------.		The current ALTO protocol [ID-alto-protocol] specification requests
	| | (2) Get Endpoint Ranking | |		the creation of two registries maintained by IANA. The ALTO Cost
	| ALTO | <----------------------> | [ALTO Client] |		Type registry ensures that the Cost Types that are represented by an
	| Server | | |		ALTO Cost Map are unique identifiers, and it further contains
	| | | P2P Client | .---------.		references to the semantics of the Cost Type. The current
	`---------' `---------------' <- | P2P |		specification registers 'routingcost' as a generic measure for
	.---------. / | ^ ^ | Tracker |		routing traffic from a source to a destination. In a similar way the
	| Peer 1 | <-------------- | | \ `---------'		ALTO Endpoint Property Registry ensures uniquenes of ALTO Endpoint
	`---------' | (1) Gather Peers		Property identifiers and provides references to particular semantics
	. (3) Connect to | | \		of the allocated Enpoint Properties. Currently the 'pid' identifier
	. Selected Peers / .--------. .--------.		is registered, which serves as an identifier that allows aggregation
	.---------. / | P2P | | DHT |		of network endpoints into network regions. Both registries accept
	| Peer 50 | <---------------- | Client | `--------'		new entries after Expert Review [[ID-alto-protocol]]. New entries
	`---------' | (PEX) |		are requested to be conform to the respective syntactical
	`--------'		requirements, and must include information about the new identifier,
	Figure 1:example scenario in the last IETF ALTO protocol draft, where the		the intended semantics as well as security considerations.
	ALTO client is embedded in the P2P Client
	Figure 2 depicts the features and mechanisms added to the current		The current protocol specification concentrates on the basic use case
	ALTO scenario for Multi-Cost ALTO services, for the use case of		of optimizing routing costs in NSPs networks. Upcoming use cases
	Figure 1. The EPs have already been discovered. In this figure, the		however will require both, new Cost Types and new Endpoint
	term Peer is replaced by the term Endpoint (EP), the term P2P Client		Properties. The goal of this section is to describe further forward
	by Application Client and an Endpoint Tracker for resource Sharing		looking use case scenarios that are likely to benefit from ALTO, and,
	Applications is added to the tools involved in Step (1) Gather		in future iterations, to convey new Cost Types and Endpoint
	Endpoints .		Properties that are likely to be beneficial for ALTO clients in these
			scenarios.
	We focus on the ALTO use case where the ALTO client is co-located		5.1. Delay Sensitive Overlay Applications
	with an Application client in a terminal node, as not all P2P systems
	use a P2P tracker for peer discovery and selection as written in
	section 9.2 of [ID-alto-protocol6]. In Figure 2, the entity called
	P2P Client mentionned in the current protocol draft is zoomed to an
	entity called in this draft "Client Block" and that links: the
	Application Client (AC), its ALTO Client and the Traffic Engineered
	EP Optimization Tool (TEEPOT).
	(3) Get EP Cost Client Block		The ALTO working group has been created to allow P2P applications and
	Cost Types=Hops,EP-mem __________________________________________________		NSPs a mutual cooperation, in particular because P2P bulk file-
	.---------. | .---------------. |		transfer applications have created a huge amount of intra-domain
	| ALTO | <-------------------> | | ALTO Client | ---------------. |		traffic. By aligning overlay topologies according to the
	| Server | | `---------------' <----. (4.a) Send EP cost |		'routingcost' of the underlying network both layers are expected to
	| | | ^ (2.c)Send list of | vectors |		benefit in terms of reduced costs and improved Quality-of-Experience.
	`---------' | | Cost Types | v |
	| | .---------------. |
	|(2.a)Send list of EPs | TEEPOT | |
	| | `---------------' |
	| | ^ (4.b)Send selected |
	| | (2.b)Send EP Specs. and ranked EPs |
	| .---------------. -------' | |
	| |Appl. Client | <---------------' |
	| `---------------' |
	|__/_|______^______________________________________|
	.---------. / | |
	| EP 1 | <-------------- | |
	`---------' | (1) Gather Endpoints (EPs)
	. (5) Connect to | |
	. Selected Endpoints / .-------------------.
	.---------. / | PEX |
	| EP 50 | <---------------' | Endpoint Tracker |
	`---------' | DHT |
	`-------------------'
	Figure 2: features and mechanisms added to the current ALTO scenario for		However other types of overlay applications might benefit from a
	Multi-Cost ALTO services		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.
	The use case in Figure 2 proceeds as follows:		5.2. CDN Surrogate Selection
	1. The Application Client discovers Endpoints (EPs) from sources		A second use case is motivated through draft
	such as Peer Exchange (PEX) from other P2P Clients, Distributed		[draft-jenkins-alto-cdn-use-cases-01]. The request router in today's
	Hash Tables (DHT), P2P Trackers or other types of EP trackers.		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.
	2. In the "Client Block" gathering the Application Client (AC), its		While distance today is the predominant metric used for routing
	ALTO Client and the Traffic Engineered EP Optimization Tool		decisions, other metrics might allow sophisticated request routing
	(TEEPOT):		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.
	A. the Application Client (AC) sends to the ALTO Client the list		6. Proposed additional Properties and Costs
	of the discovered peers as the set of Destination Endpoints.
	B. the Application Client (AC) sends to the TEEPOT the		To be further specified
	specifications on the EPs to select, according to the needs
	of the application. For example, AC needs 3 EPs, with 1 EP
	optimizing the Path Length Metric and 2 EPs optimizing the
	Path Length and the EP Memory Capacity Score, with respective
	weights of 0.4 and 0.6.
	C. the TEEPOT indicates to the ALTO Client that the Service to		6.1. Scoping ALTO information
	request is EP Cost, with the Cost Mode set to "Numerical",
	and the Cost Dimension equal to the number of requested
	metrics and with the index of the requested Cost Types.
	3. The ALTO Client queries the ALTO Server's EP Cost Service, sends		One way for the NSP to provide guidance on highly dynamic network
	the list of the discovered peers as the set of Destination		state information such as delay and load is to provide them in the
	Endpoints and the index of requested metrics, corresponding in		form of statistics or as a numerical coarse grain indicator. It is
	this example to: "Path Length" and "EP Memory Capacity Score".		important to have the possibility to reflect that the provided values
	As the number of requested metrics is > 1, the Cost Mode is		are applicable for a given time period, for example business hours,
	implicitely set to 'numerical'. The ALTO Server response		and are subject to changes over time.
	contains the set of metric values associated to each EP.
	4. In the Client block:		The following attributes can be associated to the applicable ALTO
			information:
	A. The ALTO Client hands to the TEEPOT the list of EPs and their		o an age attribute indicating when the information was generated.
	associated value set.
	B. The TEEPOT ranks the EPs with some smart algorithm, given the		o for statistical costs a time period attribute indicating over
	metric weights and then sends the ranked list to the		which duration the statistics were collected.
	Application Client.
	5. The Application Client connects to the selected EPs.		o a validity attribute indicating when the provided values should be
			refreshed. By defaut, this parameter can be set to infinity.
	7. IANA Considerations		7. IANA Considerations
	The current ALTO protocol version includes a Section 11 entitled IANA		Information for the ALTO Endpoint property registry maintained by the
	considerations, where the ALTO Cost Type registry is defined in		IANA and related to the new Endpoints supported by the acting ALTO
	Section 11.2		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		7.1. Information for IANA on proposed Cost Types
	When a new ALTO Cost Type is defined, accepted by the ALTO working		When a new ALTO Cost Type is defined, accepted by the ALTO working
	group and requests for IANA registration MUST include the following		group and requests for IANA registration MUST include the following
	information, detailed in Section 11.2: Identifier, Intended		information, detailed in Section 11.2: Identifier, Intended
	Semantics, Security Considerations.		Semantics, Security Considerations.
	7.2. Information for IANA on proposed Endpoint Propeeries		7.2. Information for IANA on proposed Endpoint Propeeries
	Likewise, an ALTO Endpoint Property Registry could serve the same		Likewise, an ALTO Endpoint Property Registry could serve the same
	purposes as the ALTO Cost Type registry. Application to IANA		purposes as the ALTO Cost Type registry. Application to IANA
	registration for Endpoint Properties would follow a similar process.		registration for Endpoint Properties would follow a similar process.
	8. Acknowledgements		8. Acknowledgements
	Thank you to Richard Alimi whose reviewing of the previous version of		Sabine Randriamasy is partially supported by the MEDIEVAL project
	this draft and advises provided a valuable input to its updates.		(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
			(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. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5693] "Application Layer Traffic Optimization (ALTO) Problem		[RFC5693] "Application Layer Traffic Optimization (ALTO) Problem
	Statement", October 2009.		Statement", October 2009.
	9.2. Informative References		9.2. Informative References
	[ID-ALTO-Requirements]
	"draft-ietf-alto-reqs-05.txt", June 2010.
	[ID-ALTO-Requirements7]		[ID-ALTO-Requirements7]
	"draft-ietf-alto-reqs-07.txt", January 2011.		"draft-ietf-alto-reqs-07.txt", January 2011.
	[ID-alto-protocol5]		[ID-alto-protocol]
	""ALTO Protocol" draft-ietf-alto-protocol-05.txt",		, Eds., ""ALTO Protocol" draft-ietf-alto-protocol-09.txt",
	July 2010.		June 2011.
	[ID-alto-protocol6]		[draft-jenkins-alto-cdn-use-cases-01]
	, eds., ""ALTO Protocol" draft-ietf-alto-protocol-06.txt",		""Use Cases for ALTO within CDNs"
	October 2010.		draft-jenkins-alto-cdn-use-cases-01", June 2011.
	Author's Address		Authors' Addresses
	Sabine Randriamasy (editor)		Sabine Randriamasy (editor)
	Alcatel-Lucent Bell Labs		Alcatel-Lucent Bell Labs
	Route de Villejust		Route de Villejust
	NOZAY 91460		NOZAY 91460
	FRANCE		FRANCE
	Email: Sabine.Randriamasy@alcatel-lucent.com		Email: Sabine.Randriamasy@alcatel-lucent.com
			Nico Schwan
			Phone:
			Fax:
			Email:
			URI:
End of changes. 79 change blocks.
	412 lines changed or deleted		249 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/