< draft-stiemerling-alto-deployments-04.txt		draft-stiemerling-alto-deployments-05.txt >
	ALTO M. Stiemerling		ALTO M. Stiemerling
	Internet-Draft NEC Europe Ltd.		Internet-Draft NEC Europe Ltd.
	Intended status: Standards Track S. Kiesel		Intended status: Informational S. Kiesel
	Expires: January 13, 2011 University of Stuttgart		Expires: April 28, 2011 University of Stuttgart
	July 12, 2010		October 25, 2010
	ALTO Deployment Considerations		ALTO Deployment Considerations
	draft-stiemerling-alto-deployments-04		draft-stiemerling-alto-deployments-05
	Abstract		Abstract
	Many Internet applications are used to access resources, such as		Many Internet applications are used to access resources, such as
	pieces of information or server processes, which are available in		pieces of information or server processes, which are available in
	several equivalent replicas on different hosts. This includes, but		several equivalent replicas on different hosts. This includes, but
	is not limited to, peer-to-peer file sharing applications. The goal		is not limited to, peer-to-peer file sharing applications. The goal
	of Application-Layer Traffic Optimization (ALTO) is to provide		of Application-Layer Traffic Optimization (ALTO) is to provide
	guidance to these applications, which have to select one or several		guidance to these applications, which have to select one or several
	hosts from a set of candidates, that are able to provide a desired		hosts from a set of candidates, that are able to provide a desired
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 January 13, 2011.		This Internet-Draft will expire on April 28, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Using ALTO for Peer-to-Peer . . . . . . . . . . . . . . . . . 7		2.1. General Placement of ALTO . . . . . . . . . . . . . . . . 4
	3.1. Expectations of ALTO . . . . . . . . . . . . . . . . . . . 9		2.2. Provided Guidance . . . . . . . . . . . . . . . . . . . . 6
	4. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 11		2.2.1. Keeping Traffic Local in Network . . . . . . . . . . . 6
	5. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . . . 12		2.2.2. Off-Loading Traffic from Network . . . . . . . . . . . 7
	6. Known Limitations of ALTO . . . . . . . . . . . . . . . . . . 14		2.2.3. Intra-Network Localization/Bottleneck Off-Loading . . 8
	6.1. Limitations of Map-based Approaches . . . . . . . . . . . 14		3. Using ALTO for Peer-to-Peer . . . . . . . . . . . . . . . . . 11
	6.2. Limitiations of Non-Map-based Approaches . . . . . . . . . 15		3.1. Using ALTO for Tracker-based Peer-to-Peer Applications . . 13
	6.3. General Challenges . . . . . . . . . . . . . . . . . . . . 15		3.2. Expectations of ALTO . . . . . . . . . . . . . . . . . . . 15
	7. API between ALTO Client and Application . . . . . . . . . . . 17		4. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		5. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . . . 17
	8.1. Information Leakage from the ALTO Server . . . . . . . . . 18		6. Known Limitations of ALTO . . . . . . . . . . . . . . . . . . 19
	8.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 18		6.1. Limitations of Map-based Approaches . . . . . . . . . . . 19
	8.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 19		6.2. Limitiations of Non-Map-based Approaches . . . . . . . . . 20
	9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20		6.3. General Challenges . . . . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		7. API between ALTO Client and Application . . . . . . . . . . . 22
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 21		8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10.2. Informative References . . . . . . . . . . . . . . . . . . 21		8.1. Information Leakage from the ALTO Server . . . . . . . . . 23
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23		8.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24		8.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 24
			9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
			10.2. Informative References . . . . . . . . . . . . . . . . . . 26
			Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	Many Internet applications are used to access resources, such as		Many Internet applications are used to access resources, such as
	pieces of information or server processes, which are available in		pieces of information or server processes, which are available in
	several equivalent replicas on different hosts. This includes, but		several equivalent replicas on different hosts. This includes, but
	is not limited to, peer-to-peer file sharing applications and Content		is not limited to, peer-to-peer file sharing applications and Content
	Delivery Networks (CDNs). The goal of Application-Layer Traffic		Delivery Networks (CDNs). The goal of Application-Layer Traffic
	Optimization (ALTO) is to provide guidance to applications, which		Optimization (ALTO) is to provide guidance to applications, which
	have to select one or several hosts from a set of candidates, that		have to select one or several hosts from a set of candidates, that
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	`--. | _.-'		`--. | _.-'
	`------|-----''		`------|-----''
	v		v
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	| ALTO | | ALTO |...| ALTO |		| ALTO | | ALTO |...| ALTO |
	| Client | | Client | | Client |		| Client | | Client | | Client |
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	Figure 1: Network Overview of ALTO Protocol		Figure 1: Network Overview of ALTO Protocol
			2.1. General Placement of ALTO
	The ALTO server and ALTO clients can be situated at various entities		The ALTO server and ALTO clients can be situated at various entities
	in a network deployment. The first differentiation is whether the		in a network deployment. The first differentiation is whether the
	ALTO client is located on the actual host that runs the application,		ALTO client is located on the actual host that runs the application,
	as shown in Figure 2, (e.g., peer-to-peer filesharing application) or		as shown in Figure 2, (e.g., peer-to-peer filesharing application) or
	if the ALTO client is located on resource directory, as shown in		if the ALTO client is located on resource directory, as shown in
	Figure 3 (e.g., a tracker in peer-to-peer filesharing).		Figure 3 (e.g., a tracker in peer-to-peer filesharing).
	+-----+		+-----+
	=====| |**		=====| |**
	==== +-----+ *		==== +-----+ *
	skipping to change at page 7, line 5 ¶		skipping to change at page 6, line 34 ¶
	Figure 3: Overview of protocol interaction between ALTO elements,		Figure 3: Overview of protocol interaction between ALTO elements,
	scenario with tracker		scenario with tracker
	However, Figure 3 does not denote where the ALTO elements are		However, Figure 3 does not denote where the ALTO elements are
	actually located, i.e., if the tracker and the ALTO server are in the		actually located, i.e., if the tracker and the ALTO server are in the
	same ISP's domain, or if the tracker and the ALTO server are managed/		same ISP's domain, or if the tracker and the ALTO server are managed/
	owned/located in different domains. The latter is the typical use		owned/located in different domains. The latter is the typical use
	case, e.g., taking Pirate Bay as example that serves Bittorrent peers		case, e.g., taking Pirate Bay as example that serves Bittorrent peers
	world-wide.		world-wide.
	3. Using ALTO for Peer-to-Peer		2.2. Provided Guidance
	This section discuss where the ALTO server can be placed and which		ALTO gives guidance to applications on what IP addresses or IP
	entities are querying the ALTO server from what ALTO client. The		prefixes, and such which hosts are to be preferred according to the
	section assumes a P2P system relying a tracker to initially find		operator of the ALTO server. The general assumption of the ALTO WG
	other peers. However, the tracker can be replaced by any other		is that a network operator would always express to prefer hosts in
	database that provides a rendezvous point for an application. The		its own network while hosts located outside its own network are to be
	limitation to a tracker is made for educational purpose, i.e. to ease		avoided (are undesired to be considered by the applications). This
	the general understanding.		might be applicable in some cases but may not be applicable in the
			general case. The ALTO protocol gives only the means to let the ALTO
			server operator to express is preference, whatever this preference
			is. This section explores this space.
			2.2.1. Keeping Traffic Local in Network
			ALTO guidance can be used to let applications prefer other peers
			within the same network operator's network instead of randomly
			connecting to other peers which are located in another operator's
			network. Figure 4 shows such a scenario where peers prefer peers in
			the same network (e.g., Peer 1 and Peer 2 in ISP1 and Peer 3 and Peer
			4 in ISP2).
			,-------. +-----------+
			,---. ,-' `-. | Peer 1 |
			,-' `-. / ISP 1 ########|ALTO Client|
			/ \ / # \ +-----------+
			/ ISP X \ | # | +-----------+
			/ \ \ ########| Peer 2 |
			; +----------------------------|ALTO Client|
			| | | `-. ,-' +-----------+
			| | | `-------'
			| | | ,-------. +-----------+
			: | ; ,-' `########| Peer 3 |
			\ | / / ISP 2 # \ |ALTO Client|
			\ | / / # \ +-----------+
			\ +---------+ # | +-----------+
			`-. ,-' \ | ########| Peer 4 |
			`---' \ +------------------|ALTO Client|
			`-. ,-' +-----------+
			`-------'
			Legend:
			### preferred "connections"
			--- non-preferred "connections"
			Figure 4: ALTO Traffic Network Localization
			TBD: Describes limits of this approach (e.g., traffic localization
			guidance is of less use if the peers cannot upload); describe how
			maps would look like.
			2.2.2. Off-Loading Traffic from Network
			Another scenario where the use of ALTO can be beneficial is in mobile
			broadband networks, e.g., CDMA200 or UMTS, but where the network
			operator may have the desire to guide peers in its own network to use
			peers in remote networks. One reason can be that the wireless
			network is not made for the load cause by, e.g., peer-to-peer
			applications, and the operator has the need that peers fetch their
			data from remote peers in other parts of the Internet.
			,-------. +-----------+
			,---. ,-' `-. | Peer 1 |
			,-' `-. / ISP 1 +-------|ALTO Client|
			/ \ / | \ +-----------+
			/ ISP X \ | | | +-----------+
			/ \ \ +-------| Peer 2 |
			; #-###########################|ALTO Client|
			| # | `-. ,-' +-----------+
			| # | `-------'
			| # | ,-------. +-----------+
			: # ; ,-' `+-------| Peer 3 |
			\ # / / ISP 2 | \ |ALTO Client|
			\ # / / | \ +-----------+
			\ ########### | | +-----------+
			`-. ,-' \ # +-------| Peer 4 |
			`---' \ ###################|ALTO Client|
			`-. ,-' +-----------+
			`-------'
			Legend:
			=== preferred "connections"
			--- non-preferred "connections"
			Figure 5: ALTO Traffic Network De-Localization
			Figure 5 shows the result of such a guidance process where Peer 2
			prefers a connection with Peer4 instead of Peer 1, as shown in
			Figure 4.
			TBD: Limits of this approach in general and with respect to p2p.
			describe how maps would look like.
			2.2.3. Intra-Network Localization/Bottleneck Off-Loading
			The above sections described the results of the ALTO guidance on an
			inter-network level. However, ALTO can also be used to guide peers
			on which internal peers are to be preferred. For instance, to guide
			Peers on a remote network side to prefer to connect to each other,
			instead of crossing a bottleneck link, a backhaul link to connect the
			side to the network core. Figure 6 shows such a scenario where Peer
			1 and Peer 2 are located in Net 2 of ISP1 and connect via a low
			capacity link to the core (Net 1) of the same ISP1. Peer1 and Peer 2
			would both exchange their data with remote peers, probably clogging
			the bottleneck link.
			,-------. +-----------+
			,---. ,-' `-. | Peer 1 |
			,-' `-. / ISP 1 #########|ALTO Client|
			/ \ / Net 2 # \ +-----------+
			/ ISP 1 \ | ######### | +-----------+
			/ Net 1 \ \ # / | Peer 2 |
			; ###; \ # ##########|ALTO Client|
			| X~~~~~~~~~~~~X#######,-' +-----------+
			| ### | ^ `-------'
			| | |
			: ; |
			\ / Bottleneck
			\ /
			\ /
			`-. ,-'
			`---'
			Legend:
			### peer "connections"
			~~~ bottleneck link
			Figure 6: Without Intra-Network ALTO Traffic Localization
			The operator can guide the peers in such a situation to try first
			local peers in the same network islands, avoiding or at least
			lowering the effect on the bottleneck link, as shown in Figure 7.
			,-------. +-----------+
			,---. ,-' `-. | Peer 1 |
			,-' `-. / ISP 1 #########|ALTO Client|
			/ \ / Net 2 # \ +-----------+
			/ ISP 1 \ | # | +-----------+
			/ Net 1 \ \ #########| Peer 2 |
			; ; \ ##########|ALTO Client|
			| #~~~~~~~~~~~########,-' +-----------+
			| ### | ^ `-------'
			| | |
			: ; |
			\ / Bottleneck
			\ /
			\ /
			`-. ,-'
			`---'
			Legend:
			### peer "connections"
			~~~ bottleneck link
			Figure 7: With Intra-Network ALTO Traffic Localization
			TBD: describe how maps would look like.
			3. Using ALTO for Peer-to-Peer
	,-------.		,-------.
	,---. ,-' `-. +-----------+		,---. ,-' `-. +-----------+
	,-' `-. / ISP 1 \ | Peer 1 |*****		,-' `-. / ISP 1 \ | Peer 1 |*****
	/ \ / +-------------+ \ | | *		/ \ / +-------------+ \ | | *
	/ ISP X \ +=====>+ ALTO Server | )+-----------+ *		/ ISP X \ +=====>+ ALTO Server | )+-----------+ *
	/ \ = \ +-------------+ / +-----------+ *		/ \ = \ +-------------+ / +-----------+ *
	; +-----------+ : = \ / | Peer 2 | *		; +-----------+ : = \ / | Peer 2 | *
	| | Tracker |<====+ `-. ,-' | |*****		| | Tracker |<====+ `-. ,-' | |*****
	| |ALTO Client|<====+ `-------' +-----------+ **		| |ALTO Client|<====+ `-------' +-----------+ **
	| +-----------+ | = ,-------. **		| +-----------+ | = ,-------. **
	skipping to change at page 7, line 39 ¶		skipping to change at page 11, line 31 ¶
	`-*-' \ / | Peer 4 |*****		`-*-' \ / | Peer 4 |*****
	* `-. ,-' | | ****		* `-. ,-' | | ****
	* `-------' +-----------+ ****		* `-------' +-----------+ ****
	* ****		* ****
	* ****		* ****
	***********************************************<******		***********************************************<******
	Legend:		Legend:
	=== ALTO client protocol		=== ALTO client protocol
	*** Application protocol		*** Application protocol
	Figure 4: Global tracker accessing ALTO server at various ISPs		Figure 8: Global tracker accessing ALTO server at various ISPs
	Figure 4 depicts a tracker-based system, where the tracker embeds the		Figure 8 depicts a tracker-based system, where the tracker embeds the
	ALTO client. The tracker itself is hosted and operated by an entity		ALTO client. The tracker itself is hosted and operated by an entity
	different than the ISP hosting and operating the ALTO server.		different than the ISP hosting and operating the ALTO server.
	Initially, the tracker has to look-up the ALTO server in charge for		Initially, the tracker has to look-up the ALTO server in charge for
	each peer where it receives a ALTO query for. Therefore, the ALTO		each peer where it receives a ALTO query for. Therefore, the ALTO
	server has to discover the handling ALTO server, as described in		server has to discover the handling ALTO server, as described in
	[I-D.kiesel-alto-3pdisc]. However, the peers do not have any way to		[I-D.kiesel-alto-3pdisc]. However, the peers do not have any way to
	query the server themselves. This setting allows to give the peers a		query the server themselves. This setting allows to give the peers a
	better selection of candidate peers for their operation at an initial		better selection of candidate peers for their operation at an initial
	time, but does not consider peers learned through direct peer-to-peer		time, but does not consider peers learned through direct peer-to-peer
	knowledge exchange, AKA peer exchange in various peer-to-peer		knowledge exchange, AKA peer exchange in various peer-to-peer
	skipping to change at page 8, line 29 ¶		skipping to change at page 12, line 29 ¶
	`-. * ,-' \ +-------------+ /= | Peer 4 |*****		`-. * ,-' \ +-------------+ /= | Peer 4 |*****
	`-*-' \ / +==>|ALTO Client| ****		`-*-' \ / +==>|ALTO Client| ****
	* `-. ,-' +-----------+ ****		* `-. ,-' +-----------+ ****
	* `-------' ****		* `-------' ****
	* ****		* ****
	***********************************************<****		***********************************************<****
	Legend:		Legend:
	=== ALTO client protocol		=== ALTO client protocol
	*** Application protocol		*** Application protocol
	Figure 5: Global Tracker - Local ALTO Servers		Figure 9: Global Tracker - Local ALTO Servers
	The scenario in Figure 5 lets the peers directly communicate with		The scenario in Figure 9 lets the peers directly communicate with
	their ISP's ALTO server (i.e., ALTO client embedded in the peers),		their ISP's ALTO server (i.e., ALTO client embedded in the peers),
	giving thus the peers the most control on which information they		giving thus the peers the most control on which information they
	query for, as they can integrate information received from trackers		query for, as they can integrate information received from trackers
	and through direct peer-to-peer knowledge exchange.		and through direct peer-to-peer knowledge exchange.
	,-------. +-----------+		,-------. +-----------+
	,---. ,-' ISP 1 `-. ***>| Peer 1 |		,---. ,-' ISP 1 `-. ***>| Peer 1 |
	,-' `-. /+-------------+\ * | |		,-' `-. /+-------------+\ * | |
	/ \ / + Tracker |<** +-----------+		/ \ / + Tracker |<** +-----------+
	/ ISP X \ | +-----===-----+<** +-----------+		/ ISP X \ | +-----===-----+<** +-----------+
	skipping to change at page 9, line 29 ¶		skipping to change at page 13, line 29 ¶
	`-. *,-' | +-----===-----+ | | Peer 4 |<*		`-. *,-' | +-----===-----+ | | Peer 4 |<*
	`---* \ +-----===-----+ / | | *		`---* \ +-----===-----+ / | | *
	* \+ ALTO Server |/ +-----------+ *		* \+ ALTO Server |/ +-----------+ *
	* +-------------+ *		* +-------------+ *
	* `-------' *		* `-------' *
	***********************************************		***********************************************
	Legend:		Legend:
	=== ALTO client protocol		=== ALTO client protocol
	*** Application protocol		*** Application protocol
	Figure 6: P4P approach with local tracker and local ALTO server		Figure 10: P4P approach with local tracker and local ALTO server
	There are some attempts to let ISP's to deploy their own trackers, as		There are some attempts to let ISP's to deploy their own trackers, as
	shown in Figure 6. In this case, the client has no chance to get		shown in Figure 10. In this case, the client has no chance to get
	guidance from the ALTO server, other than talking to the ISP's		guidance from the ALTO server, other than talking to the ISP's
	tracker. However, the peers would have still chance the contact		tracker. However, the peers would have still chance the contact
	other trackers, deployed by entities other than the peer's ISP.		other trackers, deployed by entities other than the peer's ISP.
	Figure 6 and Figure 4 ostensibly take peers the possibility to		Figure 10 and Figure 8 ostensibly take peers the possibility to
	directly query the ALTO server, if the communication with the ALTO		directly query the ALTO server, if the communication with the ALTO
	server is not permitted for any reason. However, considering the		server is not permitted for any reason. However, considering the
	plethora of different applications of ALTO, e.g., multiple tracker		plethora of different applications of ALTO, e.g., multiple tracker
	and non-tracker based P2P systems and or applications searching for		and non-tracker based P2P systems and or applications searching for
	relays, it seems to be beneficial for all participants to let the		relays, it seems to be beneficial for all participants to let the
	peers directly query the ALTO server. The peers are also the single		peers directly query the ALTO server. The peers are also the single
	point having all operational knowledge to decide whether to use the		point having all operational knowledge to decide whether to use the
	ALTO guidance and how to use the ALTO guidance. This is a preference		ALTO guidance and how to use the ALTO guidance. This is a preference
	for the scenario depicted in Figure Figure 5.		for the scenario depicted in Figure Figure 9.
	3.1. Expectations of ALTO		3.1. Using ALTO for Tracker-based Peer-to-Peer Applications
			............................. .............................
			: Tracker : : Peer :
			: ______ : : :
			: +-______-+ : : k good :
			: | | +--------+ : P2P App. : +--------+ peers +------+ :
			: | N | | random | : Protocol : | ALTO- |------>| data | :
			: | known |====>| pre- |*************>| biased | | ex- | :
			: | peers, | | selec- | : transmit : | peer |------>| cha- | :
			: | M good | | tion | : n peer : | select | n-k | nge | :
			: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :
			:...........................: :.....^.....................:
			|
			| ALTO
			| client protocol
			__|___
			+-______-+
			| |
			| ALTO |
			| server |
			+-______-+
			Figure 11: Tracker-based P2P Application with random peer
			preselection
			............................. .............................
			: Tracker : : Peer :
			: ______ : : :
			: +-______-+ : : :
			: | | +--------+ : P2P App. : k good peers & +------+ :
			: | N | | ALTO- | : Protocol : n-k bad peers | data | :
			: | known |====>| biased |******************************>| ex- | :
			: | peers, | | peer | : transmit : | cha- | :
			: | M good | | select | : n peer : | nge | :
			: +-______-+ +--------+ : IDs : +------+ :
			:.....................^.....: :...........................:
			|
			| ALTO
			| client protocol
			__|___
			+-______-+
			| |
			| ALTO |
			| server |
			+-______-+
			Figure 12: Tracker-based P2P Application with ALTO client in tracker
			TBD: explain why Figure 12 usually will yield better results wrt.
			peer selection than Figure 11.
			3.2. Expectations of ALTO
	This section hints to some recent experiments conducted with ALTO-		This section hints to some recent experiments conducted with ALTO-
	like deployments in Internet Service Provider (ISP) network's. NTT		like deployments in Internet Service Provider (ISP) network's. NTT
	performed tests with their HINT server implementation and dummy nodes		performed tests with their HINT server implementation and dummy nodes
	to gain insight on how an ALTO-like service influence a peer-to-peer		to gain insight on how an ALTO-like service influence a peer-to-peer
	systems [I-D.kamei-p2p-experiments-japan]. The results of an early		systems [I-D.kamei-p2p-experiments-japan]. The results of an early
	experiment conducted in the Comcast network are documented		experiment conducted in the Comcast network are documented
	here[RFC5632]		here[RFC5632]
	4. Using ALTO for CDNs		4. Using ALTO for CDNs
	skipping to change at page 12, line 10 ¶		skipping to change at page 17, line 10 ¶
	cache. This matching is not trivial, for instance, in DNS based		cache. This matching is not trivial, for instance, in DNS based
	approaches, where the IP address of the DNS original requester is		approaches, where the IP address of the DNS original requester is
	unknown (see [I-D.vandergaast-edns-client-ip] for a discussion of		unknown (see [I-D.vandergaast-edns-client-ip] for a discussion of
	this and a solution approach).		this and a solution approach).
	5. Cascading ALTO Servers		5. Cascading ALTO Servers
	The main assumptions of ALTO seems to be each ISP operates its own		The main assumptions of ALTO seems to be each ISP operates its own
	ALTO server independently, irrespectively of the ISP's situation.		ALTO server independently, irrespectively of the ISP's situation.
	This may true for most envisioned deployments of ALTO but there are		This may true for most envisioned deployments of ALTO but there are
	certain deployments that may have different settings. Figure 7 shows		certain deployments that may have different settings. Figure 13
	such setting, were for example, a university network is connected to		shows such setting, were for example, a university network is
	two upstream providers. ISP2 if the national research network and		connected to two upstream providers. ISP2 if the national research
	ISP1 is a commercial upstream provider to this university network.		network and ISP1 is a commercial upstream provider to this university
	The university, as well as ISP1, are operating their own ALTO server.		network. The university, as well as ISP1, are operating their own
	The ALTO clients, located on the peers will contact the ALTO server		ALTO server. The ALTO clients, located on the peers will contact the
	located at the university.		ALTO server located at the university.
	+-----------+		+-----------+
	| ISP1 |		| ISP1 |
	| ALTO |		| ALTO |
	| Server |		| Server |
	+----------=+		+----------=+
	,-------= ,------.		,-------= ,------.
	,-' =`-. ,-' `-.		,-' =`-. ,-' `-.
	/ Upstream= \ / Upstream \		/ Upstream= \ / Upstream \
	( ISP1 = ) ( ISP2 )		( ISP1 = ) ( ISP2 )
	skipping to change at page 12, line 44 ¶		skipping to change at page 17, line 44 ¶
	,' University `. |University |		,' University `. |University |
	( Network ) | ALTO |		( Network ) | ALTO |
	`. =======================| Server |		`. =======================| Server |
	`-= +-' +-----------+		`-= +-' +-----------+
	=`+------------'|		=`+------------'|
	= | |		= | |
	+--------+-+ +-+--------+		+--------+-+ +-+--------+
	| Peer1 | | PeerN |		| Peer1 | | PeerN |
	+----------+ +----------+		+----------+ +----------+
	Figure 7: Cascaded ALTO Server		Figure 13: Cascaded ALTO Server
	In this setting all "destinations" useful for the peers within ISP2		In this setting all "destinations" useful for the peers within ISP2
	are free-of-charge for the peers located in the university network		are free-of-charge for the peers located in the university network
	(i.e., they are preferred in the rating of the ALTO server).		(i.e., they are preferred in the rating of the ALTO server).
	However, all traffic that is not towards ISP2 will be handled by the		However, all traffic that is not towards ISP2 will be handled by the
	ISP1 upstream provider. Therefore, the ALTO server at the university		ISP1 upstream provider. Therefore, the ALTO server at the university
	has also to include the guidance given by the ISP1 ALTO server in its		has also to include the guidance given by the ISP1 ALTO server in its
	replies to the ALTO clients. This can be called cascaded ALTO		replies to the ALTO clients. This can be called cascaded ALTO
	servers.		servers.
	skipping to change at page 18, line 40 ¶		skipping to change at page 23, line 40 ¶
	one or multiple peers are querying an ALTO server with the goal to		one or multiple peers are querying an ALTO server with the goal to
	gather information about network topology or any other data		gather information about network topology or any other data
	considered confidential or at least sensitive. It is unclear whether		considered confidential or at least sensitive. It is unclear whether
	this is a real technical security risk or whether this is more a		this is a real technical security risk or whether this is more a
	perceived security risk.		perceived security risk.
	8.2. ALTO Server Access		8.2. ALTO Server Access
	Depending on the use case of ALTO, several access restrictions to an		Depending on the use case of ALTO, several access restrictions to an
	ALTO server may or may not apply. For an ALTO server that is solely		ALTO server may or may not apply. For an ALTO server that is solely
	accessible by peers from the ISP network (as shown in Figure 5), for		accessible by peers from the ISP network (as shown in Figure 9), for
	instance, the source IP address can be used to grant only access from		instance, the source IP address can be used to grant only access from
	that ISP network to the server. This will "limit" the number of		that ISP network to the server. This will "limit" the number of
	peers able to attack the server to the user's of the ISP (however,		peers able to attack the server to the user's of the ISP (however,
	including botnet computers).		including botnet computers).
	On the other hand, if the ALTO server has to be accessible by parties		On the other hand, if the ALTO server has to be accessible by parties
	not located in the ISP's network (see Figure Figure 4), e.g., by a		not located in the ISP's network (see Figure Figure 8), e.g., by a
	third-party tracker or by a CDN system outside the ISP's network, the		third-party tracker or by a CDN system outside the ISP's network, the
	access restrictions have to be more loose. In the extreme case,		access restrictions have to be more loose. In the extreme case,
	i.e., no access restrictions, each and every host in the Internet can		i.e., no access restrictions, each and every host in the Internet can
	access the ALTO server. This might no the intention of the ISP, as		access the ALTO server. This might no the intention of the ISP, as
	the server is not only subject to more possible attacks, but also on		the server is not only subject to more possible attacks, but also on
	the load imposed to the server, i.e., possibly more ALTO clients to		the load imposed to the server, i.e., possibly more ALTO clients to
	serve and thus more work load.		serve and thus more work load.
	8.3. Faking ALTO Guidance		8.3. Faking ALTO Guidance
	skipping to change at page 21, line 20 ¶		skipping to change at page 26, line 20 ¶
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known		[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
	Content Network (CN) Request-Routing Mechanisms",		Content Network (CN) Request-Routing Mechanisms",
	RFC 3568, July 2003.		RFC 3568, July 2003.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-alto-protocol]		[I-D.ietf-alto-protocol]
	Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",		Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
	draft-ietf-alto-protocol-04 (work in progress), May 2010.		draft-ietf-alto-protocol-05 (work in progress), July 2010.
	[I-D.ietf-alto-reqs]		[I-D.ietf-alto-reqs]
	Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and		Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
	Y. Yang, "Application-Layer Traffic Optimization (ALTO)		Y. Yang, "Application-Layer Traffic Optimization (ALTO)
	Requirements", draft-ietf-alto-reqs-05 (work in progress),		Requirements", draft-ietf-alto-reqs-06 (work in progress),
	June 2010.		October 2010.
	[I-D.kamei-p2p-experiments-japan]		[I-D.kamei-p2p-experiments-japan]
	Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO-		Kamei, S., Momose, T., Inoue, T., and T. Nishitani, "ALTO-
	Like Activities and Experiments in P2P Network Experiment		Like Activities and Experiments in P2P Network Experiment
	Council", draft-kamei-p2p-experiments-japan-03 (work in		Council", draft-kamei-p2p-experiments-japan-03 (work in
	progress), May 2010.		progress), May 2010.
	[I-D.kiesel-alto-3pdisc]		[I-D.kiesel-alto-3pdisc]
	Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M.		Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M.
	Stiemerling, "Third-party ALTO server discovery",		Stiemerling, "Third-party ALTO server discovery",
	draft-kiesel-alto-3pdisc-03 (work in progress), July 2010.		draft-kiesel-alto-3pdisc-03 (work in progress), July 2010.
	[I-D.kiesel-alto-h12]		[I-D.kiesel-alto-h12]
	Kiesel, S. and M. Stiemerling, "ALTO H12",		Kiesel, S. and M. Stiemerling, "ALTO H12",
	draft-kiesel-alto-h12-02 (work in progress), March 2010.		draft-kiesel-alto-h12-02 (work in progress), March 2010.
	[I-D.penno-alto-cdn]		[I-D.penno-alto-cdn]
	Penno, R., Raghunath, S., Medved, J., Bakshi, M., Alimi,		Penno, R., Raghunath, S., Medved, J., Bakshi, M., Alimi,
	R., and S. Previdi, "ALTO and Content Delivery Networks",		R., and S. Previdi, "ALTO and Content Delivery Networks",
	draft-penno-alto-cdn-00 (work in progress), June 2010.		draft-penno-alto-cdn-01 (work in progress), July 2010.
	[I-D.vandergaast-edns-client-ip]		[I-D.vandergaast-edns-client-ip]
	Contavalli, C., Gaast, W., Leach, S., and D. Rodden,		Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
	"Client IP information in DNS requests",		"Client IP information in DNS requests",
	draft-vandergaast-edns-client-ip-01 (work in progress),		draft-vandergaast-edns-client-ip-01 (work in progress),
	May 2010.		May 2010.
	[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and		[RFC5632] Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
	Y. Yang, "Comcast's ISP Experiences in a Proactive Network		Y. Yang, "Comcast's ISP Experiences in a Proactive Network
	Provider Participation for P2P (P4P) Technical Trial",		Provider Participation for P2P (P4P) Technical Trial",
	skipping to change at page 24, line 16 ¶		skipping to change at page 29, line 16 ¶
	Martin Stiemerling		Martin Stiemerling
	NEC Laboratories Europe/University of Goettingen		NEC Laboratories Europe/University of Goettingen
	Kurfuerstenanlage 36		Kurfuerstenanlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 6221 4342 113		Phone: +49 6221 4342 113
	Fax: +49 6221 4342 155		Fax: +49 6221 4342 155
	Email: martin.stiemerling@neclab.eu		Email: martin.stiemerling@neclab.eu
	URI: http://www.nw.neclab.eu/		URI: http://ietf.stiemerling.org
	Sebastian Kiesel		Sebastian Kiesel
	University of Stuttgart, Computing Center		University of Stuttgart, Computing Center
	Allmandring 30		Allmandring 30
	Stuttgart 70550		Stuttgart 70550
	Germany		Germany
	Email: ietf-alto@skiesel.de		Email: ietf-alto@skiesel.de
End of changes. 24 change blocks.
	56 lines changed or deleted		262 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/