< draft-kiesel-alto-3pdisc-01.txt		draft-kiesel-alto-3pdisc-02.txt >
	ALTO S. Kiesel		ALTO S. Kiesel
	Internet-Draft NEC Europe Ltd.		Internet-Draft University of Stuttgart
	Intended status: Informational M. Tomsu		Intended status: Informational M. Tomsu
	Expires: April 29, 2010 Alcatel-Lucent Bell Labs		Expires: September 9, 2010 N. Schwan
	October 26, 2009		M. Scharf
			Alcatel-Lucent Bell Labs
			March 8, 2010
	Third-party ALTO server discovery		Third-party ALTO server discovery
	draft-kiesel-alto-3pdisc-01		draft-kiesel-alto-3pdisc-02
			Abstract
			The goal of Application-Layer Traffic Optimization (ALTO) is to
			provide guidance to applications, which have to select one or several
			hosts from a set of candidates that are able to provide a desired
			resource.
			This document describes why a third-party ALTO server discovery
			mechanism is required for an important class of applications, namely
			tracker-based P2P applications. Several solution approaches are
			classified and evaluated. The conclusion is that further work is
			required to standardize a protocol and procedures that follow one
			specific approach.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 49 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 29, 2010.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	The goal of Application-Layer Traffic Optimization (ALTO) is to		described in the BSD License.
	provide guidance to applications, which have to select one or several
	hosts from a set of candidates, that are able to provide a desired
	resource.
	This document describes why a third-party ALTO server discovery
	mechanism is required for an important class of applications, namely
	tracker-based P2P applications. Several solution approaches are
	classified and evaluated. The conclusion is that further work is
	required to standardize a protocol and procedures that follow one
	specific approach.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4		2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. The need for third-party ALTO queries . . . . . . . . . . 4		2.1. The need for third-party ALTO queries . . . . . . . . . . 4
	2.2. The need for third-party ALTO server discovery . . . . . . 4		2.2. The need for third-party ALTO server discovery . . . . . . 6
	3. Peer-to-peer application scenario . . . . . . . . . . . . . . 6		3. Peer-to-peer application scenario . . . . . . . . . . . . . . 8
	4. Classification of solution approaches . . . . . . . . . . . . 8		4. Classification of solution approaches . . . . . . . . . . . . 10
	4.1. Solutions that do not require an update of the		4.1. Solutions that do not require an update of the
	application protocol . . . . . . . . . . . . . . . . . . . 8		application protocol . . . . . . . . . . . . . . . . . . . 10
	4.2. Solutions that do require an update of the application		4.2. Solutions that do require an update of the application
	protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10		protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. Approach #1 . . . . . . . . . . . . . . . . . . . . . . . 14		5.1. Approach #1 . . . . . . . . . . . . . . . . . . . . . . . 16
	5.2. Approach #2 . . . . . . . . . . . . . . . . . . . . . . . 14		5.2. Approach #2 . . . . . . . . . . . . . . . . . . . . . . . 16
	5.3. Approach #3 . . . . . . . . . . . . . . . . . . . . . . . 14		5.3. Approach #3 . . . . . . . . . . . . . . . . . . . . . . . 16
	5.4. Approach #4 . . . . . . . . . . . . . . . . . . . . . . . 15		5.4. Approach #4 . . . . . . . . . . . . . . . . . . . . . . . 17
	5.5. Approach #5 . . . . . . . . . . . . . . . . . . . . . . . 15		5.5. Approach #5 . . . . . . . . . . . . . . . . . . . . . . . 17
	5.6. Approach #6 . . . . . . . . . . . . . . . . . . . . . . . 15		5.6. Approach #6 . . . . . . . . . . . . . . . . . . . . . . . 17
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17		6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	9. Informative References . . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	The goal of Application-Layer Traffic Optimization (ALTO) is to		The goal of Application-Layer Traffic Optimization (ALTO) is to
	provide guidance to applications, which have to select one or several		provide guidance to 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
	resource. ALTO is realized by a client-server protocol. ALTO		resource. ALTO is realized by a client-server protocol. ALTO
	clients send queries to ALTO servers, in order to solicit guidance.		clients send queries to ALTO servers, in order to solicit guidance.
	The ALTO client can be embedded in the resource consumer, which will		The ALTO client can be embedded in the resource consumer, which will
	eventually access the desired resource. As an alternative, the ALTO		eventually access the desired resource. As an alternative, the ALTO
	client can be embedded in a resource directory, which assists		client can be embedded in a resource directory, which assists
	resource consumers in finding appropriate resource providers. ALTO		resource consumers in finding appropriate resource providers. In
	queries in the latter case will be referred to as third-party ALTO		some specific peer-to-peer application protocols these resource
	queries.		directories are called "trackers". ALTO queries, which are issued by
			a resource directory on behalf of a resource consumer, will be
			referred to as third-party ALTO queries.
	The challenge for third-party ALTO queries is that they have to be		The challenge for third-party ALTO queries is that they have to be
	answered by the "right" ALTO server, i.e., the ALTO server which has		answered by the "right" ALTO server, i.e., the ALTO server which has
	the knowledge to give guidance to the resource consumer on behalf of		the knowledge to give guidance to the resource consumer on behalf of
	which the query is sent.		which the query is sent.
	This document uses the terminology introduced in		This document uses the terminology introduced in [RFC5693] and it
	[I-D.ietf-alto-problem-statement] and it investigates solution		investigates solution approaches that fulfill the requirements for
	approaches that fulfill the requirements for ALTO server discovery		ALTO server discovery documented in [I-D.ietf-alto-reqs].
	documented in [I-D.ietf-alto-reqs].
	Comments and discussions about this document should be directed to		Comments and discussions about this document should be directed to
	the ALTO working group: alto@ietf.org.		the ALTO working group: alto@ietf.org.
	2. Problem statement		2. Problem statement
	2.1. The need for third-party ALTO queries		2.1. The need for third-party ALTO queries
	The scope of this document is the interaction of peer-to-peer		The scope of this document is the interaction of peer-to-peer
	applications, that use a centralized resource directory ("tracker"),		applications that use a centralized resource directory ("tracker"),
	with the ALTO service. In this scenario, the resource consumer asks		with the ALTO service. In this scenario, the resource consumer
	the resource directory for a list of potential resource providers,		("peer") asks the resource directory for a list of candidate resource
	which can provide the desired resource. Usually, only a subset of		providers, which can provide the desired resource. Usually, only a
	all resource providers known to the resource directory will		subset of all resource providers known to the resource directory will
	eventually be contacted by the resource consumer for accessing the		eventually be contacted by the resource consumer for accessing the
	resource. The purpose of ALTO is giving guidance on this peer		resource. The purpose of ALTO is giving guidance on this peer
	selection, which is supposed to yield better-than-random results.		selection, which is supposed to yield better-than-random results.
	There are two possibilities where to apply the ALTO guidance, in the		Several ALTO client protocol proposals exist (e.g.,
	resource consumer or in the resource directory:		[I-D.ietf-alto-protocol], [I-D.kiesel-alto-h12]), which specify how
			an ALTO client can query an ALTO server for guiding information and
			receive the corresponding replies. However, in the considered
			scenario of a tracker-based P2P application, there are two
			fundamentally different possibilities where to place the ALTO client:
	In the first scenario, the resource directory returns a list of		1. ALTO client in the resource consumer ("peer")
	potential resource providers without considering ALTO. It is then
	the duty of the resource consumer to invoke ALTO, in order to solicit
	guidance regarding this list. The problem with this approach is,
	that while the resource directory might know thousands of peers
	taking part in a swarm, the list returned to the resource consumer is
	usually shortened for efficiency reasons. Therefore, the "best" (in
	the sense of ALTO) potential resource providers might not be
	contained in that list anymore, even before ALTO can consider them.
	In the second scenario, the resource directory has an embedded ALTO		2. ALTO client in the resource directory ("tracker")
	client, which we will refer to as RDAC in this document. The
			In the following, both scenarios are compared in order to explain the
			need for third-party ALTO queries.
			In the first scenario (see Figure 1), the resource consumer queries
			the resource directory for the desired resource (F1). The resource
			directory returns a list of potential resource providers without
			considering ALTO (F2). It is then the duty of the resource consumer
			to invoke ALTO (F3/F4), in order to solicit guidance regarding this
			list.
			In the second scenario (see Figure 2), the resource directory has an
			embedded ALTO client, which we will refer to as RDAC in this
			document. After receiving a query for a given resource (F1) the
	resource directory invokes the RDAC to evaluate all resource		resource directory invokes the RDAC to evaluate all resource
	providers it knows. Then it returns a, possibly shortened, list		providers it knows (F2/F3). Then it returns a, possibly shortened,
	containing the "best" resource providers to the resource consumer.		list containing the "best" resource providers to the resource
	From an overall optimization perspective, this scenario is		consumer (F4).
			Peer w. ALTO cli. Tracker ALTO Server
			--------+-------- --------+-------- --------+--------
			| F1 Tracker query | |
			|======================>| |
			| F2 Tracker reply | |
			|<======================| |
			| F3 ALTO client protocol query |
			|---------------------------------------------->|
			| F4 ALTO client protocol reply |
			|<----------------------------------------------|
			| | |
			==== Application protocol (i.e., tracker-based P2P app protocol)
			---- ALTO client protocol
			Figure 1: Basic message sequence chart for resource consumer-
			initiated ALTO query
			Peer Tracker w. RDAC ALTO Server
			--------+-------- --------+-------- --------+--------
			| F1 Tracker query | |
			|======================>| |
			| | F2 ALTO cli. p. query |
			| |---------------------->|
			| | F3 ALTO cli. p. reply |
			| |<----------------------|
			| F4 Tracker reply | |
			|<======================| |
			| | |
			==== Application protocol (i.e., tracker-based P2P app protocol)
			---- ALTO client protocol
			Figure 2: Basic message sequence chart for third-party ALTO query
			Note: the message sequences depicted in Figure 1 and Figure 2 may
			occur both in the target-aware and the target-independent query mode
			(c.f. [I-D.ietf-alto-reqs]). In the target-independent query mode
			no message exchange with the ALTO server might be needed after the
			tracker query, because the candidate resource providers could be
			evaluated using a locally cached "map", which has been retrieved from
			the ALTO server some time ago.
			The problem with the first approach is, that while the resource
			directory might know thousands of peers taking part in a swarm, the
			list returned to the resource consumer is usually shortened for
			efficiency reasons. Therefore, the "best" (in the sense of ALTO)
			potential resource providers might not be contained in that list
			anymore, even before ALTO can consider them.
			For example, consider a swarm with 10,000 peers known to the tracker.
			A new peer wants to join the swarm and therefore asks the tracker for
			a list of peers. For simplicity, we assume that 100 peers would be
			desirable neighbors for the new peer (in the sense of better-than-
			random peer selection) while the other 9,900 are less favorable.
			Assume that the tracker randomly selects 100 peers out of the 10,000
			known peers and returns them to the new peer. With a probability of
			approx. 36% this list does not contain a single favorable peer, and
			with 99% probability there are only four or less of the favorable
			peers on the list. Processing this list with the guiding ALTO
			information will ensure that the few favorable peers are ranked to
			the top of the list; however, the benefit is rather limited as the
			number of favorable peers in the list is just too small. Much better
			traffic optimization could be achieved if the tracker would evaluate
			all 10,000 peers using ALTO, and return a list of 100 peers
			afterwards. This list would then include a significantly higher
			fraction of favorable peers. (Note, that if the tracker returned
			favorable peers only, there would be a risk that the swarm might
			disconnect and split into several partitions. However, finding the
			right mix of ALTO-biased and random peer selection is out of the
			scope of this document.)
			Therefore, from an overall optimization perspective, the second
			scenario with the ALTO client embedded in the resource directory is
	advantageous, because it is ensured that the addresses of the "best"		advantageous, because it is ensured that the addresses of the "best"
	resource providers are actually delivered to the resource consumer.		resource providers are actually delivered to the resource consumer.
	2.2. The need for third-party ALTO server discovery		2.2. The need for third-party ALTO server discovery
	The previous section has shown why it is advantageous that entities		The previous section has shown why it is advantageous that entities
	such as resource directories can perform ALTO queries on behalf of		such as resource directories can perform ALTO queries on behalf of
	resource consumers. We will refer to this kind of ALTO query as		resource consumers. We will refer to this kind of ALTO query as
	"third-party ALTO query".		"third-party ALTO query". ALTO queries are sent to ALTO servers,
			which have knowledge of network topology and other information on
			which the ALTO guidance is based.
	ALTO queries are sent to ALTO servers, which have knowledge of		The challenge for third-party ALTO queries is that they have to be
	network topology and other information on which the ALTO guidance is		answered by the "right" ALTO server, i.e., the ALTO server which has
	based. One deployment scenario for ALTO is to establish a group of		the knowledge to give guidance to the resource consumer on behalf of
			which the query is sent.
			One potential deployment scenario for ALTO is to establish a group of
	centralized ALTO servers which have complete knowledge and therefore		centralized ALTO servers which have complete knowledge and therefore
	can evaluate any pair of resource consumers and providers,		can evaluate any pair of resource consumers and providers,
	respectively.		respectively. Directing a third-party ALTO query to one of these
			servers would be a rather simple task.
	However, it is likely that there will be deployment scenarios with		However, it is likely that there will be deployment scenarios with
	many ALTO servers, each having only partial knowledge and therefore		many ALTO servers, each having only partial knowledge and therefore
	being able to give guidance regarding only a defined group of		being able to give guidance regarding only a defined group of
	resource consumers (e.g., those in its topological vicinity, or those		resource consumers (e.g., those in its topological vicinity, or those
	connected to the same network operator). The reasons for		connected to the same network operator). The reasons for
	partitioning the overall knowledge include scalability and separate		partitioning the overall knowledge include scalability and separate
	administrative responsibilities. For the remainder of this document,		administrative responsibilities. For the remainder of this document,
	we assume that the second scenario has to be supported. The first		we assume that the second scenario has to be supported. The first
	scenario can be seen as special case of it, i.e., a solution that		scenario can be seen as special case of it, i.e., a solution that
	supports the second scenario will support the first scenario as well.		supports the second scenario will support the first scenario as well.
			We will identify and assess several approaches for finding the
	The challenge for third-party ALTO queries is that they have to be		"right" ALTO server, which has the knowledge to give guidance to the
	answered by the "right" ALTO server, i.e, the ALTO server which has		resource consumer on behalf of which a third-party ALTO query is to
	the knowledge to give guidance to the resource consumer on behalf of		be sent.
	which the query is sent.
	3. Peer-to-peer application scenario		3. Peer-to-peer application scenario
	For illustration purposes the following chapters provide several		For illustration purposes the following chapters provide several
	examples, which all refer to the scenario presented in Figure 1.		examples, which all refer to the scenario presented in Figure 3.
	However, the evaluations and conclusions presented in this document		However, the evaluations and conclusions presented in this document
	do not only consider this scenario, but they are much more general.		do not only consider this scenario, but they are much more general.
	+------+ +---------+		+------+ +---------+
	| ALTO |---+---| Tracker |		| ALTO |---+---| Tracker |
	| Srv3 | | +---------+		| Srv3 | | +---------+
	+------+ |		+------+ |
	|RTR| ISP 3		|RTR| ISP 3
	|		|
	**** | ***********		**** | ***********
	skipping to change at page 6, line 37 ¶		skipping to change at page 8, line 37 ¶
	+-------+ | | Srv1 | |NAT| +------+		+-------+ | | Srv1 | |NAT| +------+
	| +------+ |		| +------+ |
	+-------+ | +-------+ | +---------+		+-------+ | +-------+ | +---------+
	|Peer 1b|----+ |Peer 2a|----+------|ConfigSrv|		|Peer 1b|----+ |Peer 2a|----+------|ConfigSrv|
	+-------+ | +-------+ | +---------+		+-------+ | +-------+ | +---------+
	|RTR| |		|RTR| |
	+-------+ | +-------+ | +-------+		+-------+ | +-------+ | +-------+
	|Peer 1c|----+ |Peer 2b|----+-|RTR|--|Peer 2c|		|Peer 1c|----+ |Peer 2b|----+-|RTR|--|Peer 2c|
	+-------+ +-------+ +-------+		+-------+ +-------+ +-------+
	Figure 1: ALTO scenario		Figure 3: ALTO scenario
	Figure 1 shows three networks with connected end hosts, which are		Figure 3 shows three networks with connected end hosts, which are
	operated by different Internet Service Provides, identified as ISP1,		operated by different Internet Service Provides, identified as ISP1,
	ISP2, and ISP3, respectively. These networks are interconnected by		ISP2, and ISP3, respectively. These networks are interconnected by
	Internet backbone networks.		Internet backbone networks.
	ISP1's network connects to (amongst others) three hosts that run the		ISP1's network connects to (amongst others) three hosts that run the
	peers of a P2P application, identified as peers 1a, 1b, and 1c,		peers of a P2P application, identified as peers 1a, 1b, and 1c,
	respectively. Peers 1a and 1b are in topological vicinity, while 1c		respectively. Peers 1a and 1b are in topological vicinity, while 1c
	is more distant from them, because of the additional router (RTR) in		is more distant from them, because of the additional router (RTR) in
	between. ISP1 operates an ALTO server, identified as ALTO Srv1,		between. ISP1 operates an ALTO server, identified as ALTO Srv1,
	which can give guidance to resource consumers in ISP1's network,		which can give guidance to resource consumers in ISP1's network,
	skipping to change at page 8, line 9 ¶		skipping to change at page 10, line 9 ¶
	server 1, because this ALTO server can give guidance to peer 1a.		server 1, because this ALTO server can give guidance to peer 1a.
	Analogical to that, if peer 2a sends a query to the tracker, the		Analogical to that, if peer 2a sends a query to the tracker, the
	tracker needs to ask ALTO server 2 for guidance. The procedures for		tracker needs to ask ALTO server 2 for guidance. The procedures for
	identifying this ALTO server and conveying the guiding information to		identifying this ALTO server and conveying the guiding information to
	the tracker are the scope of this document.		the tracker are the scope of this document.
	4. Classification of solution approaches		4. Classification of solution approaches
	There are several approaches for directing a third-party ALTO query		There are several approaches for directing a third-party ALTO query
	from the RDAC to the "right" ALTO server. The selection of the		from the RDAC to the "right" ALTO server. The selection of the
	"right" ALTO server needs to consider the resource consumer, on		"right" ALTO server needs to consider the resource consumer on behalf
	behalf of which the query will be performed. The set of available		of which the query will be performed. The set of available options
	options therefore depends on the available information about the		therefore depends on the available information about the resource
	resource consumer,		consumer,
	The primary criterion in the following classification is whether ALTO		The primary criterion in the following classification is whether ALTO
	must work together with all existing (P2P) application protocols, or		must work together with all existing (P2P) application protocols, or
	whether we can assume that these protocols can be augmented with new		whether we can assume that these protocols can be augmented with new
	ALTO-specific information fields.		ALTO-specific information fields.
	4.1. Solutions that do not require an update of the application		4.1. Solutions that do not require an update of the application
	protocol		protocol
	If we do not want to make specific assumptions on the (P2P)		If we do not want to make specific assumptions on the (P2P)
	skipping to change at page 8, line 37 ¶		skipping to change at page 10, line 37 ¶
	directory. This address may be the (public) IP address of the		directory. This address may be the (public) IP address of the
	resource consumer, or it may be the external address of the last NAT		resource consumer, or it may be the external address of the last NAT
	on the path between resource consumer and resource directory.		on the path between resource consumer and resource directory.
	The RDAC that wants to perform the third-party ALTO query has two		The RDAC that wants to perform the third-party ALTO query has two
	options:		options:
	o Approach #1: The RDAC invokes a discovery mechanism external to		o Approach #1: The RDAC invokes a discovery mechanism external to
	the ALTO client protocol, in order to map from the resource		the ALTO client protocol, in order to map from the resource
	consumer's IP address to the "right" ALTO server. The ALTO query		consumer's IP address to the "right" ALTO server. The ALTO query
	will then be sent there directly (see Figure 2).		will then be sent there directly (see Figure 4).
	o Approach #2: Independent of the resource consumer's identity, the		o Approach #2: Independent of the resource consumer's identity, the
	RDAC uses the ALTO client protocol to send the ALTO query to one		RDAC uses the ALTO client protocol to send the ALTO query to one
	preconfigured ALTO server. The resource consumer's IP address is		preconfigured ALTO server. The resource consumer's IP address is
	included in the query message. Based on this IP address and using		included in the query message. Based on this IP address and using
	mechanisms of the ALTO client protocol the first ALTO server		mechanisms of the ALTO client protocol the first ALTO server
	forwards (see Figure 3) or redirects (see Figure 4) the query to		forwards (see Figure 5) or redirects (see Figure 6) the query to
	the "right" ALTO server. This implies that ALTO servers must know		the "right" ALTO server. This implies that ALTO servers must know
	each other, based on some discovery mechanism or manual		each other, based on some discovery mechanism or manual
	configuration.		configuration.
	Peer 1a Tracker ALTO Srv1 DNS		Peer 1a Tracker ALTO Srv1 DNS
	----+---- ----+---- ----+---- ----+----		----+---- ----+---- ----+---- ----+----
	| | | |		| | | |
	| F1 Tracker Q | | |		| F1 Tracker Q | | |
	|==============>| F2 ALTO disc. Q (peer1a) |		|==============>| F2 ALTO disc. Q (peer1a) |
	| |******************************>|		| |******************************>|
	skipping to change at page 9, line 24 ¶		skipping to change at page 11, line 24 ¶
	| |-------------->| |		| |-------------->| |
	| | F5 ALTO cp R | |		| | F5 ALTO cp R | |
	| F6 Tracker R |<--------------| |		| F6 Tracker R |<--------------| |
	|<==============| | |		|<==============| | |
	| | | |		| | | |
	==== Application protocol (i.e., tracker-based P2P app protocol)		==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol		---- ALTO client protocol
	**** ALTO discovery protocol (e.g., based on DNS queries)		**** ALTO discovery protocol (e.g., based on DNS queries)
	Figure 2: Message sequence chart for Approach 1		Figure 4: Message sequence chart for Approach 1
	Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3		Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3
	----+---- ----+---- ----+---- ----+---- ----+----		----+---- ----+---- ----+---- ----+---- ----+----
	| | | F1/2 HELLO | |		| | | F1/2 HELLO | |
	| | |<###########>| F3/4 HELLO |		| | |<###########>| F3/4 HELLO |
	| | | F5/6 HELLO |<###########>|		| | | F5/6 HELLO |<###########>|
	| | |<#########################>|		| | |<#########################>|
	| F7 Tracker Q | | | |		| F7 Tracker Q | | | |
	|==============>| | | |		|==============>| | | |
	| | F8 ALTO cp Q | | |		| | F8 ALTO cp Q | | |
	skipping to change at page 9, line 49 ¶		skipping to change at page 11, line 49 ¶
	| | |-------------------------->|		| | |-------------------------->|
	| | F11 ALTO cp R | | |		| | F11 ALTO cp R | | |
	| F12 Tracker R |<------------------------------------------|		| F12 Tracker R |<------------------------------------------|
	|<==============| | | |		|<==============| | | |
	| | | | |		| | | | |
	==== Application protocol (i.e., tracker-based P2P app protocol)		==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol		---- ALTO client protocol
	#### Inter-ALTO server protocol		#### Inter-ALTO server protocol
	Figure 3: Message sequence chart for Approach 2 (query forwarding)		Figure 5: Message sequence chart for Approach 2 (query forwarding)
	Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3		Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3
	----+---- ----+---- ----+---- ----+---- ----+----		----+---- ----+---- ----+---- ----+---- ----+----
	| | | F1/2 HELLO | |		| | | F1/2 HELLO | |
	| | |<###########>| F3/4 HELLO |		| | |<###########>| F3/4 HELLO |
	| | | F5/6 HELLO |<###########>|		| | | F5/6 HELLO |<###########>|
	| | |<#########################>|		| | |<#########################>|
	| F7 Tracker Q | | | |		| F7 Tracker Q | | | |
	|==============>| | | |		|==============>| | | |
	| | F8 ALTO cp Q | | |		| | F8 ALTO cp Q | | |
	| |------------------------------------------>|		| |------------------------------------------>|
	skipping to change at page 10, line 27 ¶		skipping to change at page 12, line 27 ¶
	| |-------------->| | |		| |-------------->| | |
	| | F11 ALTO cp R | | |		| | F11 ALTO cp R | | |
	| F12 Tracker R |<--------------| | |		| F12 Tracker R |<--------------| | |
	|<==============| | | |		|<==============| | | |
	| | | | |		| | | | |
	==== Application protocol (i.e., tracker-based P2P app protocol)		==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol		---- ALTO client protocol
	#### Inter-ALTO server protocol		#### Inter-ALTO server protocol
	Figure 4: Message sequence chart for Approach 2 (query redirection)		Figure 6: Message sequence chart for Approach 2 (query redirection)
	4.2. Solutions that do require an update of the application protocol		4.2. Solutions that do require an update of the application protocol
	If we assume that applications can be upgraded in order to support		If we assume that applications can be upgraded in order to support
	ALTO, the resource consumer can provide additional information to the		ALTO, the resource consumer can provide additional information to the
	RDAC in order to assist the process of ALTO server discovery.		RDAC in order to assist the process of ALTO server discovery.
	o Approach #3: Using the extended application protocol, the resource		o Approach #3: Using the extended application protocol, the resource
	consumer sends an additional peer-ID, which can be understood by		consumer sends an additional peer-ID, which can be understood by
	ALTO, to the resource directory. This peer-ID could be used to		ALTO, to the resource directory. This peer-ID could be used to
	uniquely identify resource consumers and providers located behind		uniquely identify resource consumers and providers located behind
	NATs. The RDAC uses this peer-ID in addition to or instead of the		NATs. The RDAC uses this peer-ID in addition to or instead of the
	resource consumer's IP address (see Figure 5). In all other		resource consumer's IP address (see Figure 7). In all other
	aspects this approach is identical to approach #1.		aspects this approach is identical to approach #1.
	o Approach #4: This approach is identical to approach #2, except		o Approach #4: This approach is identical to approach #2, except
	that the peer-ID is used instead of the IP address, as described		that the peer-ID is used instead of the IP address, as described
	in approach #3.		in approach #3.
	o Approach #5: The resource consumer discovers its ALTO server on		o Approach #5: The resource consumer discovers its ALTO server on
	its own (i.e., not a third-party discovery). Using the extended		its own (i.e., not a third-party discovery). Using the extended
	application protocol it sends the ALTO server's address to the		application protocol it sends the ALTO server's address to the
	RDAC. The RDAC can use it for sending third-party ALTO queries		RDAC. The RDAC can use it for sending third-party ALTO queries
	skipping to change at page 11, line 38 ¶		skipping to change at page 13, line 38 ¶
	| | | F7 ALTO cp R | |		| | | F7 ALTO cp R | |
	| F8 Tracker R | |<--------------| |		| F8 Tracker R | |<--------------| |
	|<===========================| | |		|<===========================| | |
	| | | | |		| | | | |
	;;;; Configuration protocol (e.g., DHCP)		;;;; Configuration protocol (e.g., DHCP)
	==== Application protocol (i.e., tracker-based P2P app protocol)		==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol		---- ALTO client protocol
	**** ALTO discovery protocol (e.g., based on DNS queries)		**** ALTO discovery protocol (e.g., based on DNS queries)
	Figure 5: Message sequence chart for Approach 3		Figure 7: Message sequence chart for Approach 3
	Peer 2a ConfigSrv Tracker ALTO Srv2		Peer 2a ConfigSrv Tracker ALTO Srv2
	----+---- ----+---- ----+---- ----+----		----+---- ----+---- ----+---- ----+----
	| F1 Config Q | | |		| F1 Config Q | | |
	|;;;;;;;;;;;;;;>| | |		|;;;;;;;;;;;;;;>| | |
	| | | |		| | | |
	| F2 Config R | | |		| F2 Config R | | |
	| + Addr. of ALTO Srv2 | |		| + Addr. of ALTO Srv2 | |
	|<;;;;;;;;;;;;;;| | |		|<;;;;;;;;;;;;;;| | |
	| | | |		| | | |
	skipping to change at page 12, line 27 ¶		skipping to change at page 14, line 27 ¶
	| | |-------------->|		| | |-------------->|
	| | | F5 ALTO cp R |		| | | F5 ALTO cp R |
	| F6 Tracker R | |<--------------|		| F6 Tracker R | |<--------------|
	|<==============================| |		|<==============================| |
	| | | |		| | | |
	;;;; Configuration protocol (e.g., DHCP)		;;;; Configuration protocol (e.g., DHCP)
	==== Application protocol (i.e., tracker-based P2P app protocol)		==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol		---- ALTO client protocol
	Figure 6: Message sequence chart for Approach 5		Figure 8: Message sequence chart for Approach 5
	Peer 2a ConfigSrv Tracker ALTO Srv2		Peer 2a ConfigSrv Tracker ALTO Srv2
	----+---- ----+---- ----+---- ----+----		----+---- ----+---- ----+---- ----+----
	| F1 Config Q | | |		| F1 Config Q | | |
	|;;;;;;;;;;;;;;>| | |		|;;;;;;;;;;;;;;>| | |
	| | | |		| | | |
	| F2 Config R | | |		| F2 Config R | | |
	| + Addr. of ALTO Srv2 | |		| + Addr. of ALTO Srv2 | |
	|<;;;;;;;;;;;;;;| | |		|<;;;;;;;;;;;;;;| | |
	| | | |		| | | |
	skipping to change at page 13, line 31 ¶		skipping to change at page 15, line 31 ¶
	| F5 Tracker Q (Info from ALTO reply + meas'mt.)|		| F5 Tracker Q (Info from ALTO reply + meas'mt.)|
	|==============================>| |		|==============================>| |
	| F6 Tracker R | | |		| F6 Tracker R | | |
	|<==============================| |		|<==============================| |
	| | | |		| | | |
	;;;; Configuration protocol (e.g., DHCP)		;;;; Configuration protocol (e.g., DHCP)
	==== Application protocol (i.e., tracker-based P2P app protocol)		==== Application protocol (i.e., tracker-based P2P app protocol)
	---- ALTO client protocol		---- ALTO client protocol
	Figure 7: Message sequence chart for Approach 6		Figure 9: Message sequence chart for Approach 6
	5. Discussion		5. Discussion
	This section assesses and compares the different approaches		This section assesses and compares the different approaches
	introduced above, regarding trust, scalability, integration into		introduced above, regarding trust, scalability, integration into
	existing ISP infrastructure and management processes, modification of		existing ISP infrastructure and management processes, modification of
	existing applications, and ongoing ALTO architecture specification		existing applications, and ongoing ALTO architecture specification
	works.		works.
	5.1. Approach #1		5.1. Approach #1
	The existence of a mechanism according to approach #1 is assumed by		The existence of a mechanism according to approach #1 is assumed by
	[I-D.penno-alto-protocol].		[I-D.ietf-alto-protocol].
	This approach does not require any changes of existing (P2P)		This approach does not require any changes of existing (P2P)
	application protocols. However, the RDAC needs to implement an		application protocols. However, the RDAC needs to implement an
	additional protocol for performing third-party ALTO server discovery.		additional protocol for performing third-party ALTO server discovery.
	One possible way of implementing this approach would be based on DNS,		One possible way of implementing this approach would be based on DNS,
	providing a mapping from the resource consumer's IP address to the IP		providing a mapping from the resource consumer's IP address to the IP
	address of the corresponding "right" ALTO server. DNS is proven to		address of the corresponding "right" ALTO server. DNS is proven to
	be scalable and has well-understood mechanisms for delegating		be scalable and has well-understood mechanisms for delegating
	authority. Network operators are used to DNS management.		authority. Network operators are used to DNS management.
	skipping to change at page 17, line 18 ¶		skipping to change at page 19, line 18 ¶
	mechanism is required for an important class of applications, namely		mechanism is required for an important class of applications, namely
	tracker-based P2P applications. Several solution approaches are		tracker-based P2P applications. Several solution approaches are
	classified and evaluated. Assuming that ALTO should work together		classified and evaluated. Assuming that ALTO should work together
	with already deployed application protocols, "Approach #1" seems to		with already deployed application protocols, "Approach #1" seems to
	be most promising. In this approach, the resource directory invokes		be most promising. In this approach, the resource directory invokes
	a discovery mechanism external to the ALTO client protocol, in order		a discovery mechanism external to the ALTO client protocol, in order
	to map from the resource consumer's IP address to the "right" ALTO		to map from the resource consumer's IP address to the "right" ALTO
	server.		server.
	The existence of such a mechanism according to "Approach #1" is		The existence of such a mechanism according to "Approach #1" is
	assumed by [I-D.penno-alto-protocol].		assumed by [I-D.ietf-alto-protocol].
	Further action is required to standardize a protocol and procedures		Further action is required to standardize a protocol and procedures
	according to "Approach #1".		according to "Approach #1".
	7. IANA Considerations		7. IANA Considerations
	This document does not mandate any immediate IANA actions. However,		This document does not mandate any immediate IANA actions. However,
	such IANA considerations may arise from future ALTO discovery		such IANA considerations may arise from future ALTO discovery
	specification documents which try to meet the requirements given		specification documents which try to meet the requirements given
	here.		here.
	8. Security Considerations		8. Security Considerations
	This early version of this memo does not yet have any security		This early version of this memo does not yet have any security
	considerations, but they will be added in future revision.		considerations, but they will be added in future revision.
	9. Informative References		9. References
	[I-D.ietf-alto-problem-statement]		[I-D.ietf-alto-protocol]
	Seedorf, J. and E. Burger, "Application-Layer Traffic		Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
	Optimization (ALTO) Problem Statement",		draft-ietf-alto-protocol-02 (work in progress),
	draft-ietf-alto-problem-statement-02 (work in progress),		March 2010.
	July 2009.
	[I-D.ietf-alto-reqs]		[I-D.ietf-alto-reqs]
	Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.		Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.
	Yang, "Application-Layer Traffic Optimization (ALTO)		Yang, "Application-Layer Traffic Optimization (ALTO)
	Requirements", draft-ietf-alto-reqs-01 (work in progress),		Requirements", draft-ietf-alto-reqs-03 (work in progress),
	July 2009.		February 2010.
	[I-D.penno-alto-protocol]		[I-D.kiesel-alto-h12]
	Penno, R. and Y. Yang, "ALTO Protocol",		Kiesel, S. and M. Stiemerling, "ALTO H12",
	draft-penno-alto-protocol-03 (work in progress),		draft-kiesel-alto-h12-01 (work in progress), March 2010.
	July 2009.
	[I-D.song-alto-server-discovery]		[I-D.song-alto-server-discovery]
	Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual,		Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual,
	"ALTO Service Discovery",		"ALTO Service Discovery",
	draft-song-alto-server-discovery-01 (work in progress),		draft-song-alto-server-discovery-01 (work in progress),
	July 2009.		July 2009.
			[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
			Optimization (ALTO) Problem Statement", RFC 5693,
			October 2009.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The authors would like to thank Haibin Song, Richard Alimi, and Roni		The authors would like to thank Haibin Song, Richard Alimi, and Roni
	Even for fruitful discussions during the 75th IETF meeting.		Even for fruitful discussions during the 75th IETF meeting.
	Sebastian Kiesel is partially supported by the NAPA-WINE project		Marco Tomsu and Nico Schwan are partially supported by the ENVISION
	(Network-Aware P2P-TV Application over Wise Networks,		project (http://www.envision-project.org), a research project
	http://www.napa-wine.org), a research project supported by the		supported by the European Commission under its 7th Framework Program
	European Commission under its 7th Framework Program (contract no.		(contract no. 248565). The views and conclusions contained herein
	214412). The views and conclusions contained herein are those of the		are those of the authors and should not be interpreted as necessarily
	authors and should not be interpreted as necessarily representing the		representing the official policies or endorsements, either expressed
	official policies or endorsements, either expressed or implied, of		or implied, of the ENVISION project or the European Commission.
	the NAPA-WINE project or the European Commission.
	Marco Tomsu is partially supported by the 4WARD project		Michael Scharf is supported by the German-Lab project
	(http://www.4ward-project.eu), a research project supported by the		(http://www.german-lab.de) funded by the German Federal Ministry of
	European Commission under its 7th Framework Program (contract no.		Education and Research (BMBF).
	216041). The views and conclusions contained herein are those of the
	authors and should not be interpreted as necessarily representing the
	official policies or endorsements, either expressed or implied, of
	the 4WARD project or the European Commission.
	Authors' Addresses		Authors' Addresses
	Sebastian Kiesel		Sebastian Kiesel
	NEC Laboratories Europe		University of Stuttgart Computing Center
	Kurfuerstenanlage 36		Allmandring 30
	Heidelberg 69115		Stuttgart 70550
	Germany		Germany
	Email: kiesel@nw.neclab.eu		Email: ietf-alto@skiesel.de
	URI: http://www.nw.neclab.eu/		URI: http://www.rus.uni-stuttgart.de/nks/
	Marco Tomsu		Marco Tomsu
	Alcatel-Lucent Bell Labs		Alcatel-Lucent Bell Labs
	Lorenzstrasse 10		Lorenzstrasse 10
	Stuttgart 70435		Stuttgart 70435
	Germany		Germany
	Email: marco.tomsu@alcatel-lucent.com		Email: marco.tomsu@alcatel-lucent.com
	URI: www.alcatel-lucent.com/bell-labs		URI: www.alcatel-lucent.com/bell-labs
			Nico Schwan
			Alcatel-Lucent Bell Labs
			Lorenzstrasse 10
			Stuttgart 70435
			Germany
			Email: nico.schwan@alcatel-lucent.com
			URI: www.alcatel-lucent.com/bell-labs
			Michael Scharf
			Alcatel-Lucent Bell Labs
			Lorenzstrasse 10
			Stuttgart 70435
			Germany
			Email: michael.scharf@alcatel-lucent.com
			URI: www.alcatel-lucent.com/bell-labs
End of changes. 45 change blocks.
	130 lines changed or deleted		223 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/