< draft-ietf-alto-deployments-01.txt		draft-ietf-alto-deployments-02.txt >
	ALTO M. Stiemerling		ALTO M. Stiemerling
	Internet-Draft NEC Europe Ltd.		Internet-Draft NEC Europe Ltd.
	Intended status: Informational S. Kiesel		Intended status: Informational S. Kiesel
	Expires: September 15, 2011 University of Stuttgart		Expires: January 12, 2012 University of Stuttgart
	March 14, 2011		July 11, 2011
	ALTO Deployment Considerations		ALTO Deployment Considerations
	draft-ietf-alto-deployments-01		draft-ietf-alto-deployments-02
	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 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 16 ¶		skipping to change at page 2, line 23 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. General Considerations . . . . . . . . . . . . . . . . . . . . 5		2. General Considerations . . . . . . . . . . . . . . . . . . . . 5
	2.1. General Placement of ALTO . . . . . . . . . . . . . . . . 5		2.1. General Placement of ALTO . . . . . . . . . . . . . . . . 5
	2.2. Relationship between ALTO and Applications . . . . . . . . 7		2.2. Relationship between ALTO and Applications . . . . . . . . 7
	2.3. Provided Guidance . . . . . . . . . . . . . . . . . . . . 7		2.3. Provided Guidance . . . . . . . . . . . . . . . . . . . . 7
	2.3.1. Keeping Traffic Local in Network . . . . . . . . . . . 8		2.3.1. Keeping Traffic Local in Network . . . . . . . . . . . 8
	2.3.2. Off-Loading Traffic from Network . . . . . . . . . . . 8		2.3.2. Off-Loading Traffic from Network . . . . . . . . . . . 8
	2.3.3. Intra-Network Localization/Bottleneck Off-Loading . . 9		2.3.3. Intra-Network Localization/Bottleneck Off-Loading . . 9
	2.4. Provisiong ALTO Maps . . . . . . . . . . . . . . . . . . . 11		2.4. Provisiong ALTO Maps . . . . . . . . . . . . . . . . . . . 11
	3. Using ALTO for P2P . . . . . . . . . . . . . . . . . . . . . . 12		3. Deployment Considerations by ISPs . . . . . . . . . . . . . . 12
	3.1. Using ALTO for Tracker-based Peer-to-Peer Applications . . 14		3.1. Requirement for Traffic Optimization by ISPs . . . . . . . 12
	3.2. Expectations of ALTO . . . . . . . . . . . . . . . . . . . 16		3.2. Considerations for ISPs . . . . . . . . . . . . . . . . . 13
	4. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 17		3.2.1. Very small ISPs with simple Network Structure . . . . 13
	5. Advanced Features . . . . . . . . . . . . . . . . . . . . . . 18		3.2.2. Large ISPs with layered fixed Network Structure . . . 13
	5.1. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . 18		3.2.3. ISPs with Mobile Network . . . . . . . . . . . . . . . 15
	5.2. ALTO for IPv4 and IPv6 . . . . . . . . . . . . . . . . . . 19		4. Using ALTO for P2P . . . . . . . . . . . . . . . . . . . . . . 17
	5.3. Monitoring ALTO . . . . . . . . . . . . . . . . . . . . . 19		4.1. Using ALTO for Tracker-based Peer-to-Peer Applications . . 19
	6. Known Limitations of ALTO . . . . . . . . . . . . . . . . . . 20		4.2. Expectations of ALTO . . . . . . . . . . . . . . . . . . . 21
	6.1. Limitations of Map-based Approaches . . . . . . . . . . . 20		5. Using ALTO for CDNs . . . . . . . . . . . . . . . . . . . . . 22
	6.2. Limitiations of Non-Map-based Approaches . . . . . . . . . 21		6. Advanced Features . . . . . . . . . . . . . . . . . . . . . . 23
	6.3. General Challenges . . . . . . . . . . . . . . . . . . . . 21		6.1. Cascading ALTO Servers . . . . . . . . . . . . . . . . . . 23
	7. Extensions to the ALTO Protocol . . . . . . . . . . . . . . . 23		6.2. ALTO for IPv4 and IPv6 . . . . . . . . . . . . . . . . . . 24
	7.1. Host Group Descriptors . . . . . . . . . . . . . . . . . . 23		6.3. Monitoring ALTO . . . . . . . . . . . . . . . . . . . . . 24
	7.2. Rating Criteria . . . . . . . . . . . . . . . . . . . . . 23		6.3.1. Monitoring Metrics Definition . . . . . . . . . . . . 24
	7.2.1. Distance-related Rating Criteria . . . . . . . . . . . 23		6.3.2. Monitoring Data Sources . . . . . . . . . . . . . . . 25
	7.2.2. Charging-related Rating Criteria . . . . . . . . . . . 24		6.3.3. Monitoring Structure . . . . . . . . . . . . . . . . . 25
	7.2.3. Performance-related Rating Criteria . . . . . . . . . 24		7. Known Limitations of ALTO . . . . . . . . . . . . . . . . . . 27
	7.2.4. Inappropriate Rating Criteria . . . . . . . . . . . . 25		7.1. Limitations of Map-based Approaches . . . . . . . . . . . 27
	8. API between ALTO Client and Application . . . . . . . . . . . 26		7.2. Limitiations of Non-Map-based Approaches . . . . . . . . . 28
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 27		7.3. General Challenges . . . . . . . . . . . . . . . . . . . . 28
	9.1. Information Leakage from the ALTO Server . . . . . . . . . 27		8. Extensions to the ALTO Protocol . . . . . . . . . . . . . . . 30
	9.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 27		8.1. Host Group Descriptors . . . . . . . . . . . . . . . . . . 30
	9.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 28		8.2. Rating Criteria . . . . . . . . . . . . . . . . . . . . . 30
	10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29		8.2.1. Distance-related Rating Criteria . . . . . . . . . . . 30
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30		8.2.2. Charging-related Rating Criteria . . . . . . . . . . . 31
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 30		8.2.3. Performance-related Rating Criteria . . . . . . . . . 31
	11.2. Informative References . . . . . . . . . . . . . . . . . . 30		8.2.4. Inappropriate Rating Criteria . . . . . . . . . . . . 32
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33		9. API between ALTO Client and Application . . . . . . . . . . . 33
			10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
			10.1. Information Leakage from the ALTO Server . . . . . . . . . 34
			10.2. ALTO Server Access . . . . . . . . . . . . . . . . . . . . 34
			10.3. Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 35
			11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 36
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
			12.1. Normative References . . . . . . . . . . . . . . . . . . . 37
			12.2. Informative References . . . . . . . . . . . . . . . . . . 37
			Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 39
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
	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 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	Figure 7: With Intra-Network ALTO Traffic Localization		Figure 7: With Intra-Network ALTO Traffic Localization
	TBD: describe how maps would look like.		TBD: describe how maps would look like.
	2.4. Provisiong ALTO Maps		2.4. Provisiong ALTO Maps
	This section will describe how ALTO maps in the protocol can be		This section will describe how ALTO maps in the protocol can be
	populated before using them.		populated before using them.
	3. Using ALTO for P2P		3. Deployment Considerations by ISPs
			The Internet is a large network constituted of multiple networks
			worldwide. Numerous of these networks are built by telecom operators
			or network operators (named ISP in this memo), and these networks
			provide network connectivity, such as cable networks, 3G and so on.
			As well as some of networks are built by universities or big
			organizations themselves, and these networks are used to provide
			connectivity for research and work. The essence of Internet is its
			connectivity and sharing capability. However, ISPs emphasize
			network's manageability and controllability, because ISPs provide
			public network access service for most person and families, they need
			to manage, to control and to audit the traffic. Thus, it's important
			for ISPs to understand the requirement of optimizing traffic, and how
			to deploy ALTO service in these manageability and controllability
			networks.
			3.1. Requirement for Traffic Optimization by ISPs
			All networks of ISPs are connected to each other through peering
			points. From view of business mode, the inter-network settlement is
			needed in traffic exchanging between these ISP's networks. The
			current settlement can be costly. So to save these cost, the simple
			and basic method is to decrease the traffic exchange across the
			peering points and keep the traffic in own network area.
			For some large ISPs, their whole network is layered. The upper layer
			network includes one or several backbone networks, and the lower
			layer network includes multiple access networks. These access
			networks are connected to backbone networks, and the exchange traffic
			with others through backbone network. In this kind of layered
			network, the bandwidth of backbone network is important and may be
			scarce. Traffic should be limited to the access networks, so to
			decrease the usage of backbone as far as possible.
			Compared to fixed networks, mobile networks have some special
			characters, including small link bandwidth, high cost, limited radio
			frequency resource, and terminal battery. In mobile network, the
			usage of wireless link should be decreased as far as possible and be
			high-efficient. For example, in the case of a P2P service, the
			clients in the fixed network should decrease the data transport from
			the clients in the mobile networks, as well as the clients in the
			mobile networks should prefer the data transmission from the clients
			in the fixed networks.
			3.2. Considerations for ISPs
			3.2.1. Very small ISPs with simple Network Structure
			For very small ISPs, the traffic optimizing problem they focus is
			that how to decrease the traffic exchanging with other ISPs, because
			of high settlement costs. To use the ALTO service to optimize
			traffic, small ISPs can define two optimization areas: one is their
			own network; the other is all outer networks connected with their
			network. The cost map can be defined like this: the cost of link
			between clients of inner ISP's networks is lower than from clients of
			outer ISP's networks to clients of inner ISP's networks. So the
			client of this ISP will prefer to require data from the clients in
			the same ISP with high priority.
			One example is given as below in Figure 8. ISP A is one small ISP,
			only having one access network. In ALTO service deploying, we can
			define ISP A to be one optimization area, named as PID1, and define
			other networks to be the other optimization area, named as PID2. C1
			is denoted as the link cost in inner ISP A. C2 is denoted as the link
			cost from PID2 to PID1. We define the cost map as:
			C1<C2
			-----------
			//// \\\\
			// \\
			// \\ /-----------\
			| +---------+ | //// \\\\
			| | ALTO | ISP A | C2 | Other Networks |
			| | Service | PID 1 <----------- PID 2
			| +---------+ C1 | | |
			| | \\\\ ////
			\\ // \-----------/
			\\ //
			\\\\ ////
			-----------
			Figure 8: ALTO deployment in small ISPs
			3.2.2. Large ISPs with layered fixed Network Structure
			For large ISPs with layered fixed network structure, the traffic
			optimizing problems they focus will include that: using backbone
			network by high-efficiency, adjusting traffic balance in different
			access networks according to traffic conditions and management
			policies, and considering settlement cost with other ISPs. So in
			ALTO service deploying to this kind of large ISP, first the
			optimization area can be defined according to real network condition.
			For example, each access network can be defined to be one
			optimization area. Then cost can be defined according to the
			optimizing requirement by ISPs. There is one example described below
			and also shown in Figure 9.
			In this example, ISP A has one backbone network and three access
			networks, named as AN A, AN B, and AN C. A P2P application is used in
			this example. For the traffic optimization, the first requirement is
			to decrease the P2P traffic of backbone network in inner ISP A; and
			the second requirement is to decrease the P2P traffic to outer ISPs.
			Always, the second requirement is prior to the first one. Also, we
			assume that the settlement rate with ISP B is lower than with other
			ISPs. Then ISP A can deploy ALTO service to meet the need of traffic
			optimization. We will give the detail example of ALTO service
			definition and configuration according to requirements above.
			In inner network of ISP A, we can define each access network to be
			one optimization area, and assign one PID to every access network,
			such as PID1, PID2, and PID 3. Because of different settlement with
			different outer ISPs, we define ISP B to be one optimization area,
			and assign PID 4 to it, as well as define all other networks to be
			one optimization area and PID 5.
			We assign cost names (C1, C2, C3, C4, C5, C6, C7) as the figure
			below. C1 is denoted as the link cost in inner AN A, the same as C2
			and C3. C4 is denoted as the link cost from PID 1 to PID 2, the same
			as C5. C6 is denoted as the link cost from the ISP B to ISP A. C7 is
			denoted as the link cost from other networks to ISP A.
			According to discussion of the first requirement and the second
			requirement above, the relationship of these costs will be defined
			as: (C1, C2, C3) < (C4, C5) < (C6) < (C7)
			This is one very simple example above, in which we do not consider
			the different link type of access network. In deploying ALTO service
			in real network, we must consider more real network conditions and
			requirements. One real example is described in greater detail in
			[I-D.lee-alto-chinatelecom-trial].
			+------------------------------------+ +----------------+
			| ISP A +---------------+ | | |
			| | Backbone | | C6 | ISP B |
			| +--+ Network +---+ |<--------+ PID 4 |
			| | +-------+-------+ | | | |
			| | | | | | |
			| | | | | +----------------+
			| +---+--+ +--+---+ +-+----+ |
			| |AN A | C4 |AN B | C5 |AN C | |
			| |PID 1 +--->|PID 2 |<----+PID 3 | |
			| |C1 | |C2 | |C3 | | +----------------+
			| +---+--+ +---+--+ +-+----+ | | |
			| | | | | | |
			| | | | | C7 | Other Networks |
			| | +--------+--+ | |<--------+ PID 5 |
			| +--| ALTO +-------+ | | |
			| | Service | | | |
			| +-----------+ | | |
			+------------------------------------+ +----------------+
			Figure 9: ALTO deployment in large ISPs with layered fixed network
			structures
			3.2.3. ISPs with Mobile Network
			For ISPs with mobile network and fixed network, the traffic
			optimizing problems they focus will be optimizing the mobile traffic,
			except problems on last hop section. Wireless radio frequency
			resource is scarce and costly in mobile network. The requirement of
			traffic optimization in mobile network is mainly decreasing the usage
			of radio resource. The ALTO service can be deployed to meet these
			needs.
			For example in one ISP A as below in Figure 10, there is one mobile
			network is connected to backbone network. In this kind of network
			structure, mobile network can be defined as one optimization area,
			and assigned PID 1. We also define other PID and cost as figure
			below.
			To decrease the usage of wireless link, the relationship of these
			costs will be defined to:
			From view of mobile network:(C4 < C1). This means that, the clients
			in mobile network requiring data resource from clients of the other
			access networks is prior to clients of mobile network. This policy
			can decrease the usage of wireless link and power consumption in
			terminal.
			From view of AN A:(C2 < C6, C5 = maximum cost). This means that, to
			other optimization area, requiring data from mobile network should be
			avoided.
			+-----------------------------------------------------------------+
			| |
			| ISP A +-------------+ |
			| +--------+ ALTO +---------+ |
			| | | Service | | |
			| | +------+------+ | |
			| | | | |
			| | | | |
			| | | | |
			| +-------+-------+ | C6 +--------+------+ |
			| | AN A |<-------------- AN B | |
			| | PID 2 | C7 | | PID 3 | |
			| | C2 -------------->| C3 | |
			| +---------------+ | +---------------+ |
			| ^ | | | ^ |
			| | | | | | |
			| | |C4 | | | |
			| C5 | | | | | |
			| | | +--------+---------+ | | |
			| | +-->| Mobile Network |<---+ | |
			| | | PID 1 | | |
			| +------- | C1 |----------+ |
			| +------------------+ |
			+-----------------------------------------------------------------+
			Figure 10: ALTO deployment in ISPs with mobile network
			4. Using ALTO for P2P
	,-------.		,-------.
	,---. ,-' `-. +-----------+		,---. ,-' `-. +-----------+
	,-' `-. / 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 12, line 31 ¶		skipping to change at page 17, line 31 ¶
	`-*-' \ / | Peer 4 |*****		`-*-' \ / | Peer 4 |*****
	* `-. ,-' | | ****		* `-. ,-' | | ****
	* `-------' +-----------+ ****		* `-------' +-----------+ ****
	* ****		* ****
	* ****		* ****
	***********************************************<******		***********************************************<******
	Legend:		Legend:
	=== ALTO client protocol		=== ALTO client protocol
	*** Application protocol		*** Application protocol
	Figure 8: Global tracker accessing ALTO server at various ISPs		Figure 11: Global tracker accessing ALTO server at various ISPs
	Figure 8 depicts a tracker-based system, where the tracker embeds the		Figure 11 depicts a tracker-based system, where the tracker embeds
	ALTO client. The tracker itself is hosted and operated by an entity		the ALTO client. The tracker itself is hosted and operated by an
	different than the ISP hosting and operating the ALTO server.		entity 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
	protocols.		protocols.
	skipping to change at page 13, line 29 ¶		skipping to change at page 18, line 29 ¶
	`-. * ,-' \ +-------------+ /= | Peer 4 |*****		`-. * ,-' \ +-------------+ /= | Peer 4 |*****
	`-*-' \ / +==>|ALTO Client| ****		`-*-' \ / +==>|ALTO Client| ****
	* `-. ,-' +-----------+ ****		* `-. ,-' +-----------+ ****
	* `-------' ****		* `-------' ****
	* ****		* ****
	***********************************************<****		***********************************************<****
	Legend:		Legend:
	=== ALTO client protocol		=== ALTO client protocol
	*** Application protocol		*** Application protocol
	Figure 9: Global Tracker - Local ALTO Servers		Figure 12: Global Tracker - Local ALTO Servers
	The scenario in Figure 9 lets the peers directly communicate with		The scenario in Figure 12 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 14, line 29 ¶		skipping to change at page 19, line 29 ¶
	`-. *,-' | +-----===-----+ | | Peer 4 |<*		`-. *,-' | +-----===-----+ | | Peer 4 |<*
	`---* \ +-----===-----+ / | | *		`---* \ +-----===-----+ / | | *
	* \+ ALTO Server |/ +-----------+ *		* \+ ALTO Server |/ +-----------+ *
	* +-------------+ *		* +-------------+ *
	* `-------' *		* `-------' *
	***********************************************		***********************************************
	Legend:		Legend:
	=== ALTO client protocol		=== ALTO client protocol
	*** Application protocol		*** Application protocol
	Figure 10: P4P approach with local tracker and local ALTO server		Figure 13: 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 10. In this case, the client has no chance to get		shown in Figure 13. 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 10 and Figure 8 ostensibly take peers the possibility to		Figure 13 and Figure 11 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 9.		for the scenario depicted in Figure Figure 12.
	3.1. Using ALTO for Tracker-based Peer-to-Peer Applications		4.1. Using ALTO for Tracker-based Peer-to-Peer Applications
	............................. .............................		............................. .............................
	: Tracker : : Peer :		: Tracker : : Peer :
	: ______ : : :		: ______ : : :
	: +-______-+ : : k good :		: +-______-+ : : k good :
	: | | +--------+ : P2P App. : +--------+ peers +------+ :		: | | +--------+ : P2P App. : +--------+ peers +------+ :
	: | N | | random | : Protocol : | ALTO- |------>| data | :		: | N | | random | : Protocol : | ALTO- |------>| data | :
	: | known |====>| pre- |*************>| biased | | ex- | :		: | known |====>| pre- |*************>| biased | | ex- | :
	: | peers, | | selec- | : transmit : | peer |------>| cha- | :		: | peers, | | selec- | : transmit : | peer |------>| cha- | :
	: | M good | | tion | : n peer : | select | n-k | nge | :		: | M good | | tion | : n peer : | select | n-k | nge | :
	: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :		: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :
	skipping to change at page 15, line 25 ¶		skipping to change at page 20, line 25 ¶
	|		|
	| ALTO		| ALTO
	| client protocol		| client protocol
	__|___		__|___
	+-______-+		+-______-+
	| |		| |
	| ALTO |		| ALTO |
	| server |		| server |
	+-______-+		+-______-+
	Figure 11: Tracker-based P2P Application with random peer		Figure 14: Tracker-based P2P Application with random peer
	preselection		preselection
	............................. .............................		............................. .............................
	: Tracker : : Peer :		: Tracker : : Peer :
	: ______ : : :		: ______ : : :
	: +-______-+ : : :		: +-______-+ : : :
	: | | +--------+ : P2P App. : k good peers & +------+ :		: | | +--------+ : P2P App. : k good peers & +------+ :
	: | N | | ALTO- | : Protocol : n-k bad peers | data | :		: | N | | ALTO- | : Protocol : n-k bad peers | data | :
	: | known |====>| biased |******************************>| ex- | :		: | known |====>| biased |******************************>| ex- | :
	: | peers, | | peer | : transmit : | cha- | :		: | peers, | | peer | : transmit : | cha- | :
	skipping to change at page 15, line 49 ¶		skipping to change at page 20, line 49 ¶
	|		|
	| ALTO		| ALTO
	| client protocol		| client protocol
	__|___		__|___
	+-______-+		+-______-+
	| |		| |
	| ALTO |		| ALTO |
	| server |		| server |
	+-______-+		+-______-+
	Figure 12: Tracker-based P2P Application with ALTO client in tracker		Figure 15: Tracker-based P2P Application with ALTO client in tracker
	TBD: explain why Figure 12 usually will yield better results wrt.		TBD: explain why Figure 15 usually will yield better results wrt.
	peer selection than Figure 11.		peer selection than Figure 14.
	3.2. Expectations of ALTO		4.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		5. Using ALTO for CDNs
	Section 2 discussed the placement and usage of ALTO for P2P systems,		Section 2 discussed the placement and usage of ALTO for P2P systems,
	but not beyond. This section discuss the usage of ALTO for Content		but not beyond. This section discuss the usage of ALTO for Content
	Delivery Networks (CDNs). CDNs are used to bring a service (e.g., a		Delivery Networks (CDNs). CDNs are used to bring a service (e.g., a
	web page, videos, etc) closer to the location of the user - where		web page, videos, etc) closer to the location of the user - where
	close refers to shorten the distance between the client and the		close refers to shorten the distance between the client and the
	server in the IP topology. CDNs use several techniques to decide		server in the IP topology. CDNs use several techniques to decide
	which server is closest to a client requesting a service. One common		which server is closest to a client requesting a service. One common
	way to do so, is relying on the DNS system, but there are many other		way to do so, is relying on the DNS system, but there are many other
	ways, see [RFC3568].		ways, see [RFC3568].
	The general issue for CDNs, independent of DNS or HTTP Redirect based		The general issue for CDNs, independent of DNS or HTTP Redirect based
	approaches (see, for instance, [I-D.penno-alto-cdn]), is that the CDN		approaches (see, for instance, [I-D.penno-alto-cdn]), is that the CDN
	logic has to match the client's IP address with the closest CDN		logic has to match the client's IP address with the closest CDN
	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. Advanced Features		6. Advanced Features
	5.1. Cascading ALTO Servers		6.1. 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 13		certain deployments that may have different settings. Figure 16
	shows such setting, were for example, a university network is		shows such setting, were for example, a university network is
	connected to two upstream providers. ISP2 if the national research		connected to two upstream providers. ISP2 if the national research
	network and ISP1 is a commercial upstream provider to this university		network and ISP1 is a commercial upstream provider to this university
	network. The university, as well as ISP1, are operating their own		network. The university, as well as ISP1, are operating their own
	ALTO server. The ALTO clients, located on the peers will contact the		ALTO server. The ALTO clients, located on the peers will contact the
	ALTO server located at the university.		ALTO server located at the university.
	+-----------+		+-----------+
	| ISP1 |		| ISP1 |
	| ALTO |		| ALTO |
	skipping to change at page 18, line 46 ¶		skipping to change at page 23, line 46 ¶
	,' University `. |University |		,' University `. |University |
	( Network ) | ALTO |		( Network ) | ALTO |
	`. =======================| Server |		`. =======================| Server |
	`-= +-' +-----------+		`-= +-' +-----------+
	=`+------------'|		=`+------------'|
	= | |		= | |
	+--------+-+ +-+--------+		+--------+-+ +-+--------+
	| Peer1 | | PeerN |		| Peer1 | | PeerN |
	+----------+ +----------+		+----------+ +----------+
	Figure 13: Cascaded ALTO Server		Figure 16: 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.
	5.2. ALTO for IPv4 and IPv6		6.2. ALTO for IPv4 and IPv6
	TBD		TBD
	5.3. Monitoring ALTO		6.3. Monitoring ALTO
	TBD		In addition to providing configuration, an ISP providing ALTO may
			want to deploy a monitoring infrastructure to assess the benefits of
			ALTO and adjust its ALTO configuration according to the results of
			the monitoring.
	6. Known Limitations of ALTO		To construct an effective monitoring infrastructure, the ISP should
			(1) define the performance metrics to be monitored; (2) and identify
			and deploy data sources to collect data to compute the performance
			metrics. We discuss both below.
			[Editor's note: Is there a relationship to the IPPM working group at
			the IETF?]
			6.3.1. Monitoring Metrics Definition
			o Inter-domain ALTO-Integrated Application Traffic (Network metric):
			This metric includes total cross domain traffic generated by
			applications that utilize ALTO guidance. This metric evaluates
			the impacts of ALTO on the inbound and outbound traffic of a
			domain.
			o Total Inter-domain Traffic (Network metric): This is similar to
			the preceding but focuses on all of the traffic, ALTO aware or
			not. One possibility is that some of the reduction of interdomain
			traffic by ALTO aware applications may (XXX missing words?). This
			metric is always used with the preceding and the following
			metrics.
			o Intra-domain ALTO-Integrated Application Traffic (Network metric).
			(XXX description missing)
			o Network hop count (Network metric): This metric provides the
			average number of hops that traffic traverses inside a domain.
			ALTO may reduce not only traffic volume but also the hops. The
			metric can also indirectly reflect some application performance
			(e.g., latency).
			o Application download rate (Application metric): This metric
			measures application performance directly. Download means inbound
			traffic to one user. Global average means the average value of
			all users' download rates in one or more domains.
			o Application Client type audit(Application metric): this metric
			gives the audit of client types in ALTO service. The current
			types include fixed network client and mobile network client.
			6.3.2. Monitoring Data Sources
			The preceding metrics are derived from data sources. We identify
			three data sources.
			1. Application Log Server: Many application systems deploy Log
			Servers to collect data.
			2. P2P Clients: Some P2P applications may not have Log Servers.
			When available, P2P client logs can provide data. This is for
			P2P application
			3. OAM: Many ISPs deploy OAM systems to monitor IP layer traffic.
			An OAM provides traffic monitoring of every network device in its
			management area. It provides data such as link physical
			bandwidth and traffic volumes.
			6.3.3. Monitoring Structure
			As discussed in the preceding section, some data sources are from ISP
			while some others are from application. When there is a
			collaboration agreement between the ISP and an application, there can
			be an integrated monitoring system as shown in the figure below. In
			particular, an application developer may deploy Monitor Clients to
			communicate with Monitor Server of the ISP to transmit raw data from
			the Log Server or P2P clients of the application to the ISP.
			+------------------------------------------------+
			| |
			| New Entities +--------------------------------------+
			| | Service Provider |
			| | (P2P/CDN Operator etc)|
			| +-----------+ | +-----------+ | |
			| |ALTO Server|-------------|ALTO Client| | |
			| +-----------+ | +-----------+ | |
			| | | +----------+ |
			| | | |Log Server| |
			| | | +----------+ |
			| +--------------+ | +--------------+ | +----------+ |
			| |Monitor Server|----------|Monitor Client| | |P2P Client| |
			| +--------------+ | +--------------+ | +----------+ |
			| | | | |
			| +--------|--------+ +--------------------------------------+
			+-|--------|--------|----------------------------+
			| | |
			| | |
			| +---+ |
			| |OAM| |
			| +---+ |
			| ISP |
			-----------------
			Figure 17: Monitoring Structure
			7. Known Limitations of ALTO
	This section describes some known limitations of ALTO in general or		This section describes some known limitations of ALTO in general or
	specific mechanisms in ALTO.		specific mechanisms in ALTO.
	6.1. Limitations of Map-based Approaches		7.1. Limitations of Map-based Approaches
	The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses,		The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses,
	amongst others mechanism, so-called network maps. The network map		amongst others mechanism, so-called network maps. The network map
	approach uses Host Group Descriptors that group one or multiple		approach uses Host Group Descriptors that group one or multiple
	subnetworks (i.e., IP prefixes) to a single Host Group Descriptor. A		subnetworks (i.e., IP prefixes) to a single Host Group Descriptor. A
	set of IP prefixes is called partition and the associated Host Group		set of IP prefixes is called partition and the associated Host Group
	Descriptor is called partition ID. The "costs" between the various		Descriptor is called partition ID. The "costs" between the various
	partition IDs is stored in a second map, the cost map. Map-based		partition IDs is stored in a second map, the cost map. Map-based
	approaches are chosen as they lower the signaling load on the server,		approaches are chosen as they lower the signaling load on the server,
	as the maps have only to be retrieved if they are changed.		as the maps have only to be retrieved if they are changed.
	skipping to change at page 21, line 32 ¶		skipping to change at page 28, line 32 ¶
	instance one IP addresses IP11 out of a IP prefix IP1 can be assigned		instance one IP addresses IP11 out of a IP prefix IP1 can be assigned
	to a VDSL (e.g., 2 MBit/s uplink) access-line while the subsequent IP		to a VDSL (e.g., 2 MBit/s uplink) access-line while the subsequent IP
	address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s		address IP12 is assigned to a slow ADSL line (e.g., 128 kbit/s
	uplink). These IP addresses are assigned on a first come first		uplink). These IP addresses are assigned on a first come first
	served basis, i.e., the a single IP address out of the same IP prefix		served basis, i.e., the a single IP address out of the same IP prefix
	can change its associated costs quite fast. This may not be an issue		can change its associated costs quite fast. This may not be an issue
	with respect to the used upstream provider (thus the cross ISP		with respect to the used upstream provider (thus the cross ISP
	traffic) but depending on the capacity of the aggregation-network		traffic) but depending on the capacity of the aggregation-network
	this may raise to an issue.		this may raise to an issue.
	6.2. Limitiations of Non-Map-based Approaches		7.2. Limitiations of Non-Map-based Approaches
	The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses,		The specification of the ALTO protocol [I-D.ietf-alto-protocol] uses,
	amongst others mechanism, a mechanism called Endpoint Cost Service.		amongst others mechanism, a mechanism called Endpoint Cost Service.
	ALTO clients can ask guidance for specific IP addresses to the ALTO		ALTO clients can ask guidance for specific IP addresses to the ALTO
	server. However, asking for IP addresses, asking with long lists of		server. However, asking for IP addresses, asking with long lists of
	IP addresses, and asking quite frequent may overload the ALTO server.		IP addresses, and asking quite frequent may overload the ALTO server.
	The server has to rank each received IP address which causes load at		The server has to rank each received IP address which causes load at
	the server. This may be amplified by the fact that not only a single		the server. This may be amplified by the fact that not only a single
	ALTO client is asking for guidance, but a larger number of them.		ALTO client is asking for guidance, but a larger number of them.
	Caching of IP addresses at the ALTO client or the usage of the H12		Caching of IP addresses at the ALTO client or the usage of the H12
	approach [I-D.kiesel-alto-h12] in conjunction with caching may lower		approach [I-D.kiesel-alto-h12] in conjunction with caching may lower
	the query load on the ALTO server.		the query load on the ALTO server.
	6.3. General Challenges		7.3. General Challenges
	An ALTO server stores information about preferences (e.g., a list of		An ALTO server stores information about preferences (e.g., a list of
	preferred autonomous systems, IP ranges, etc) and ALTO clients can		preferred autonomous systems, IP ranges, etc) and ALTO clients can
	retrieve these preferences. However, there are basically two		retrieve these preferences. However, there are basically two
	different approaches on where the preferences are actually processed:		different approaches on where the preferences are actually processed:
	1. The ALTO server has a list of preferences and clients can		1. The ALTO server has a list of preferences and clients can
	retrieve this list via the ALTO protocol. This preference list		retrieve this list via the ALTO protocol. This preference list
	can be partially updated by the server. The actual processing of		can be partially updated by the server. The actual processing of
	the data is done on the client and thus there is no data of the		the data is done on the client and thus there is no data of the
	skipping to change at page 23, line 5 ¶		skipping to change at page 30, line 5 ¶
	server.		server.
	Both approaches have their pros and cons and are extensively		Both approaches have their pros and cons and are extensively
	discussed on the ALTO mailing list. But there is basically a		discussed on the ALTO mailing list. But there is basically a
	dilemma: Approach 1 is seen as the only working solution by peer-to-		dilemma: Approach 1 is seen as the only working solution by peer-to-
	peer software vendors and approach 2 is seen as the only working by		peer software vendors and approach 2 is seen as the only working by
	the network operators. But neither the software vendors nor the		the network operators. But neither the software vendors nor the
	operators seem to willing to change their position. However, there		operators seem to willing to change their position. However, there
	is the need to get both sides on board, to come to a solution.		is the need to get both sides on board, to come to a solution.
	7. Extensions to the ALTO Protocol		8. Extensions to the ALTO Protocol
	7.1. Host Group Descriptors		8.1. Host Group Descriptors
	Host group descriptors are used in the ALTO client protocol to		Host group descriptors are used in the ALTO client protocol to
	describe the location of a host in the network topology. The ALTO		describe the location of a host in the network topology. The ALTO
	client protocol specification defines a basic set of host group		client protocol specification defines a basic set of host group
	descriptor types, which have to be supported by all implementations,		descriptor types, which have to be supported by all implementations,
	and an extension procedure for adding new descriptor types . The		and an extension procedure for adding new descriptor types . The
	following list gives an overview on further host group descriptor		following list gives an overview on further host group descriptor
	types that have been proposed in the past, or which are in use by		types that have been proposed in the past, or which are in use by
	ALTO-related prototype implementations. This list is not intended as		ALTO-related prototype implementations. This list is not intended as
	normative text. Instead, the only purpose of the following list is		normative text. Instead, the only purpose of the following list is
	to document the descriptor types that have been proposed so far, and		to document the descriptor types that have been proposed so far, and
	to solicit further feedback and discussion:		to solicit further feedback and discussion:
	o Autonomous System (AS) number		o Autonomous System (AS) number
	o Protocol-specific group identifiers, which expand to a set of IP		o Protocol-specific group identifiers, which expand to a set of IP
	address ranges (CIDR) and/or AS numbers. In one specific solution		address ranges (CIDR) and/or AS numbers. In one specific solution
	proposal, these are called Partition ID (PID).		proposal, these are called Partition ID (PID).
	7.2. Rating Criteria		8.2. Rating Criteria
	Rating criteria are used in the ALTO client protocol to express		Rating criteria are used in the ALTO client protocol to express
	topology- or connectivity-related properties, which are evaluated in		topology- or connectivity-related properties, which are evaluated in
	order to generate the ALTO guidance. The ALTO client protocol		order to generate the ALTO guidance. The ALTO client protocol
	specification defines a basic set of rating criteria, which have to		specification defines a basic set of rating criteria, which have to
	be supported by all implementations, and an extension procedure for		be supported by all implementations, and an extension procedure for
	adding new criteria . The following list gives an overview on		adding new criteria . The following list gives an overview on
	further rating criteria that have been proposed in the past, or which		further rating criteria that have been proposed in the past, or which
	are in use by ALTO-related prototype implementations. This list is		are in use by ALTO-related prototype implementations. This list is
	not intended as normative text. Instead, the only purpose of the		not intended as normative text. Instead, the only purpose of the
	following list is to document the rating criteria that have been		following list is to document the rating criteria that have been
	proposed so far, and to solicit further feedback and discussion:		proposed so far, and to solicit further feedback and discussion:
	7.2.1. Distance-related Rating Criteria		8.2.1. Distance-related Rating Criteria
	o Relative topological distance: relative means that a larger		o Relative topological distance: relative means that a larger
	numerical value means greater distance, but it is up to the ALTO		numerical value means greater distance, but it is up to the ALTO
	service how to compute the values, and the ALTO client will not be		service how to compute the values, and the ALTO client will not be
	informed about the nature of the information. One way of		informed about the nature of the information. One way of
	generating this kind of information MAY be counting AS hops, but		generating this kind of information MAY be counting AS hops, but
	when querying this parameter, the ALTO client MUST NOT assume that		when querying this parameter, the ALTO client MUST NOT assume that
	the numbers actually are AS hops.		the numbers actually are AS hops.
	o Absolute topological distance, expressed in the number of		o Absolute topological distance, expressed in the number of
	traversed autonomous systems (AS).		traversed autonomous systems (AS).
	o Absolute topological distance, expressed in the number of router		o Absolute topological distance, expressed in the number of router
	hops (i.e., how much the TTL value of an IP packet will be		hops (i.e., how much the TTL value of an IP packet will be
	decreased during transit).		decreased during transit).
	o Absolute physical distance, based on knowledge of the approximate		o Absolute physical distance, based on knowledge of the approximate
	geolocation (continent, country) of an IP address.		geolocation (continent, country) of an IP address.
	7.2.2. Charging-related Rating Criteria		8.2.2. Charging-related Rating Criteria
	o Traffic volume caps, in case the Internet access of the resource		o Traffic volume caps, in case the Internet access of the resource
	consumer is not charged by "flat rate". For each candidate		consumer is not charged by "flat rate". For each candidate
	resource provider, the ALTO service could indicate the amount of		resource provider, the ALTO service could indicate the amount of
	data that may be transferred from/to this resource provider until		data that may be transferred from/to this resource provider until
	a given point in time, and how much of this amount has already		a given point in time, and how much of this amount has already
	been consumed. Furthermore, it would have to be indicated how		been consumed. Furthermore, it would have to be indicated how
	excess traffic would be handled (e.g., blocked, throttled, or		excess traffic would be handled (e.g., blocked, throttled, or
	charged separately at an indicated price). The interaction of		charged separately at an indicated price). The interaction of
	several applications running on a host, out of which some use this		several applications running on a host, out of which some use this
	criterion while others don't, as well as the evaluation of this		criterion while others don't, as well as the evaluation of this
	criterion in resource directories, which issue ALTO queries on		criterion in resource directories, which issue ALTO queries on
	behalf of other peers, are for further study.		behalf of other peers, are for further study.
	7.2.3. Performance-related Rating Criteria		8.2.3. Performance-related Rating Criteria
	The following rating criteria are subject to the remarks below.		The following rating criteria are subject to the remarks below.
	o The minimum achievable throughput between the resource consumer		o The minimum achievable throughput between the resource consumer
	and the candidate resource provider, which is considered useful by		and the candidate resource provider, which is considered useful by
	the application (only in ALTO queries), or		the application (only in ALTO queries), or
	o An arbitrary upper bound for the throughput from/to the candidate		o An arbitrary upper bound for the throughput from/to the candidate
	resource provider (only in ALTO responses). This may be, but is		resource provider (only in ALTO responses). This may be, but is
	not necessarily the provisioned access bandwidth of the candidate		not necessarily the provisioned access bandwidth of the candidate
	skipping to change at page 25, line 39 ¶		skipping to change at page 32, line 39 ¶
	state information, which are inherent to the ALTO service, the		state information, which are inherent to the ALTO service, the
	application must use other mechanisms (such as passive measurements		application must use other mechanisms (such as passive measurements
	on actual data transmissions) to assess the currently achievable		on actual data transmissions) to assess the currently achievable
	throughput, and it MUST use appropriate congestion control mechanisms		throughput, and it MUST use appropriate congestion control mechanisms
	in order to avoid a congestion collapse. Nevertheless, these rating		in order to avoid a congestion collapse. Nevertheless, these rating
	criteria may provide a useful shortcut for quickly excluding		criteria may provide a useful shortcut for quickly excluding
	candidate resource providers from such probing, if it is known in		candidate resource providers from such probing, if it is known in
	advance that connectivity is in any case worse than what is		advance that connectivity is in any case worse than what is
	considered the minimum useful value by the respective application.		considered the minimum useful value by the respective application.
	7.2.4. Inappropriate Rating Criteria		8.2.4. Inappropriate Rating Criteria
	Rating criteria that SHOULD NOT be defined for and used by the ALTO		Rating criteria that SHOULD NOT be defined for and used by the ALTO
	service include:		service include:
	o Performance metrics that are closely related to the instantaneous		o Performance metrics that are closely related to the instantaneous
	congestion status. The definition of alternate approaches for		congestion status. The definition of alternate approaches for
	congestion control is explicitly out of the scope of ALTO.		congestion control is explicitly out of the scope of ALTO.
	Instead, other appropriate means, such as using TCP based		Instead, other appropriate means, such as using TCP based
	transport, have to be used to avoid congestion.		transport, have to be used to avoid congestion.
	8. API between ALTO Client and Application		9. API between ALTO Client and Application
	This sections gives some informational guidance on how the interface		This sections gives some informational guidance on how the interface
	between the actual application using the ALTO guidance and the ALTO		between the actual application using the ALTO guidance and the ALTO
	client can look like.		client can look like.
	This is still TBD.		This is still TBD.
	9. Security Considerations		10. Security Considerations
	The ALTO protocol itself, as well as, the ALTO client and server		The ALTO protocol itself, as well as, the ALTO client and server
	raise new security issues beyond the one mentioned in		raise new security issues beyond the one mentioned in
	[I-D.ietf-alto-protocol] and issues related to message transport over		[I-D.ietf-alto-protocol] and issues related to message transport over
	the Internet. For instance, Denial of Service (DoS) is of interest		the Internet. For instance, Denial of Service (DoS) is of interest
	for the ALTO server and also for the ALTO client. A server can get		for the ALTO server and also for the ALTO client. A server can get
	overloaded if too many TCP requests hit the server, or if the query		overloaded if too many TCP requests hit the server, or if the query
	load of the server surpasses the maximum computing capacity. An ALTO		load of the server surpasses the maximum computing capacity. An ALTO
	client can get overloaded if the responses from the sever are, either		client can get overloaded if the responses from the sever are, either
	intentionally or due to an implementation mistake, too large to be		intentionally or due to an implementation mistake, too large to be
	handled by that particular client.		handled by that particular client.
	9.1. Information Leakage from the ALTO Server		10.1. Information Leakage from the ALTO Server
	The ALTO server will be provisioned with information about the owning		The ALTO server will be provisioned with information about the owning
	ISP's network and very likely also with information about neighboring		ISP's network and very likely also with information about neighboring
	ISPs. This information (e.g., network topology, business relations,		ISPs. This information (e.g., network topology, business relations,
	etc) is consider to be confidential to the ISP and must not be		etc) is consider to be confidential to the ISP and must not be
	revealed.		revealed.
	The ALTO server will naturally reveal parts of that information in		The ALTO server will naturally reveal parts of that information in
	small doses to peers, as the guidance given will depend on the above		small doses to peers, as the guidance given will depend on the above
	mentioned information. This is seen beneficial for both parties,		mentioned information. This is seen beneficial for both parties,
	i.e., the ISP's and the peer's. However, there is the chance that		i.e., the ISP's and the peer's. However, there is the chance that
	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.
	9.2. ALTO Server Access		10.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 9), for		accessible by peers from the ISP network (as shown in Figure 12), 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 8), e.g., by a		not located in the ISP's network (see Figure Figure 11), 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.
	9.3. Faking ALTO Guidance		10.3. Faking ALTO Guidance
	It has not yet been investigated how a faked or wrong ALTO guidance		It has not yet been investigated how a faked or wrong ALTO guidance
	by an ALTO server can impact the operation of the network and also		by an ALTO server can impact the operation of the network and also
	the peers.		the peers.
	Here is a list of examples how the ALTO guidance could be faked and		Here is a list of examples how the ALTO guidance could be faked and
	what possible consequences may arise:		what possible consequences may arise:
	Sorting An attacker could change to sorting order of the ALTO		Sorting An attacker could change to sorting order of the ALTO
	guidance (given that the order is of importance, otherwise the		guidance (given that the order is of importance, otherwise the
	skipping to change at page 29, line 5 ¶		skipping to change at page 36, line 5 ¶
	Preference of a single peer A single IP address (thus a peer) could		Preference of a single peer A single IP address (thus a peer) could
	be marked as to be preferred all over other peers. This peer can		be marked as to be preferred all over other peers. This peer can
	be located within the local ISP or also in other parts of the		be located within the local ISP or also in other parts of the
	Internet (e.g., a web server). This could lead to the case that		Internet (e.g., a web server). This could lead to the case that
	quite a number of peers to trying to contact this IP address,		quite a number of peers to trying to contact this IP address,
	possibly causing a Denial of Service (DoS) attack.		possibly causing a Denial of Service (DoS) attack.
	This section is solely giving a first shot on security issues related		This section is solely giving a first shot on security issues related
	to ALTO deployments.		to ALTO deployments.
	10. Conclusion		11. Conclusion
	This is the first version of the deployment considerations and for		This is the first version of the deployment considerations and for
	sure the considerations are yet incomplete and imprecise.		sure the considerations are yet incomplete and imprecise.
	11. References		12. References
	11.1. Normative References		12.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.
	[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.
	11.2. Informative References		12.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-06 (work in progress),		draft-ietf-alto-protocol-09 (work in progress), June 2011.
	October 2010.
	[I-D.ietf-alto-reqs]		[I-D.ietf-alto-reqs]
	Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang,		Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
	"Application-Layer Traffic Optimization (ALTO)		Y. Yang, "Application-Layer Traffic Optimization (ALTO)
	Requirements", draft-ietf-alto-reqs-08 (work in progress),		Requirements", draft-ietf-alto-reqs-10 (work in progress),
	March 2011.		June 2011.
	[I-D.kamei-p2p-experiments-japan]		[I-D.kamei-p2p-experiments-japan]
	Kamei, S., Momose, T., and T. Inoue, "ALTO-Like Activities		Kamei, S., Momose, T., and T. Inoue, "ALTO-Like Activities
	and Experiments in P2P Network Experiment Council",		and Experiments in P2P Network Experiment Council",
	draft-kamei-p2p-experiments-japan-05 (work in progress),		draft-kamei-p2p-experiments-japan-05 (work in progress),
	March 2011.		March 2011.
	[I-D.kiesel-alto-3pdisc]		[I-D.kiesel-alto-3pdisc]
	Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M.		Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M.,
	Stiemerling, "ALTO Server Discovery Protocol",		Tomsu, M., and S. Yongchao, "ALTO Server Discovery
	draft-kiesel-alto-3pdisc-04 (work in progress),		Protocol", draft-kiesel-alto-3pdisc-05 (work in progress),
	October 2010.		March 2011.
	[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.lee-alto-chinatelecom-trial]
			Li, K. and G. Jian, "ALTO and DECADE service trial within
			China Telecom", draft-lee-alto-chinatelecom-trial-02 (work
			in progress), April 2011.
	[I-D.penno-alto-cdn]		[I-D.penno-alto-cdn]
	Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R.,		Penno, R., Medved, J., Alimi, R., Yang, R., and S.
	and S. Previdi, "ALTO and Content Delivery Networks",		Previdi, "ALTO and Content Delivery Networks",
	draft-penno-alto-cdn-02 (work in progress), October 2010.		draft-penno-alto-cdn-03 (work in progress), March 2011.
	[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",
	RFC 5632, September 2009.		RFC 5632, September 2009.
	[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic		[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
	Optimization (ALTO) Problem Statement", RFC 5693,		Optimization (ALTO) Problem Statement", RFC 5693,
	October 2009.		October 2009.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	Martin Stiemerling is partially supported by the NAPA-WINE project		Xianghui Sun, Lee Kai, and Richard Yang contributed Section 3 and
	(Network-Aware P2P-TV Application over Wise Networks,		Section 6.3
	http://www.napa-wine.org), a research project supported by the
			Martin Stiemerling is partially supported by the COAST project
			(COntent Aware Searching, retrieval and sTreaming,
			http://www.coast-fp7.eu), a research project supported by the
	European Commission under its 7th Framework Program (contract no.		European Commission under its 7th Framework Program (contract no.
	214412). The views and conclusions contained herein are those of the		248036). The views and conclusions contained herein are those of the
	authors and should not be interpreted as necessarily representing the		authors and should not be interpreted as necessarily representing the
	official policies or endorsements, either expressed or implied, of		official policies or endorsements, either expressed or implied, of
	the NAPA-WINE project or the European Commission.		the COAST project or the European Commission.
	Authors' Addresses		Authors' Addresses
	Martin Stiemerling		Martin Stiemerling
	NEC Laboratories Europe		NEC Laboratories Europe
	Kurfuerstenanlage 36		Kurfuerstenanlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 6221 4342 113		Phone: +49 6221 4342 113
End of changes. 55 change blocks.
	99 lines changed or deleted		426 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/