draft-ietf-cdi-known-request-routing-02.txt		draft-ietf-cdi-known-request-routing-03.txt
	Network Working Group B. Cain		Network Working Group A. Barbir
	Internet-Draft Storigen Systems		Internet-Draft Nortel Networks
	Expires: May 2, 2003 A. Barbir		Expires: October 2, 2003 B. Cain
	Nortel Networks		Storigen Systems
	R. Nair		R. Nair
	Cisco		Cisco
	O. Spatscheck		O. Spatscheck
	AT&T		AT&T
	November 2002		April 3, 2003
	Known CN Request-Routing Mechanisms		Known CN Request-Routing Mechanisms
	draft-ietf-cdi-known-request-routing-02.txt		draft-ietf-cdi-known-request-routing-03.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	Drafts.
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 May 2, 2003.		This Internet-Draft will expire on October 2, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	The work presents a summary of Request-Routing techniques that are		The work presents a summary of Request-Routing techniques that are
	used to direct client requests to surrogates based on various		used to direct client requests to surrogates based on various
	policies and a possible set of metrics. In this memo the term		policies and a possible set of metrics. The document covers
	Request-Routing represents techniques that are commonly called		techniques that were commonly used in the industry on or before
	content routing or content redirection. In principle, Request-		December 2000. In this memo the term Request-Routing represents
	Routing techniques can be classified under: DNS Request-Routing,		techniques that is commonly called content routing or content
	Transport-layer Request-Routing, and Application-layer Request-		redirection. In principle, Request-Routing techniques can be
	Routing.		classified under: DNS Request-Routing, Transport-layer
			Request-Routing, and Application-layer Request-Routing.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 4		2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 4
	2.1 Single Reply . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1 Single Reply . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2 Multiple Replies . . . . . . . . . . . . . . . . . . . . . . 4		2.2 Multiple Replies . . . . . . . . . . . . . . . . . . . . . . 4
	2.3 Multi-Level Resolution . . . . . . . . . . . . . . . . . . . 4		2.3 Multi-Level Resolution . . . . . . . . . . . . . . . . . . . 4
	2.3.1 NS Redirection . . . . . . . . . . . . . . . . . . . . . . . 4		2.3.1 NS Redirection . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3.2 CNAME Redirection . . . . . . . . . . . . . . . . . . . . . 5		2.3.2 CNAME Redirection . . . . . . . . . . . . . . . . . . . . . 5
	2.4 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.4 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.5 Object Encoding . . . . . . . . . . . . . . . . . . . . . . 6		2.5 Object Encoding . . . . . . . . . . . . . . . . . . . . . . 6
	2.6 DNS Request-Routing Limitations . . . . . . . . . . . . . . 6		2.6 DNS Request-Routing Limitations . . . . . . . . . . . . . . 7
	3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 8		3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 9
	4. Application-Layer Request-Routing . . . . . . . . . . . . . 9		4. Application-Layer Request-Routing . . . . . . . . . . . . . 10
	4.1 Header Inspection . . . . . . . . . . . . . . . . . . . . . 9		4.1 Header Inspection . . . . . . . . . . . . . . . . . . . . . 10
	4.1.1 URL-Based Request-Routing . . . . . . . . . . . . . . . . . 9		4.1.1 URL-Based Request-Routing . . . . . . . . . . . . . . . . . 10
	4.1.2 Header-Based Request-Routing . . . . . . . . . . . . . . . . 10		4.1.2 Header-Based Request-Routing . . . . . . . . . . . . . . . . 11
	4.1.3 Site-Specific Identifiers . . . . . . . . . . . . . . . . . 10		4.1.3 Site-Specific Identifiers . . . . . . . . . . . . . . . . . 11
	4.2 Content Modification . . . . . . . . . . . . . . . . . . . . 11		4.2 Content Modification . . . . . . . . . . . . . . . . . . . . 12
	4.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . . 11		4.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . . 12
	4.2.2 On-Demand URL Rewriting . . . . . . . . . . . . . . . . . . 12		4.2.2 On-Demand URL Rewriting . . . . . . . . . . . . . . . . . . 13
	4.2.3 Content Modification Limitations . . . . . . . . . . . . . . 12		4.2.3 Content Modification Limitations . . . . . . . . . . . . . . 13
	5. Combination of Multiple Mechanisms . . . . . . . . . . . . . 13		5. Combination of Multiple Mechanisms . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . 15
	7. Additional Authors and Acknowledgements . . . . . . . . . . 15		7. Additional Authors and Acknowledgements . . . . . . . . . . 16
	Normative References . . . . . . . . . . . . . . . . . . . . 16		Normative References . . . . . . . . . . . . . . . . . . . . 17
	Informative References . . . . . . . . . . . . . . . . . . . 17		Informative References . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
	A. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 18		A. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 21
	A.1 Proximity Measurements . . . . . . . . . . . . . . . . . . . 18		A.1 Proximity Measurements . . . . . . . . . . . . . . . . . . . 21
	A.1.1 Active Probing . . . . . . . . . . . . . . . . . . . . . . . 18		A.1.1 Active Probing . . . . . . . . . . . . . . . . . . . . . . . 21
	A.1.2 Passive Measurement . . . . . . . . . . . . . . . . . . . . 19		A.1.2 Metric Types . . . . . . . . . . . . . . . . . . . . . . . . 22
	A.1.3 Metric Types . . . . . . . . . . . . . . . . . . . . . . . . 19		A.1.3 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . . 22
	A.1.4 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . . 20		Intellectual Property and Copyright Statements . . . . . . . 23
	Full Copyright Statement . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	The document provides a summary of current known techniques that		The document provides a summary of known request routing techniques
	could be used to direct client requests to surrogates based on		that are used by the industry before December 2000. Request routing
	various policies and a possible set of metrics. The task of		techniques are generally used to direct client requests to surrogates
	directing clients' requests to surrogates is also called Request-		based on various policies and a possible set of metrics. The task of
	Routing, Content Routing or Content Redirection.		directing clients' requests to surrogates is also called
			Request-Routing, Content Routing or Content Redirection.
	Request-Routing techniques are commonly used in Content Networks		Request-Routing techniques are commonly used in Content Networks
	(also known as Content Delivery Networks) [8]. Content Networks		(also known as Content Delivery Networks) [8]. Content Networks
	include network infrastructure that exists in layers 4 through 7.		include network infrastructure that exists in layers 4 through 7.
	Content Networks deal with the routing and forwarding of requests and		Content Networks deal with the routing and forwarding of requests and
	responses for content. Content Networks rely on layer 7 protocols		responses for content. Content Networks rely on layer 7 protocols
	such as HTTP [4] for transport.		such as HTTP [4] for transport.
	Request-Routing techniques are generally used to direct client		Request-Routing techniques are generally used to direct client
	requests for objects to a surrogate or a set of surrogates that could		requests for objects to a surrogate or a set of surrogates that could
	skipping to change at page 3, line 44		skipping to change at page 3, line 45
	example, the choice of the surrogate could be based on network		example, the choice of the surrogate could be based on network
	proximity, bandwidth availability, surrogate load and availability of		proximity, bandwidth availability, surrogate load and availability of
	content. Appendix A provides a summary of metrics and measurement		content. Appendix A provides a summary of metrics and measurement
	techniques that could be used in the selection of the best surrogate.		techniques that could be used in the selection of the best surrogate.
	The memo is organized as follows: Section 2 provides a summary of		The memo is organized as follows: Section 2 provides a summary of
	known DNS based Request-Routing techniques. Section 3 discusses		known DNS based Request-Routing techniques. Section 3 discusses
	transport-layer Request-Routing methods. In section 4 application		transport-layer Request-Routing methods. In section 4 application
	layer Request-Routing mechanisms are explored. Section 5 provides		layer Request-Routing mechanisms are explored. Section 5 provides
	insight on combining the various methods that were discussed in the		insight on combining the various methods that were discussed in the
	earlier sections in order to optimize the performance of the Request-		earlier sections in order to optimize the performance of the
	Routing System. Appendix A provides a summary of possible metrics		Request-Routing System. Appendix A provides a summary of possible
	and measurements techniques that could be used by the Request-		metrics and measurements techniques that could be used by the
	Routing system to choose a given surrogate.		Request-Routing system to choose a given surrogate.
	2. DNS based Request-Routing Mechanisms		2. DNS based Request-Routing Mechanisms
	DNS based Request-Routing techniques are common due to the ubiquity		DNS based Request-Routing techniques are common due to the ubiquity
	of DNS as a directory service. In DNS based Request-Routing		of the DNS system [10][12][13]. In DNS based Request-Routing
	techniques, a specialized DNS server is inserted in the DNS		techniques, a specialized DNS server is inserted in the DNS
	resolution process. The server is capable of returning a different		resolution process. The server is capable of returning a different
	set of A, NS or CNAME records based on user defined policies,		set of A, NS or CNAME records based on user defined policies,
	metrics, or a combination of both.		metrics, or a combination of both. In [11] RFC 2782 (DNS SRV)
			provides guidance on the use of DNS for load balancing. The RFC
			describes some of the limitations and suggests appropriate usesage of
			DNS based techniques. The next sections provides a summary of some of
			the used techniques.
	2.1 Single Reply		2.1 Single Reply
	In this approach, the DNS server is authoritative for the entire DNS		In this approach, the DNS server is authoritative for the entire DNS
	domain or a sub domain. The DNS server returns the IP address of the		domain or a sub domain. The DNS server returns the IP address of the
	best surrogate in an A record to the requesting DNS server. The IP		best surrogate in an A record to the requesting DNS server. The IP
	address of the surrogate could also be a virtual IP(VIP) address of		address of the surrogate could also be a virtual IP(VIP) address of
	the best set of surrogates for requesting DNS server.		the best set of surrogates for requesting DNS server.
	2.2 Multiple Replies		2.2 Multiple Replies
	skipping to change at page 4, line 52		skipping to change at page 5, line 7
	server within that territory to provide a more accurate resolution.		server within that territory to provide a more accurate resolution.
	2.3.1 NS Redirection		2.3.1 NS Redirection
	A DNS server can use NS records to redirect the authority of the next		A DNS server can use NS records to redirect the authority of the next
	level domain to another Request-Routing DNS server. The, technique		level domain to another Request-Routing DNS server. The, technique
	allows multiple DNS server to be involved in the name resolution		allows multiple DNS server to be involved in the name resolution
	process. For example, a client site DNS server resolving		process. For example, a client site DNS server resolving
	a.b.example.com [10] would eventually request a resolution of		a.b.example.com [10] would eventually request a resolution of
	a.b.example.com from the name server authoritative for example.com.		a.b.example.com from the name server authoritative for example.com.
	The name server authoritative for this domain might be a Request-		The name server authoritative for this domain might be a
	Routing NS server. In this case the Request-Routing DNS server can		Request-Routing NS server. In this case the Request-Routing DNS
	either return a set of A records or can redirect the resolution of		server can either return a set of A records or can redirect the
	the request a.b.example.com to the DNS server that is authoritative		resolution of the request a.b.example.com to the DNS server that is
	for example.com using NS records.		authoritative for example.com using NS records.
	One drawback of using NS records is that the number of Request-		One drawback of using NS records is that the number of
	Routing DNS servers are limited by the number of parts in the DNS		Request-Routing DNS servers are limited by the number of parts in
	name. This problem results from DNS policy that causes a client site		the DNS name. This problem results from DNS policy that causes a
	DNS server to abandon a request if no additional parts of the DNS		client site DNS server to abandon a request if no additional parts of
	name are resolved in an exchange with an authoritative DNS server.		the DNS name are resolved in an exchange with an authoritative DNS
			server.
	A second drawback is that the last DNS server can determine the TTL		A second drawback is that the last DNS server can determine the TTL
	of the entire resolution process. Basically, the last DNS server can		of the entire resolution process. Basically, the last DNS server can
	return in the authoritative section of its response its own NS		return in the authoritative section of its response its own NS
	record. The client will use this cached NS record for further		record. The client will use this cached NS record for further request
	request resolutions until it expires.		resolutions until it expires.
	Another drawback is that some implementations of bind voluntarily		Another drawback is that some implementations of bind voluntarily
	cause timeouts to simplify their implementation in cases in which a		cause timeouts to simplify their implementation in cases in which a
	NS level redirect points to a name server for which no valid A record		NS level redirect points to a name server for which no valid A record
	is returned or cached. This is especially a problem if the domain of		is returned or cached. This is especially a problem if the domain of
	the name server does not match the domain currently resolved, since		the name server does not match the domain currently resolved, since
	in this case the A records, which might be passed in the DNS		in this case the A records, which might be passed in the DNS
	response, are discarded for security reasons. Another drawback is		response, are discarded for security reasons. Another drawback is the
	the added delay in resolving the request due to the use of multiple		added delay in resolving the request due to the use of multiple DNS
	DNS servers.		servers.
	2.3.2 CNAME Redirection		2.3.2 CNAME Redirection
	In this scenario, the Request-Routing DNS server returns a CNAME		In this scenario, the Request-Routing DNS server returns a CNAME
	record to direct resolution to an entirely new domain. In principle,		record to direct resolution to an entirely new domain. In principle,
	the new domain might employ a new set of Request-Routing DNS servers.		the new domain might employ a new set of Request-Routing DNS servers.
	One disadvantage of this approach is the additional overhead of		One disadvantage of this approach is the additional overhead of
	resolving the new domain name. The main advantage of this approach		resolving the new domain name. The main advantage of this approach is
	is that the number of Request-Routing DNS servers is independent of		that the number of Request-Routing DNS servers is independent of the
	the format of the domain name.		format of the domain name.
	2.4 Anycast		2.4 Anycast
	Anycast [5] is an inter-network service that is applicable to		Anycast [5] is an inter-network service that is applicable to
	networking situations where a host, application, or user wishes to		networking situations where a host, application, or user wishes to
	locate a host which supports a particular service but, if several		locate a host which supports a particular service but, if several
	servers support the service, does not particularly care which server		servers support the service, does not particularly care which server
	is used. In an anycast service, a host transmits a datagram to an		is used. In an anycast service, a host transmits a datagram to an
	anycast address and the inter-network is responsible for providing		anycast address and the inter-network is responsible for providing
	best effort delivery of the datagram to at least one, and preferably		best effort delivery of the datagram to at least one, and preferably
	only one, of the servers that accept datagrams for the anycast		only one, of the servers that accept datagrams for the anycast
	address.		address.
	The motivation for anycast is that it considerably simplifies the		The motivation for anycast is that it considerably simplifies the
	task of finding an appropriate server. For example, users, instead		task of finding an appropriate server. For example, users, instead of
	of consulting a list of servers and choosing the closest one, could		consulting a list of servers and choosing the closest one, could
	simply type the name of the server and be connected to the nearest		simply type the name of the server and be connected to the nearest
	one. By using anycast, DNS resolvers would no longer have to be		one. By using anycast, DNS resolvers would no longer have to be
	configured with the IP addresses of their servers, but rather could		configured with the IP addresses of their servers, but rather could
	send a query to a well-known DNS anycast address.		send a query to a well-known DNS anycast address.
	Furthermore, to combine measurement and redirection, the Request-		Furthermore, to combine measurement and redirection, the
	Routing DNS server can advertise an anycast address as its IP		Request-Routing DNS server can advertise an anycast address as its IP
	address. The same address is used by multiple physical DNS servers.		address. The same address is used by multiple physical DNS servers.
	In this scenario, the Request-Routing DNS server that is the closest		In this scenario, the Request-Routing DNS server that is the closest
	to the client site DNS server in terms of OSPF and BGP routing will		to the client site DNS server in terms of OSPF and BGP routing will
	receive the packet containing the DNS resolution request. The server		receive the packet containing the DNS resolution request. The server
	can use this information to make a Request- Routing decision.		can use this information to make a Request- Routing decision.
	Drawbacks of this approach are listed below:		Drawbacks of this approach are listed below:
	o The DNS server may not be the closest server in terms of routing		o The DNS server may not be the closest server in terms of routing
	to the client.		to the client.
	skipping to change at page 6, line 40		skipping to change at page 6, line 45
	process.		process.
	2.5 Object Encoding		2.5 Object Encoding
	Since only DNS names are visible during the DNS Request-Routing, some		Since only DNS names are visible during the DNS Request-Routing, some
	solutions encode the object type, object hash, or similar information		solutions encode the object type, object hash, or similar information
	into the DNS name. This might vary from a simple division of objects		into the DNS name. This might vary from a simple division of objects
	based on object type (such as images.a.b.example.com and		based on object type (such as images.a.b.example.com and
	streaming.a.b.example.com) to a sophisticated schema in which the		streaming.a.b.example.com) to a sophisticated schema in which the
	domain name contains a unique identifier (such as a hash) of the		domain name contains a unique identifier (such as a hash) of the
	object. The obvious advantage is that object information is		object. The obvious advantage is that object information is available
	available at resolution time. The disadvantage is that the client		at resolution time. The disadvantage is that the client site DNS
	site DNS server has to perform multiple resolutions to retrieve a		server has to perform multiple resolutions to retrieve a single Web
	single Web page, which might increase rather than decrease the		page, which might increase rather than decrease the overall latency.
	overall latency.
	2.6 DNS Request-Routing Limitations		2.6 DNS Request-Routing Limitations
	Some limitations of DNS based Request-Routing techniques are		This section lists some of the limitations of DNS based
	described below:		Request-Routing techniques.
	o DNS only allows resolution at the domain level. However, an ideal		o DNS only allows resolution at the domain level. However, an ideal
	request resolution system should service requests per object		request resolution system should service requests per object
	level.		level.
	o In DNS based Request-Routing systems servers may be required to		o In DNS based Request-Routing systems servers may be required to
	return DNS entries with a short time-to-live (TTL) values. This		return DNS entries with a short time-to-live (TTL) values. This
	may be needed in order to be able to react quickly in the face of		may be needed in order to be able to react quickly in the face of
	outages. This in return may increase the volume of requests to		outages. This in return may increase the volume of requests to DNS
	DNS servers.		servers.
	o Some DNS implementations do not always adhere to DNS standards.		o Some DNS implementations do not always adhere to DNS standards.
	For example, many DNS implementations do not honor the DNS TTL		For example, many DNS implementations do not honor the DNS TTL
	field.		field.
	o DNS Request-Routing is based only on knowledge of the client DNS		o DNS Request-Routing is based only on knowledge of the client DNS
	server, as client addresses are not relayed within DNS requests.		server, as client addresses are not relayed within DNS requests.
	This limits the ability of the Request-Routing system to determine		This limits the ability of the Request-Routing system to determine
	a client's proximity to the surrogate.		a client's proximity to the surrogate.
	o DNS servers can request and allow recursive resolution of DNS		o DNS servers can request and allow recursive resolution of DNS
	names. For recursive resolution of requests, the Request-Routing		names. For recursive resolution of requests, the Request-Routing
	DNS server will not be exposed to the IP address of the client's		DNS server will not be exposed to the IP address of the client's
	site DNS server. In this case, the Request-Routing DNS server		site DNS server. In this case, the Request-Routing DNS server will
	will be exposed to the address of the DNS server that is		be exposed to the address of the DNS server that is recursively
	recursively requesting the information on behalf of the client's		requesting the information on behalf of the client's site DNS
	site DNS server. For example, imgs.example.com might be resolved		server. For example, imgs.example.com might be resolved by a CN,
	by a CN, but the request for the resolution might come from		but the request for the resolution might come from
	dns1.example.com as a result of the recursion.		dns1.example.com as a result of the recursion.
	o Users that share a single client site DNS server will be		o Users that share a single client site DNS server will be
	redirected to the same set of IP addresses during the TTL		redirected to the same set of IP addresses during the TTL
	interval. This might lead to overloading of the surrogate during		interval. This might lead to overloading of the surrogate during a
	a flash crowd.		flash crowd.
	o Some implementations of bind can cause DNS timeouts to occur while		o Some implementations of bind can cause DNS timeouts to occur while
	handling exceptional situations. For example, timeouts can occur		handling exceptional situations. For example, timeouts can occur
	for NS redirections to unknown domains.		for NS redirections to unknown domains.
			DNS based request routing techniques can suffer from serious
			limitations. For example, the use of such techniques can overburden
			third party DNS servers, which should not be allowed [19]. In [11]
			RFC 2782 provides warnings on the use of DNS for load balancing.
			Readers are encouraged to read the RFC for better understanding of
			the limitations.
	3. Transport-Layer Request-Routing		3. Transport-Layer Request-Routing
	At the transport-layer finer levels of granularity can be achieved by		At the transport-layer finer levels of granularity can be achieved by
	the close inspection of client's requests. In this approach, the		the close inspection of client's requests. In this approach, the
	Request-Routing system inspects the information available in the		Request-Routing system inspects the information available in the
	first packet of the client's request to make surrogate selection		first packet of the client's request to make surrogate selection
	decisions. The inspection of the client's requests provides data		decisions. The inspection of the client's requests provides data
	about the client's IP address, port information, and layer 4		about the client's IP address, port information, and layer 4
	protocol. The acquired data could be used in combination with user-		protocol. The acquired data could be used in combination with
	defined policies and other metrics to determine the selection of a		user-defined policies and other metrics to determine the selection of
	surrogate that is better suited to serve the request. The techniques		a surrogate that is better suited to serve the request. The
	that are used to hand off the session to a more appropriate surrogate		techniques [20][18][15] are used to hand off the session to a more
	are beyond the scope of this document.		appropriate surrogate are beyond the scope of this document.
	In general, the forward-flow traffic (client to newly selected		In general, the forward-flow traffic (client to newly selected
	surrogate) will flow through the surrogate originally chosen by DNS.		surrogate) will flow through the surrogate originally chosen by DNS.
	The reverse-flow (surrogate to client) traffic, which normally		The reverse-flow (surrogate to client) traffic, which normally
	transfers much more data than the forward flow, would typically take		transfers much more data than the forward flow, would typically take
	the direct path.		the direct path.
	The overhead associated with transport-layer Request-Routing makes it		The overhead associated with transport-layer Request-Routing [21][19]
	better suited for long-lived sessions such as FTP [1]and RTSP [3].		it better suited for long-lived sessions such as FTP [1]and RTSP
	However, it also could be used to direct clients away from overloaded		[3]. However, it also could be used to direct clients away from
	surrogates.		overloaded surrogates.
	In general, transport-layer Request-Routing can be combined with DNS		In general, transport-layer Request-Routing can be combined with DNS
	based techniques. As stated earlier, DNS based methods resolve		based techniques. As stated earlier, DNS based methods resolve
	clients requests based on domains or sub domains with exposure to the		clients requests based on domains or sub domains with exposure to the
	client's DNS server IP address. Hence, the DNS based methods could		client's DNS server IP address. Hence, the DNS based methods could be
	be used as a first step in deciding on an appropriate surrogate with		used as a first step in deciding on an appropriate surrogate with
	more accurate refinement made by the transport-layer Request-Routing		more accurate refinement made by the transport-layer Request-Routing
	system.		system.
	4. Application-Layer Request-Routing		4. Application-Layer Request-Routing
	Application-layer Request-Routing systems perform deeper examination		Application-layer Request-Routing systems perform deeper examination
	of client's packets beyond the transport layer header. Deeper		of client's packets beyond the transport layer header. Deeper
	examination of client's packets provides fine-grained Request-Routing		examination of client's packets provides fine-grained Request-Routing
	control down to the level of individual objects. The process could		control down to the level of individual objects. The process could be
	be performed in real time at the time of the object request. The		performed in real time at the time of the object request. The
	exposure to the client's IP address combined with the fine-grained		exposure to the client's IP address combined with the fine-grained
	knowledge of the requested objects enable application-layer Request-		knowledge of the requested objects enable application-layer Request-
	Routing systems to provide better control over the selection of the		Routing systems to provide better control over the selection of the
	best surrogate.		best surrogate.
	4.1 Header Inspection		4.1 Header Inspection
	Some application level protocols such as HTTP [4], RTSP [3], and SSL		Some application level protocols such as HTTP [4], RTSP [3], and SSL
	[2] provide hints in the initial portion of the session about how the		[2] provide hints in the initial portion of the session about how the
	client request must be directed. These hints may come from the URL		client request must be directed. These hints may come from the URL of
	of the content or other parts of the MIME request header such as		the content or other parts of the MIME request header such as
	Cookies.		Cookies.
	4.1.1 URL-Based Request-Routing		4.1.1 URL-Based Request-Routing
	Application level protocols such as HTTP and RTSP describe the		Application level protocols such as HTTP and RTSP describe the
	requested content by its URL [6]. In many cases, this information		requested content by its URL [6]. In many cases, this information is
	is sufficient to disambiguate the content and suitably direct the		sufficient to disambiguate the content and suitably direct the
	request. In most cases, it may be sufficient to make Request-		request. In most cases, it may be sufficient to make Request- Routing
	Routing decision just by examining the prefix or suffix of the URL.		decision just by examining the prefix or suffix of the URL.
	4.1.1.1 302 Redirection		4.1.1.1 302 Redirection
	In this approach, the client's request is first resolved to a virtual		In this approach, the client's request is first resolved to a virtual
	surrogate. Consequently, the surrogate returns an application-		surrogate. Consequently, the surrogate returns an
	specific code such as the 302 (in the case of HTTP [4] or RTSP [3])		application-specific code such as the 302 (in the case of HTTP [4] or
	to redirect the client to the actual delivery node.		RTSP [3]) to redirect the client to the actual delivery node.
	This technique is relatively simple to implement. However, the main		This technique is relatively simple to implement. However, the main
	drawback of this method is the additional latency involved in sending		drawback of this method is the additional latency involved in sending
	the redirect message back to the client.		the redirect message back to the client.
	4.1.1.2 In-Path Element		4.1.1.2 In-Path Element
	In this technique, an In-Path element is present in the network in		In this technique, an In-Path element is present in the network in
	the forwarding path of the client's request. The In-Path element		the forwarding path of the client's request. The In-Path element
	provides transparent interception of the transport connection. The		provides transparent interception of the transport connection. The
	skipping to change at page 10, line 24		skipping to change at page 11, line 24
	The technique allows for the possibility of partitioning the traffic		The technique allows for the possibility of partitioning the traffic
	among a set of delivery nodes by content objects identified by URLs.		among a set of delivery nodes by content objects identified by URLs.
	This allows object-specific control of server loading. For example,		This allows object-specific control of server loading. For example,
	requests for non-cacheable object types may be directed away from a		requests for non-cacheable object types may be directed away from a
	cache.		cache.
	4.1.2 Header-Based Request-Routing		4.1.2 Header-Based Request-Routing
	This technique involves the task of using HTTP [4] such as Cookie,		This technique involves the task of using HTTP [4] such as Cookie,
	Language, and User-Agent, in order to select a surrogate.		Language, and User-Agent, in order to select a surrogate. In [20]
			some examples of using this technique are provided.
	Cookies can be used to identify a customer or session by a web site.		Cookies can be used to identify a customer or session by a web site.
	Cookie based Request-Routing provides content service differentiation		Cookie based Request-Routing provides content service differentiation
	based on the client. This approach works provided that the cookies		based on the client. This approach works provided that the cookies
	belong to the client. In addition, it is possible to direct a		belong to the client. In addition, it is possible to direct a
	connection from a multi-session transaction to be directed to the		connection from a multi-session transaction to be directed to the
	same server to achieve session-level persistence.		same server to achieve session-level persistence.
	The language header can be used to direct traffic to a language-		The language header can be used to direct traffic to a
	specific delivery node. The user-agent header helps identify the		language-specific delivery node. The user-agent header helps identify
	type of client device. For example, a voice-browser, PDA, or cell		the type of client device. For example, a voice-browser, PDA, or cell
	phone can indicate the type of delivery node that has content		phone can indicate the type of delivery node that has content
	specialized to handle the content request.		specialized to handle the content request.
	4.1.3 Site-Specific Identifiers		4.1.3 Site-Specific Identifiers
	Site-specific identifiers help authenticate and identify a session		Site-specific identifiers help authenticate and identify a session
	from a specific user. This information may be used to direct a		from a specific user. This information may be used to direct a
	content request.		content request.
	An example of a site-specific identifier is the SSL Session		An example of a site-specific identifier is the SSL Session
	skipping to change at page 11, line 11		skipping to change at page 12, line 13
	session identifier, an In-Path element would observe the responses of		session identifier, an In-Path element would observe the responses of
	the web server and determine the session identifier which is then		the web server and determine the session identifier which is then
	used to associate the session to a specific server. The remaining		used to associate the session to a specific server. The remaining
	sessions are directed based on the stored session identifier.		sessions are directed based on the stored session identifier.
	4.2 Content Modification		4.2 Content Modification
	This technique enables a content provider to take direct control over		This technique enables a content provider to take direct control over
	Request-Routing decisions without the need for specific witching		Request-Routing decisions without the need for specific witching
	devices or directory services in the path between the client and the		devices or directory services in the path between the client and the
	origin server. Basically, a content provider can directly		origin server. Basically, a content provider can directly communicate
	communicate to the client the best surrogate that can serve the		to the client the best surrogate that can serve the request.
	request. Decisions about the best surrogate can be made on a per-		Decisions about the best surrogate can be made on a per-object basis
	object basis or it can depend on a set of metrics. The overall goal		or it can depend on a set of metrics. The overall goal is to improve
	is to improve scalability and the performance for delivering the		scalability and the performance for delivering the modified content,
	modified content, including all embedded objects.		including all embedded objects.
	In general, the method takes advantage of content objects that		In general, the method takes advantage of content objects that
	consist of basic structure that includes references to additional,		consist of basic structure that includes references to additional,
	embedded objects. For example, most web pages, consist of an HTML		embedded objects. For example, most web pages, consist of an HTML
	document that contains plain text together with some embedded		document that contains plain text together with some embedded
	objects, such as GIF or JPEG images. The embedded objects are		objects, such as GIF or JPEG images. The embedded objects are
	referenced using embedded HTML directives. In general, embedded HTML		referenced using embedded HTML directives. In general, embedded HTML
	directives direct the client to retrieve the embedded objects from		directives direct the client to retrieve the embedded objects from
	the origin server. A content provider can now modify references to		the origin server. A content provider can now modify references to
	embedded objects such that they could be fetched from the best		embedded objects such that they could be fetched from the best
	skipping to change at page 11, line 47		skipping to change at page 12, line 49
	subsections.		subsections.
	4.2.1 A-priori URL Rewriting		4.2.1 A-priori URL Rewriting
	In this scheme, a content provider rewrites the embedded URLs before		In this scheme, a content provider rewrites the embedded URLs before
	the content is positioned on the origin server. In this case, URL		the content is positioned on the origin server. In this case, URL
	rewriting can be done either manually or by using a software tools		rewriting can be done either manually or by using a software tools
	that parse the content and replace embedded URLs.		that parse the content and replace embedded URLs.
	A-priori URL rewriting alone does not allow consideration of client		A-priori URL rewriting alone does not allow consideration of client
	specifics for Request-Routing. However, it can be used in		specifics for Request-Routing. However, it can be used in combination
	combination with DNS Request-Routing to direct related DNS queries		with DNS Request-Routing to direct related DNS queries into the
	into the domain name space of the service provider. Dynamic Request-		domain name space of the service provider. Dynamic Request-Routing
	Routing based on client specifics are then done using the DNS		based on client specifics are then done using the DNS approach.
	approach.
	4.2.2 On-Demand URL Rewriting		4.2.2 On-Demand URL Rewriting
	On-Demand or dynamic URL rewriting, modifies the content when the		On-Demand or dynamic URL rewriting, modifies the content when the
	client request reaches the origin server. At this time, the		client request reaches the origin server. At this time, the
	identity of the client is known and can be considered when rewriting		identity of the client is known and can be considered when rewriting
	the embedded URLs. In particular, an automated process can		the embedded URLs. In particular, an automated process can determine,
	determine, on-demand, which surrogate would serve the requesting		on-demand, which surrogate would serve the requesting client best.
	client best. The embedded URLs can then be rewritten to direct		The embedded URLs can then be rewritten to direct the client to
	the client to retrieve the objects from the best surrogate rather		retrieve the objects from the best surrogate rather than from the
	than from the origin server.		origin server.
	4.2.3 Content Modification Limitations		4.2.3 Content Modification Limitations
	Content modification as a Request-Routing mechanism suffers from the		Content modification as a Request-Routing mechanism suffers from many
	following limitations:		limitation [23]. For example:
	o The first request from a client to a specific site must be served		o The first request from a client to a specific site must be served
	from the origin server.		from the origin server.
	o Content that has been modified to include references to nearby		o Content that has been modified to include references to nearby
	surrogates rather than to the origin server should be marked as		surrogates rather than to the origin server should be marked as
	non-cacheable. Alternatively, such pages can be marked to be		non-cacheable. Alternatively, such pages can be marked to be
	cacheable only for a relatively short period of time. Rewritten		cacheable only for a relatively short period of time. Rewritten
	URLs on cached pages can cause problems, because they can get		URLs on cached pages can cause problems, because they can get
	outdated and point to surrogates that are no longer available or		outdated and point to surrogates that are no longer available or
	skipping to change at page 14, line 9		skipping to change at page 15, line 9
	can be used together with DNS Request-Routing to overcome this		can be used together with DNS Request-Routing to overcome this
	problem. With content modification, references to different objects		problem. With content modification, references to different objects
	on the same origin server can be rewritten to point into different		on the same origin server can be rewritten to point into different
	domain name spaces. Using DNS Request-Routing, requests for those		domain name spaces. Using DNS Request-Routing, requests for those
	objects can now dynamically be directed to different surrogates.		objects can now dynamically be directed to different surrogates.
	6. Security Considerations		6. Security Considerations
	The main objective of this document is to provide a summary of		The main objective of this document is to provide a summary of
	current Request-Routing techniques. Such techniques are currently		current Request-Routing techniques. Such techniques are currently
	implemented in the Internet. The document acknowledges that security		implemented in the Internet. However, security must be addressed by
	must be addressed by any entity that implements any technique that		any entity that implements any technique that redirects client's
	redirects client's requests. In [9] RFC 3238 addresses the main		requests. In [9] RFC 3238 addresses the main requirements for
	requirements for entities that intent to modify requests for content		entities that intent to modify requests for content in the Internet.
	in the Internet.
	The details of security techniques are beyond the scope of this		Some active probing techniques will set off intrusion detection
	document.		systems and firewalls. Therefore, it is recommended that implementers
			be aware of routing protocol security [25].
			It is important to note the impact of TLS [2] on request routing in
			CNs. Specifically, when TLS is used the full URL is not visible to
			the content network unless it terminates the TLS session. The current
			document focuses on HTTP techniques. TLS based techniques that
			require the termination of TLS sessions on Content Peering Gateways
			[8] are out of scope.
			Furthermore, the details of security techniques are beyond the scope
			of this document.
	7. Additional Authors and Acknowledgements		7. Additional Authors and Acknowledgements
	The following people have contributed to the task of authoring this		The following people have contributed to the task of authoring this
	document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann		document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann
	(Lucent), Doug Potter.		(Lucent), Doug Potter.
	The authors acknowledge the contributions and comments of Ian Cooper,		The authors acknowledge the contributions and comments of Ian Cooper,
	Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean		Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean
	(CrystalBall).		(CrystalBall).
	skipping to change at page 16, line 27		skipping to change at page 17, line 27
	[5] C. Partridge et al., "Host Anycasting Service", RFC 1546,		[5] C. Partridge et al., "Host Anycasting Service", RFC 1546,
	November 1993.		November 1993.
	[6] T. Berners-Lee et al, "Uniform Resource Locators (URL)", RFC		[6] T. Berners-Lee et al, "Uniform Resource Locators (URL)", RFC
	1738, May 1994.		1738, May 1994.
	[7] H. Schulzrinneet al, "RTP: A Transport Protocol for Real-Time		[7] H. Schulzrinneet al, "RTP: A Transport Protocol for Real-Time
	Applications", RFC 1889, January 1996.		Applications", RFC 1889, January 1996.
	[8] M. Day et al, "A Model for Content Internetworking (CDI)",		[8] M. Day et al, "A Model for Content Internetworking (CDI)", RFC
	Internet-Draft: http://www.ietf.org/internet-drafts/ draft-ietf-		3466 , February 2003.
	cdi-model-02.txt (groups Last Call), May 2002.
	[9] S. Floyd et al, "IAB Architectural and Policy Considerations for		[9] S. Floyd et al, "IAB Architectural and Policy Considerations for
	Open Pluggable Edge Services", RFC 3238, January 2002.		Open Pluggable Edge Services", RFC 3238, January 2002.
	Informative References		Informative References
	[10] D. Eastlake et al, "Reserved Top Level DNS Names", RFC 2606,		[10] D. Eastlake et al, "Reserved Top Level DNS Names", RFC 2606,
	June 1999.		June 1999.
	Authors' Addresses		[11] A. Gulbrandsen et al, "A DNS RR for specifying the location of
			services (DNS SRV)", RFC 2782, February 2002.
	Brad Cain		[12] P. Mockapetris, "Domain names - concepts and facilities", RFC
	Storigen Systems		1034, November 1987.
	650 Suffolk Street
	Lowell, MA 01854
	USA
	Phone: +1 978-323-4454		[13] P. Mockapetris, "Domain names - concepts and facilities", RFC
	EMail: bcain@storigen.com		1035, November 1987.
			[14] R. Elz et al, "Clarifications to the DNS Specification", RFC
			2181, July 1997.
			[15] D. Awduche et al, "Overview and Principles of Internet Traffic
			Engineering", RFC 3272, May 2002.
			[16] E. Crawley et al, "A Framework for QoS-based Routing in the
			Internet", RFC 2386, August 1998.
			[17] G. Huston, "Commentary on Inter-Domain Routing in the
			Internet", RFC 3221, December 2001.
			[18] M. Welsh et al., "SEDA: An Architecture for Well-Conditioned,
			Scalable Internet Services", Proceedings of the Eighteenth
			Symposium on Operating Systems Principles (SOSP-18) 2001,
			October 2001.
			[19] A. Shaikh, "On the effectiveness of DNS-based Server
			Selection", INFOCOM 2001, August 2001.
			[20] C. Yang et al., "An effective mechanism for supporting
			content-based routing in scalable Web server clusters", Proc.
			International Workshops on Parallel Processing 1999, September
			1999.
			[21] R. Liston et al., "Using a Proxy to Measure Client-Side Web
			Performance", Proceedings of the Sixth International Web
			Content Caching and Distribution Workshop (WCW'01) 2001, August
			2001.
			[22] W. Jiang et al., "Modeling of packet loss and delay and their
			effect on real-time multimedia service quality", Proceedings of
			NOSSDAV 2000, June 2000.
			[23] K. Johnson et al., "The measured performance of content
			distribution networks", Proceedings of the Fifth International
			Web Caching Workshop and Content Delivery Workshop 2000, May
			2000.
			[24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM
			Transactions 1999, June 1999.
			[25] F. Wang et al., "Secure routing protocols: Theory and
			Practice", Technical report, North Carolina State University
			1997, May 1997.
			Authors' Addresses
	Abbie Barbir		Abbie Barbir
	Nortel Networks		Nortel Networks
	3500 Carling Avenue		3500 Carling Avenue
	Nepean, Ontario K2H 8E9		Nepean, Ontario K2H 8E9
	Canada		Canada
	Phone: +1 613 763 5229		Phone: +1 613 763 5229
	EMail: abbieb@nortelnetworks.com		EMail: abbieb@nortelnetworks.com
			Brad Cain
			Storigen Systems
			650 Suffolk Street
			Lowell, MA 01854
			USA
			Phone: +1 978-323-4454
			EMail: bcain@storigen.com
	Raj Nair		Raj Nair
	Cisco		Cisco
	50 Nagog Park		50 Nagog Park
	Acton, MA 01720		Acton, MA 01720
	USA		USA
	EMail: rnair@cisco.com		EMail: rnair@cisco.com
	Oliver Spatscheck		Oliver Spatscheck
	AT&T		AT&T
	180 Park Ave, Bldg 103		180 Park Ave, Bldg 103
	Florham Park, NJ 07932		Florham Park, NJ 07932
	USA		USA
	EMail: spatsch@research.att.com		EMail: spatsch@research.att.com
	Appendix A. Measurements		Appendix A. Measurements
	skipping to change at page 18, line 18		skipping to change at page 21, line 18
	determine the best surrogate that can serve a client's request. In		determine the best surrogate that can serve a client's request. In
	general, these metrics are based on network measurements and feedback		general, these metrics are based on network measurements and feedback
	from surrogates. It is possible to combine multiple metrics using		from surrogates. It is possible to combine multiple metrics using
	both proximity and surrogate feedback for best surrogate selection.		both proximity and surrogate feedback for best surrogate selection.
	The following sections describe several well known metrics as well as		The following sections describe several well known metrics as well as
	the major techniques for obtaining them.		the major techniques for obtaining them.
	A.1 Proximity Measurements		A.1 Proximity Measurements
	Proximity measurements can be used by the Request-Routing system to		Proximity measurements can be used by the Request-Routing system to
	direct users to the "closest" surrogate. In a DNS Request-Routing		direct users to the "closest" surrogate. In this document proximity
	system, the measurements are made to the client's local DNS server.		means round-trip time. In a DNS Request-Routing system, the
	However, when the IP address of the client is accessible more		measurements are made to the client's local DNS server. However, when
	accurate proximity measurements can be obtained.		the IP address of the client is accessible more accurate proximity
			measurements can be obtained [24].
	Furthermore, proximity measurements can be exchanged between		Proximity measurements can be exchanged between surrogates and the
	surrogates and the requesting entity. In many cases, proximity		requesting entity. In many cases, proximity measurements are
	measurements are "one-way" in that they measure either the forward or		"one-way" in that they measure either the forward or reverse path of
	reverse path of packets from the surrogate to the requesting entity.		packets from the surrogate to the requesting entity. This is
	This is important as many paths in the Internet are asymmetric.		important as many paths in the Internet are asymmetric [24].
	In order to obtain a set of proximity measurements, a network may		In order to obtain a set of proximity measurements, a network may
	employ active probing techniques and/or passive measurement		employ active probing techniques.
	techniques. The following sections describe these two techniques.
	A.1.1 Active Probing		A.1.1 Active Probing
	Active probing is when past or possible requesting entities are		Active probing is when past or possible requesting entities are
	probed using one or more techniques to determine one or more metrics		probed using one or more techniques to determine one or more metrics
	from each surrogate or set of surrogates. An example of a probing		from each surrogate or set of surrogates. An example of a probing
	technique is an ICMP ECHO Request that is periodically sent from each		technique is an ICMP ECHO Request that is periodically sent from each
	surrogate or set of surrogates to a potential requesting entity.		surrogate or set of surrogates to a potential requesting entity.
	In any active probing approach, a list of potential requesting		In any active probing approach, a list of potential requesting
	entities need to be obtained. This list can be generated		entities need to be obtained. This list can be generated
	dynamically. Here, as requests arrive, the requesting entity		dynamically. Here, as requests arrive, the requesting entity
	addresses can be cached for later probing. Another potential		addresses can be cached for later probing. Another potential solution
	solution is to use an algorithm to divide address space into blocks		is to use an algorithm to divide address space into blocks and to
	and to probe random addresses within those blocks. Limitations of		probe random addresses within those blocks. Limitations of active
	active probing techniques include:		probing techniques include:
	o Measurements can only be taken periodically.		o Measurements can only be taken periodically.
	o Firewalls and NATs disallow probes.		o Firewalls and NATs disallow probes.
	o Probes often cause security alarms to be triggered on intrusion		o Probes often cause security alarms to be triggered on intrusion
	detection systems.		detection systems.
	A.1.2 Passive Measurement		A.1.2 Metric Types
	Passive measurements could be obtained when a client performs data
	transfers to or from a surrogate. Here, a bootstrap mechanism is
	used to direct the client to a bootstrap surrogate. Once the client
	connects, the actual performance of the transfer is measured. This
	data is then fed back into the Request-Routing system.
	An example of passive measurement is to watch the packet loss from a
	client to a surrogate by observing TCP behavior. Latency
	measurements can also be learned by observing TCP behavior. The
	limitations of passive measurement approach are directly related to
	the bootstrapping mechanism. Basically, a good mechanism is needed
	to ensure that not every surrogate is tested per client in order to
	obtain the data.
	A.1.3 Metric Types
	The following sections list some of the metrics, which can be used		The following sections list some of the metrics, which can be used
	for proximity calculations.		for proximity calculations.
	o Latency: Network latency measurements metrics are used to		o Latency: Network latency measurements metrics are used to
	determine the surrogate (or set of surrogates) that has the least		determine the surrogate (or set of surrogates) that has the least
	delay to the requesting entity. These measurements can be		delay to the requesting entity. These measurements can be
	obtained using either an active probing approach or a		obtained using active probing techniques.
	passive network measurement system.
	o Packet Loss: Packet loss measurements can be used as a selection
	metric. A passive measurement approach can easily obtain packet
	loss information from TCP header information. Active probing can
	periodically measure packet loss from probes.
	o Hop Counts: Router hops from the surrogate to the requesting		o Hop Counts: Router hops from the surrogate to the requesting
	entity can be used as a proximity measurement.		entity can be used as a proximity measurement.
	o BGP Information: BGP AS PATH and MED attributes can be used to		o BGP Information: BGP AS PATH and MED attributes can be used to
	determine the "BGP distance" to a given prefix/length pair. In		determine the "BGP distance" to a given prefix/length pair. In
	order to use BGP information for proximity measurements, it must		order to use BGP information for proximity measurements, it must
	be obtained at each surrogate site/location.		be obtained at each surrogate site/location.
	A.1.4 Surrogate Feedback		It is important to note that the value of BGP AS PATH information can
			be meaningless as a good selection metric [24].
			A.1.3 Surrogate Feedback
	In order to select a "least-loaded" delivery node. Feedback can be		In order to select a "least-loaded" delivery node. Feedback can be
	delivered from each surrogate or can be aggregated by site or by		delivered from each surrogate or can be aggregated by site or by
	location.		location.
	A.1.4.1 Probing		A.1.3.1 Probing
	Feedback information may be obtained by periodically probing a		Feedback information may be obtained by periodically probing a
	surrogate by issuing an HTTP request and observing the behavior. The		surrogate by issuing an HTTP request and observing the behavior. The
	problems with probing for surrogate information are:		problems with probing for surrogate information are:
	o It is difficult to obtain "real-time" information.		o It is difficult to obtain "real-time" information.
	o Non-real-time information may be inaccurate.		o Non-real-time information may be inaccurate.
	Consequently, feedback information can be obtained by agents that		Consequently, feedback information can be obtained by agents that
	reside on surrogates that can communicate a variety of metrics about		reside on surrogates that can communicate a variety of metrics about
	their nodes.		their nodes.
	A.1.4.2 Well Known Metrics		Intellectual Property Statement
	The following provides a list of several of the popular metrics that
	are used for surrogate feedback:
	o Surrogate CPU Load.
	o Interface Load/Dropped packets.
	o Number of connections being served.		The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
	o Storage I/O Load.		The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgement
End of changes. 59 change blocks.
	206 lines changed or deleted		270 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/