< draft-gu-alto-redistribution-02.txt		draft-gu-alto-redistribution-03.txt >
	ALTO Y. Gu		ALTO Y. Gu
	Internet-Draft Huawei		Internet-Draft Huawei
	Intended status: BCP R. Alimi		Intended status: BCP R. Alimi
	Expires: September 9, 2010 Yale University		Expires: January 13, 2011 Yale University
	R. Even		R. Even
	Huawei		Huawei
	March 8, 2010		July 12, 2010
	ALTO Information Redistribution		ALTO Information Redistribution
	draft-gu-alto-redistribution-02		draft-gu-alto-redistribution-03
	Abstract		Abstract
	The ALTO protocol proposes several mechanisms to increase		The ALTO protocol proposes several mechanisms to increase
	scalability. One of the proposed mechanisms is ALTO information		scalability. One of the proposed mechanisms is ALTO information
	redistribution. This document concretely defines ALTO Information		redistribution. This document concretely defines ALTO Information
	Redistribution, indicates suggested extensions to the ALTO Protocol		Redistribution, indicates suggested extensions to the ALTO Protocol
	to support redistribution, and shows how redistribution could be used		to support redistribution, and shows how redistribution could be used
	in practice.		in practice.
	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 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). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 13, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 4		2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 4
	3. Redistribution Framework . . . . . . . . . . . . . . . . . . . 4		3. Redistribution Framework . . . . . . . . . . . . . . . . . . . 4
	3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 5		3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 5
	3.2. ALTO Information Types . . . . . . . . . . . . . . . . . . 5		3.2. ALTO Information Types . . . . . . . . . . . . . . . . . . 5
	3.3. Redistribution Scheme Design . . . . . . . . . . . . . . . 6		3.3. Redistribution Scheme Design . . . . . . . . . . . . . . . 6
	4. ALTO Protocol Requirements . . . . . . . . . . . . . . . . . . 6		4. ALTO Redistribution Solutions Analysis . . . . . . . . . . . . 6
	4.1. Signature and Verification . . . . . . . . . . . . . . . . 6		4.1. PUSH Information into Overlay . . . . . . . . . . . . . . 7
	4.2. Redistributable Indication and Expiration Time . . . . . . 6		4.1.1. General Requirements for PUSH . . . . . . . . . . . . 7
	5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1.2. Tracker Acts as Redistribution Proxy . . . . . . . . . 8
	5.1. Tracker-based redistribution . . . . . . . . . . . . . . . 7		4.1.3. Supernode Acts as Redistribution Proxy . . . . . . . . 8
	5.2. Trackerless redistribution . . . . . . . . . . . . . . . . 8		4.1.4. Advantages of PUSH . . . . . . . . . . . . . . . . . . 8
	5.2.1. Lookup in DHT . . . . . . . . . . . . . . . . . . . . 9		4.2. PULL Inforamtion into Overlay . . . . . . . . . . . . . . 9
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		4.2.1. PULL Use Cases . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 10		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		6.2. Informative References . . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	When providing an ALTO service, Network Providers offer information		When providing an ALTO service, Network Providers offer information
	to clients with the goal of helping P2P applications to perform		to clients with the goal of helping P2P applications to perform
	better peer selection and improving network efficiency. The ALTO		better peer selection and improving network efficiency. The ALTO
	Service becomes a distribution point of network information for ALTO		Service becomes a distribution point of network information for ALTO
	Clients within its network. A Network Provider may deploy an ALTO		Clients within its network. A Network Provider may deploy an ALTO
	Service using techniques such as load balancing and caching to handle		Service using techniques such as load balancing and caching to handle
	a large number of subscribers. In this document, we discuss an		a large number of subscribers. In this document, we discuss an
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 12 ¶
	peers (e.g., participating in a different swarm, or be in contact		peers (e.g., participating in a different swarm, or be in contact
	with a different set of peers within the same swarm).		with a different set of peers within the same swarm).
	3.3. Redistribution Scheme Design		3.3. Redistribution Scheme Design
	While this document does not fully specify a particular		While this document does not fully specify a particular
	redistribution scheme, we provide a sampling of decisions that should		redistribution scheme, we provide a sampling of decisions that should
	be considered when designing an implementing a redistribution scheme.		be considered when designing an implementing a redistribution scheme.
	This list can be used as a guide for implementers when designing a		This list can be used as a guide for implementers when designing a
	redistribution scheme for a particular setting. Considerations for a		redistribution scheme for a particular setting. Considerations for a
	redistribution scheme include:Which ALTO Client(s) directly query the		redistribution scheme include:
	ALTO Server?
	o What method is used for locating redistributed ALTO information?		o Who places the ALTO Information onto overlay, and how the ALTO
			Information is published on the overlay
			o How could peers decide whether to get ALTO Information from ALTO
			Server or to get from Overlay?
			o What method is used for peers to locate redistributed ALTO
			information?
			o What protocol is used for retrieving redistributed ALTO
			information?
			o How could peers verify the Redistributed Information it obtained.
			o How to update the Redistributed Information on time and who is
			responsible for updating.
	o What naming scheme is used to specify the ALTO Server hostname,		o What naming scheme is used to specify the ALTO Server hostname,
	port, and input parameters in the protocol for locating		port, and input parameters in the protocol for locating
	redistributed ALTO information? For example, the naming scheme		redistributed ALTO information? For example, the naming scheme
	could define how to compute the 'key' in a DHT.		could define how to compute the 'key' in a DHT.
	o What protocol is used for retrieving redistributed ALTO
	information?
	o How is the redistributed information encoded? Note that the		o How is the redistributed information encoded? Note that the
	original response from the ALTO Service may be reformatted (e.g.,		original response from the ALTO Service may be reformatted (e.g.,
	compressed) for redistribution. Note that if this approach is		compressed) for redistribution. Note that if this approach is
	taken and ALTO Clients still wish to verify received information,		taken and ALTO Clients still wish to verify received information,
	ALTO Clients should be able to reconstruct the ALTO Service's		ALTO Clients should be able to reconstruct the ALTO Service's
	original response (e.g., via decompression). If a lossy		original response (e.g., via decompression). If a lossy
	transformation is used (e.g., filtering), ALTO Clients may not be		transformation is used (e.g., filtering), ALTO Clients may not be
	able to verify the received information.		able to verify the received information.
	4. ALTO Protocol Requirements		4. ALTO Redistribution Solutions Analysis
	4.1. Signature and Verification		In this section, we present our considerations on Redistribution
			Implementation. In the previous section, several questions have been
			enumerated, and the answer to the first question is the baseline of
			ALTO Redistribution. There are two distinct ways to place the ALTO
			Information into the overlay: Redistribution Proxy PUSH the
			Information into the overlay or components of the overlay PULL the
			Information into the Overlay.
	We proposed to consider signature mechanism to ensure that an ALTO		The main difference betwen PUSH and PULL is as follows.
	client can verify that a redistributed information is generated from
	the right ALTO server and is based on the correct input parameters in
	-01 version. The basic idea has been accepted in [I-D.penno-alto-
	protocol] and is described in section 7.5.3. [I-D.penno-alto-
	protocol] also introduces how public key is obtained.
	4.2. Redistributable Indication and Expiration Time		o In PUSH, the Redistribution Proxy can publish the updated
			redistribution Information into the overlay. Since the
			Redistribution Proxy can be much intelligent than a normal peer,
			e.g. Redistribution Proxy has overall understanding of the
			overlay, it can make decision on how to distribute the Information
			in order to utilize the overlay much efficient. For example,
			integration with DECADE, distribution via a CDN (many P2P apps are
			integrating CDNs now). We will add more use case for PUSH in our
			later version.
	In -01 version, we proposed that ALTO server should using HTTP		o While In PULL, peers individually pull/request updated ALTO
	Caching directives to indicate whether a response could be		information from an overlay or ALTO server. Considering the
	redistributed and when a redistributed information should be updated.		general size of a redistributable information, there might be an
	In the lastest version of [I-D.penno-alto-protocol], An ALTO server		out-of-control flooding through the overlay.
	MAY indicate that a response is suitable fore redistribution by
	including a "redistribution" JSON object and the Expiration time is
	also indicated as JSON object.
	5. Use Cases		In the following text, we introduces some consideration of both PUSH
			and PULL, and conclude other features of PUSH and PULL.
			4.1. PUSH Information into Overlay
			In PUSH method, we introduce a new terminology, Redistribution Proxy.
			A Redistribution Proxy can be a Tracker in Tracker-based P2P Overlay
			or a supernode either in Tracker-based or Trackerless P2P Overlay.
			The duty of Redistribution Proxy to accecpt the redistributable
			information from ALTO Server and push the information into the
			overlay. There are two options on obtaining redistributable
			inforamtion from ALTO Server. One is Redistribution Proxy request
			and ALTO Server answers or ALTO Server positively update the
			information to the Redistribution Proxy. Since the number of
			Redistribution Proxy is much fewer than the total number of ALTO
			Clients, so the latter option does not occupy much connection
			resources on ALTO Server. In our draft, we introduce the PUSH based
			on the latter option, which is ALTO Server pushes the uptaed
			information to Redistribution Proxy positivly.
			4.1.1. General Requirements for PUSH
			To make PUSH feasible, the following requirements must be satisfied.
			o Redistribution Proxy MUST has public IP Addresse, so that both
			ALTO server and Peers can connect with it without NAT issue.
			o ALTO server MUST know Redistribution proxy's IP Address.
			o Redistribution Proxy MUST be reliable.
			4.1.2. Tracker Acts as Redistribution Proxy
			If Tracker is deployed as Redistribution Proxy, it has two choices.
			Tracker can publish the ALTO Information into overlay, then peers can
			search and obtain the Information through Overlay.
			Or Tracker can store the Information on itself, and answer peers'
			particular request based on the Information. For those information
			that is not redistributable, peers can request directly from ALTO
			server or ask Tracker to request from ALTO server and answer.
			In both case, an indication is necessary for telling peers where to
			get ALTO Service. For example, peers should know that for those
			redistributable type of Information, peers should first request from
			Tracker, and for those unredistributable, they should request from
			ALTO Sever. Which can be configured by application. The definition
			of indication configuration is out of the scope of ALTO.
			4.1.3. Supernode Acts as Redistribution Proxy
			If Supernode is deployed as Redistribution Proxy, it has two choices
			as well.
			Supernode store the Information and answer peers request. In this
			case, peers should learn Supernode's IP Address in advance.
			Or Supernode just publish the Information into the overlay and then
			peers search and get the Information through the overlay.
			In both case, an indication is necessary as well.
			4.1.4. Advantages of PUSH
			The advantages of PUSH is obvious.
			1 Intelligence. Refer to the text that explain the main difference
			between PUSH and PULL.
			2 Scalability. PUSH can significantly reduce the request directly
			sent to ALTO Server, which can reduce the load on ALTO Server.
			3 Quick updating. Once the ALTO Information is updated in Server,
			ALTO server can notify the Redistribution Proxy with new
			Information.
			4 Good Consistency, because redistributed Informaiton can be updated
			in time.
			5 Never expiration, because the redistributed Information is always
			as new as those in the server.
			6 Safe. Redistribution Proxy is reliable.
			7 Low latency, because peers do not need to search and locate the
			redistribution Information on the overlay, which is extremely
			meaningful for time sensitive application, e.g. Live streaming.
			4.2. PULL Inforamtion into Overlay
			There could be Tracker or peers who PULL the ALTO Information into
			the overlay.
			If it's peer that pull ALTO information into the overlay, several
			aspects should be considered.
			1 Where to request for ALTO Information first, ALTO server or
			overlay? This can be configured by application, e.g. always
			request redistributable type of ALTO Information through Overlay
			first. If appliction configuration recommends peer to request
			from ALTO Server first, this won't be any good to ALTO
			Redistribution.
			2 Publishing mechanism. Should peer store the Information on itself
			and publish the resource into the overlay, or should peer store
			the Information on the corresponding responsible peer on the
			overlay? However, this won't make much difference.
			3 How to authenticate the Information? We have introduce a security
			method with Signature, which is now in ALTP Protocol, while the
			question is where to get the Public Key.
			4.2.1. PULL Use Cases
	The architecture of a particular P2P application will affect the		The architecture of a particular P2P application will affect the
	redistribution mechanism. Generally speaking, there are two kinds of		redistribution mechanism. Generally speaking, there are two kinds of
	P2P applications: trackerless, and those using a tracker. In		P2P applications: trackerless, and those using a tracker. In
	Tracker-based applications, a resource directory is maintained on a		Tracker-based applications, a resource directory is maintained on a
	tracker, and peers contact the tracker to learn about new peers. In		tracker, and peers contact the tracker to learn about new peers. In
	a Trackerless overlay, peers are organized through a particular		a Trackerless overlay, peers are organized through a particular
	algorithm, e.g. DHT, and they publish or find resources by routing		algorithm, e.g. DHT, and they publish or find resources by routing
	through the overlay.		through the overlay.
	5.1. Tracker-based redistribution		4.2.1.1. Tracker-based redistribution
	1. The Tracker finds the ALTO server on behalf of a peer, queries		1. The Tracker finds the ALTO server on behalf of a peer, queries
	the necessary ALTO information and replies to the peer with the		the necessary ALTO information and replies to the peer with the
	ALTO information as well as the candidate list.		ALTO information as well as the candidate list.
	[I-D.kiesel-alto-3pdisc] describes several methods by which		[I-D.kiesel-alto-3pdisc] describes several methods by which
	Tracker can find the right ALTO server. Note that the Tracker		Tracker can find the right ALTO server. Note that the Tracker
	might omit the 'more preferred' peers when making the original		might omit the 'more preferred' peers when making the original
	selection. However, the ALTO Information can be applied to peers		selection. However, the ALTO Information can be applied to peers
	learned from other sources (e.g., Peer Exchange and/or DHT).		learned from other sources (e.g., Peer Exchange and/or DHT).
	skipping to change at page 8, line 40 ¶		skipping to change at page 11, line 40 ¶
	^ | | ^		^ | | ^
	^ +---------------+ ^		^ +---------------+ ^
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	--- ALTO query and response protocol		--- ALTO query and response protocol
	ooo peer request protocol in p2p overlay (out of scope)		ooo peer request protocol in p2p overlay (out of scope)
	*** ALTO information redistribution in overlay		*** ALTO information redistribution in overlay
	Information redistribution among peers in Tracker-based P2P		Information redistribution among peers in Tracker-based P2P
	Application		Application
	5.2. Trackerless redistribution		4.2.1.2. Trackerless redistribution
	In a Trackerless overlay, peers obtain the ALTO information, then		In a Trackerless overlay, peers obtain the ALTO information, then
	publish it via a P2P protocol (e.g., in a DHT). Peers can also		publish it via a P2P protocol (e.g., in a DHT). Peers can also
	locate and retrieve ALTO information through the protocol.		locate and retrieve ALTO information through the protocol.
	+------------+		+------------+
	| |		| |
	| ALTO |		| ALTO |
	| Server |		| Server |
	| |		| |
	skipping to change at page 9, line 31 ¶		skipping to change at page 12, line 31 ¶
	^ * (2) * ^		^ * (2) * ^
	^ * Overlay redistribution * ^		^ * Overlay redistribution * ^
	^ *************************** ^		^ *************************** ^
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	--- ALTO query and response protocol		--- ALTO query and response protocol
	*** ALTO information searching and redistribution		*** ALTO information searching and redistribution
	by using P2P Protocol		by using P2P Protocol
	Information redistribution among peers in Trackerless P2P Overlay		Information redistribution among peers in Trackerless P2P Overlay
	5.2.1. Lookup in DHT		4.2.1.2.1. Lookup in DHT
	When searching for a piece of data in a DHT, a node constructs an		When searching for a piece of data in a DHT, a node constructs an
	identifier for the desired data. We propose here a simple naming		identifier for the desired data. We propose here a simple naming
	scheme that can be used to lookup ALTO Information in a DHT. This is		scheme that can be used to lookup ALTO Information in a DHT. This is
	provided as a suggestion for an implementation technique, and is not		provided as a suggestion for an implementation technique, and is not
	a requirement on redistribution implementations employing a DHT.		a requirement on redistribution implementations employing a DHT.
	Also note that the ALTO Information does not need to be included		Also note that the ALTO Information does not need to be included
	directly in the DHT. A mechanism such as the Distributed Tracker		directly in the DHT. A mechanism such as the Distributed Tracker
	implemented in Vuze [http://www.vuze.com] could be used to locate an		implemented in Vuze [http://www.vuze.com] could be used to locate an
	skipping to change at page 10, line 25 ¶		skipping to change at page 13, line 25 ¶
	hash("alto:http://alto.example.com:80/capability").		hash("alto:http://alto.example.com:80/capability").
	2) Full Network Map.		2) Full Network Map.
	hash("alto:http://alto.example.com:80/prop/pid/map").		hash("alto:http://alto.example.com:80/prop/pid/map").
	3) Full Path Cost among all PIDs		3) Full Path Cost among all PIDs
	hash("alto:http://alto.example.com:80/cost/pid/map").		hash("alto:http://alto.example.com:80/cost/pid/map").
	6. Acknowledgments		5. Acknowledgments
	The authors would like to give special thanks to Jan Seedorf and many		The authors would like to give special thanks to Jan Seedorf and many
	others for the illuminative discussion in the mailing list. The		others for the illuminative discussion in the mailing list. The
	authors also thank David Bryan for providing comments on preliminary		authors also thank David Bryan for providing comments on preliminary
	versions of the draft.		versions of the draft.
	7. References		6. References
	7.1. Normative References		6.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.
	[I-D.ietf-alto-problem-statement]		[I-D.ietf-alto-problem-statement]
	Seedorf, J. and E. Burger, "Application-Layer Traffic		Seedorf, J. and E. Burger, "Application-Layer Traffic
	Optimization (ALTO) Problem Statement",		Optimization (ALTO) Problem Statement",
	draft-ietf-alto-problem-statement-04 (work in progress),		draft-ietf-alto-problem-statement-04 (work in progress),
	September 2009.		September 2009.
	7.2. Informative References		6.2. Informative References
	[I-D.penno-alto-protocol]		[I-D.penno-alto-protocol]
	Penno, R. and Y. Yang, "ALTO Protocol",		Penno, R. and Y. Yang, "ALTO Protocol",
	draft-penno-alto-protocol-04 (work in progress),		draft-penno-alto-protocol-04 (work in progress),
	October 2009.		October 2009.
	[I-D.kiesel-alto-3pdisc]		[I-D.kiesel-alto-3pdisc]
	Kiesel, S. and M. Tomsu, "Third-party ALTO server		Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M.
	discovery", draft-kiesel-alto-3pdisc-01 (work in		Stiemerling, "Third-party ALTO server discovery",
	progress), October 2009.		draft-kiesel-alto-3pdisc-03 (work in progress), July 2010.
	[I-D.song-alto-server-discovery]		[I-D.song-alto-server-discovery]
	Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual,		Yongchao, S., Tomsu, M., Garcia, G., Wang, Y., and V.
	"ALTO Service Discovery",		Avila, "ALTO Service Discovery",
	draft-song-alto-server-discovery-01 (work in progress),		draft-song-alto-server-discovery-03 (work in progress),
	July 2009.		July 2010.
	Authors' Addresses		Authors' Addresses
	Gu Yingjie		Gu Yingjie
	Huawei		Huawei
	Baixia Road No. 91		Baixia Road No. 91
	Nanjing, Jiangsu Province 210001		Nanjing, Jiangsu Province 210001
	P.R.China		P.R.China
	Phone: +86-25-84565868		Phone: +86-25-84565868
End of changes. 26 change blocks.
	64 lines changed or deleted		190 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/