draft-ietf-cdi-known-request-routing-01.txt		draft-ietf-cdi-known-request-routing-02.txt
	Network Working Group A. Barbir
	Internet-Draft Nortel Networks		Network Working Group B. Cain
	Expires: November 8, 2002 B. Cain		Internet-Draft Storigen Systems
	Storigen Systems		Expires: May 2, 2003 A. Barbir
	F. Douglis		Nortel Networks
	IBM Research
	M. Green
	CacheFlow
	M. Hofmann
	Lucent
	R. Nair		R. Nair
	D. Potter
	Cisco		Cisco
	O. Spatscheck		O. Spatscheck
	AT&T Labs		AT&T
			November 2002
	May 8, 2002
	Known CN Request-Routing Mechanisms		Known CN Request-Routing Mechanisms
	draft-ietf-cdi-known-request-routing-01.txt		draft-ietf-cdi-known-request-routing-02.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 groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months and may be updated, replaced, or obsoleted by other documents		and may be updated, replaced, or obsoleted by other documents at any
	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://
	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 November 08, 2002.		This Internet-Draft will expire on May 2, 2003.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2002). 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. In this memo the term
	Request-Routing represents techniques that are commonly called		Request-Routing represents techniques that are commonly called
	content routing or content redirection. In principle,		content routing or content redirection. In principle, Request-
	Request-Routing techniques can be classified under: DNS		Routing techniques can be classified under: DNS Request-Routing,
	Request-Routing, Transport-layer Request-Routing, and		Transport-layer Request-Routing, and Application-layer Request-
	Application-layer Request-Routing.		Routing.
	Table of Content		Table of Contents
	1. Introduction ................................................2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. DNS based Request-Routing Mechanisms ........................3		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 . . . . . . . . . . . . . . 6
	3. Transport-Layer Request-Routing .............................7		3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 8
	4. Application-Layer Request-Routing ...........................8		4. Application-Layer Request-Routing . . . . . . . . . . . . . 9
	4.1 Header Inspection ...........................................8		4.1 Header Inspection . . . . . . . . . . . . . . . . . . . . . 9
	4.1.1 URL-Based Request-Routing ...................................8		4.1.1 URL-Based Request-Routing . . . . . . . . . . . . . . . . . 9
	4.1.1.1 302 Redirection .............................................8		4.1.2 Header-Based Request-Routing . . . . . . . . . . . . . . . . 10
	4.1.1.2 In-Path Element .............................................9		4.1.3 Site-Specific Identifiers . . . . . . . . . . . . . . . . . 10
	4.1.2 Mime Header-Based Request-Routing ...........................9		4.2 Content Modification . . . . . . . . . . . . . . . . . . . . 11
	4.1.3 Site-Specific Identifiers ...................................10		4.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . . 11
	4.2 Content Modification ........................................10		4.2.2 On-Demand URL Rewriting . . . . . . . . . . . . . . . . . . 12
	4.2.1 A-priori URL Rewriting ......................................10		4.2.3 Content Modification Limitations . . . . . . . . . . . . . . 12
	4.2.2 On-Demand URL Rewriting .....................................11		5. Combination of Multiple Mechanisms . . . . . . . . . . . . . 13
	4.2.3 Content Modification Limitations ............................11		6. Security Considerations . . . . . . . . . . . . . . . . . . 14
	5. Combination of Multiple Mechanisms ..........................11		7. Additional Authors and Acknowledgements . . . . . . . . . . 15
	6. Security Considerations .....................................12		Normative References . . . . . . . . . . . . . . . . . . . . 16
	7. Acknowledgements ............................................12		Informative References . . . . . . . . . . . . . . . . . . . 17
	8. References ..................................................12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
	9. Authors' Addresses ..........................................12		A. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 18
	Appendix A ..................................................14		A.1 Proximity Measurements . . . . . . . . . . . . . . . . . . . 18
	A.1 Proximity Measurements ......................................14		A.1.1 Active Probing . . . . . . . . . . . . . . . . . . . . . . . 18
	A.1.1 Active Probing ..............................................14		A.1.2 Passive Measurement . . . . . . . . . . . . . . . . . . . . 19
	A.1.2 Passive Measurement .........................................15		A.1.3 Metric Types . . . . . . . . . . . . . . . . . . . . . . . . 19
	A.1.3 Metric Types ................................................15		A.1.4 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . . 20
	A.2 Surrogate Feedback ..........................................16		Full Copyright Statement . . . . . . . . . . . . . . . . . . 21
	A.2.1 Probing .....................................................16
	A.2.2 Well Known Metrics ..........................................16
	1. Introduction		1. Introduction
	The document provides a summary of current known techniques that		The document provides a summary of current known techniques that
	could be used to direct client requests to surrogates based on		could be used to direct client requests to surrogates based on
	various policies and a possible set of metrics. The task of		various policies and a possible set of metrics. The task of
	directing clients' requests to surrogates is also called		directing clients' requests to surrogates is also called Request-
	Request-Routing, Content Routing or Content Redirection.		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)[5]. 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		Content Networks deal with the routing and forwarding of requests and
	and responses for content. Content Networks rely on layer 7		responses for content. Content Networks rely on layer 7 protocols
	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		requests for objects to a surrogate or a set of surrogates that could
	could best serve that content. Request-Routing mechanisms could		best serve that content. Request-Routing mechanisms could be used to
	be used to direct client requests to surrogates that are within a		direct client requests to surrogates that are within a Content
	Content Network (CN) [5].		Network (CN) [8].
	Request-Routing techniques are used as a vehicle to extend the		Request-Routing techniques are used as a vehicle to extend the reach
	reach and scale of Content Delivery Networks. There exist multiple		and scale of Content Delivery Networks. There exist multiple
	Request-Routing mechanisms. At a high-level, these may be classified		Request-Routing mechanisms. At a high-level, these may be classified
	under: DNS Request-Routing, transport-layer Request-Routing, and		under: DNS Request-Routing, transport-layer Request-Routing, and
	application-layer Request-Routing.		application-layer Request-Routing.
	A request routing system uses a set of metrics in an attempt to		A request routing system uses a set of metrics in an attempt to
	direct users to surrogate that can best serve the request. For		direct users to surrogate that can best serve the request. For
	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		proximity, bandwidth availability, surrogate load and availability of
	of content. Appendix A provides a summary of metrics and		content. Appendix A provides a summary of metrics and measurement
	measurement techniques that could be used in the selection of		techniques that could be used in the selection of the best surrogate.
	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		transport-layer Request-Routing methods. In section 4 application
	application-layer Request-Routing mechanisms are explored. Section		layer Request-Routing mechanisms are explored. Section 5 provides
	5 provides insight on combining the various methods that were		insight on combining the various methods that were discussed in the
	discussed in the earlier sections in order to optimize the		earlier sections in order to optimize the performance of the Request-
	performance of the Request-Routing System. Appendix A provides		Routing System. Appendix A provides a summary of possible metrics
	a summary of possible metrics and measurements techniques that could		and measurements techniques that could be used by the Request-
	be used by the Request-Routing system to choose a given surrogate.		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 DNS as a directory service. 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.
	2.1 Single Reply		2.1 Single Reply
	In this approach, the DNS server is authoritative for the entire		In this approach, the DNS server is authoritative for the entire DNS
	DNS domain or a sub domain. The DNS server returns the IP address		domain or a sub domain. The DNS server returns the IP address of the
	of the best surrogate in an A record to the requesting DNS server.		best surrogate in an A record to the requesting DNS server. The IP
	The IP address of the surrogate could also be a virtual IP(VIP)		address of the surrogate could also be a virtual IP(VIP) address of
	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
	In this approach, the Request-Routing DNS server returns multiple		In this approach, the Request-Routing DNS server returns multiple
	replies such as several A records for various surrogates. Common		replies such as several A records for various surrogates. Common
	implementations of client site DNS server's cycles through the		implementations of client site DNS server's cycles through the
	multiple replies in a Round-Robin fashion. The order in which the		multiple replies in a Round-Robin fashion. The order in which the
	records are returned can be used to direct multiple clients using		records are returned can be used to direct multiple clients using a
	a single client site DNS server.		single client site DNS server.
	2.3 Multi-Level Resolution		2.3 Multi-Level Resolution
	In this approach multiple Request-Routing DNS servers can be		In this approach multiple Request-Routing DNS servers can be involved
	involved in a single DNS resolution. The rationale of utilizing		in a single DNS resolution. The rationale of utilizing multiple
	multiple Request-Routing DNS servers in a single DNS resolution		Request-Routing DNS servers in a single DNS resolution is to allow
	is to allow one to distribute more complex decisions from a		one to distribute more complex decisions from a single server to
	single server to multiple, more specialized, Request-Routing DNS		multiple, more specialized, Request-Routing DNS servers. The most
	servers. The most common mechanisms used to insert multiple		common mechanisms used to insert multiple Request-Routing DNS servers
	Request-Routing DNS servers in a single DNS resolution is the		in a single DNS resolution is the use of NS and CNAME records. An
	use of NS and CNAME records. An example would be the case where		example would be the case where a higher level DNS server operates
	a higher level DNS server operates within a territory,		within a territory, directing the DNS lookup to a more specific DNS
	directing the DNS lookup to a more specific DNS server within that		server within that territory to provide a more accurate resolution.
	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		A DNS server can use NS records to redirect the authority of the next
	next level domain to another Request-Routing DNS server. The,		level domain to another Request-Routing DNS server. The, technique
	technique allows multiple DNS server to be involved in the name		allows multiple DNS server to be involved in the name resolution
	resolution process. For example, a client site DNS server		process. For example, a client site DNS server resolving
	resolving a.b.c.com would eventually request a resolution of		a.b.example.com [10] would eventually request a resolution of
	a.b.c.com from the name server authoritative for c.com. The name		a.b.example.com from the name server authoritative for example.com.
	server authoritative for this domain might be a Request-Routing		The name server authoritative for this domain might be a Request-
	NS server. In this case the Request-Routing DNS server can either		Routing NS server. In this case the Request-Routing DNS server can
	return a set of A records or can redirect the resolution of the		either return a set of A records or can redirect the resolution of
	request a.b.c.com to the DNS server that is authoritative for		the request a.b.example.com to the DNS server that is authoritative
	.c.com using NS records.		for example.com using NS records.
	One drawback of using NS records is that the number of		One drawback of using NS records is that the number of Request-
	Request-Routing DNS servers are limited by the number of parts in		Routing DNS servers are limited by the number of parts in the DNS
	the DNS name. This problem results from DNS policy that causes a		name. This problem results from DNS policy that causes a client site
	client site DNS server to abandon a request if no additional parts		DNS server to abandon a request if no additional parts of the DNS
	of the DNS name are resolved in an exchange with an authoritative		name are resolved in an exchange with an authoritative DNS server.
	DNS server.
	A second drawback is that the last DNS server can determine the		A second drawback is that the last DNS server can determine the TTL
	TTL of the entire resolution process. Basically, the last DNS		of the entire resolution process. Basically, the last DNS server can
	server can return in the authoritative section of its response its		return in the authoritative section of its response its own NS
	own NS record. The client will use this cached NS record for		record. The client will use this cached NS record for further
	further request resolutions until it expires.		request 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		NS level redirect points to a name server for which no valid A record
	record is returned or cached. This is especially a problem if the		is returned or cached. This is especially a problem if the domain of
	domain of the name server does not match the domain currently		the name server does not match the domain currently resolved, since
	resolved, since in this case the A records, which might be passed		in this case the A records, which might be passed in the DNS
	in the DNS response, are discarded for security reasons. Another		response, are discarded for security reasons. Another drawback is
	drawback is the added delay in resolving the request due to the		the added delay in resolving the request due to the use of multiple
	use of multiple DNS servers.		DNS 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		record to direct resolution to an entirely new domain. In principle,
	principle, the new domain might employ a new set of Request-Routing		the new domain might employ a new set of Request-Routing DNS servers.
	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 that the number of Request-Routing DNS servers is independent		is that the number of Request-Routing DNS servers is independent of
	of the format of the domain name.		the format of the domain name.
	2.4 Anycast		2.4 Anycast
	Anycast [6] 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		best effort delivery of the datagram to at least one, and preferably
	preferably only one, of the servers that accept datagrams for the		only one, of the servers that accept datagrams for the anycast
	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 consulting a list of servers and choosing the closest one, could		of 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		Furthermore, to combine measurement and redirection, the Request-
	Request-Routing DNS server can advertise an anycast address as its		Routing DNS server can advertise an anycast address as its IP
	IP address. The same address is used by multiple physical DNS		address. The same address is used by multiple physical DNS servers.
	servers. In this scenario, the Request-Routing DNS server that is		In this scenario, the Request-Routing DNS server that is the closest
	the closest to the client site DNS server in terms of OSPF and		to the client site DNS server in terms of OSPF and BGP routing will
	BGP routing will receive the packet containing the DNS resolution		receive the packet containing the DNS resolution request. The server
	request. The server can use this information to make a Request-		can use this information to make a Request- Routing decision.
	Routing decision. Drawbacks of this approach are listed below:		Drawbacks of this approach are listed below:
	* The DNS server may not be the closest server in terms of		o The DNS server may not be the closest server in terms of routing
	routing to the client.		to the client.
	* Typically, routing protocols are not load sensitive. Hence,		o Typically, routing protocols are not load sensitive. Hence, the
	the closest server may not be the one with the least network		closest server may not be the one with the least network latency.
	latency.
	* The server load is not considered during the Request-		o The server load is not considered during the Request-Routing
	Routing process.		process.
	2.5 Object Encoding		2.5 Object Encoding
	Since only DNS names are visible during the DNS Request-Routing,		Since only DNS names are visible during the DNS Request-Routing, some
	some solutions encode the object type, object hash, or similar		solutions encode the object type, object hash, or similar information
	information into the DNS name. This might vary from a simple		into the DNS name. This might vary from a simple division of objects
	division of objects based on object type (such as images.a.b.c.com		based on object type (such as images.a.b.example.com and
	and streaming.a.b.c.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 at resolution time. The disadvantage is that the client		available at resolution time. The disadvantage is that the client
	site DNS server has to perform multiple resolutions to retrieve a		site DNS server has to perform multiple resolutions to retrieve a
	single Web page, which might increase rather than decrease the		single Web 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		Some limitations of DNS based Request-Routing techniques are
	described below:		described below:
	1. DNS only allows resolution at the domain level. However, an		o DNS only allows resolution at the domain level. However, an ideal
	ideal request resolution system should service requests		request resolution system should service requests per object
	per object level.		level.
	2. In DNS based Request-Routing systems servers may be required		o In DNS based Request-Routing systems servers may be required to
	to return DNS entries with a short time-to-live (TTL) values.		return DNS entries with a short time-to-live (TTL) values. This
	This may be needed in order to be able to react quickly in the		may be needed in order to be able to react quickly in the face of
	face of outages. This in return may increase the volume of		outages. This in return may increase the volume of requests to
	requests to DNS servers.		DNS servers.
	3. 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.
	4. DNS Request-Routing is based only on knowledge of the client		o DNS Request-Routing is based only on knowledge of the client DNS
	DNS server, as client addresses are not relayed within DNS		server, as client addresses are not relayed within DNS requests.
	requests. This limits the ability of the Request-Routing system		This limits the ability of the Request-Routing system to determine
	to determine a client's proximity to the surrogate.		a client's proximity to the surrogate.
	5. 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-		names. For recursive resolution of requests, the Request-Routing
	Routing DNS server will not be exposed to the IP address of the		DNS server will not be exposed to the IP address of the client's
	client's site DNS server. In this case, the Request-Routing DNS		site DNS server. In this case, the Request-Routing DNS server
	server will be exposed to the address of the DNS server that is		will be exposed to the address of the DNS server that is
	recursively requesting the information on behalf of the client's		recursively requesting the information on behalf of the client's
	site DNS server. For example, imgs.company.com might be resolved		site DNS server. For example, imgs.example.com might be resolved
	by a CN, but the request for the resolution might come from		by a CN, but the request for the resolution might come from
	dns1.company.com as a result of the recursion.		dns1.example.com as a result of the recursion.
	6. 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		interval. This might lead to overloading of the surrogate during
	during a flash crowd.		a flash crowd.
	7. Some implementations of bind can cause DNS timeouts to occur		o Some implementations of bind can cause DNS timeouts to occur while
	while handling exceptional situations. For example, timeouts		handling exceptional situations. For example, timeouts can occur
	can occur for NS redirections to unknown domains.		for NS redirections to unknown domains.
	3. Transport-Layer Request-Routing		3. Transport-Layer Request-Routing
	At the transport-layer finer levels of granularity can be achieved		At the transport-layer finer levels of granularity can be achieved by
	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		protocol. The acquired data could be used in combination with user-
	user-defined policies and other metrics to determine the selection		defined policies and other metrics to determine the selection of a
	of a surrogate that is better suited to serve the request. The		surrogate that is better suited to serve the request. The techniques
	techniques that are used to hand off the session to a more		that are used to hand off the session to a more appropriate surrogate
	appropriate surrogate are beyond the scope of this document.		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		transfers much more data than the forward flow, would typically take
	take the direct path.		the direct path.
	The overhead associated with transport-layer Request-Routing makes		The overhead associated with transport-layer Request-Routing makes it
	it better suited for long-lived sessions such as FTP [1]and RTSP [3].		better suited for long-lived sessions such as FTP [1]and RTSP [3].
	However, it also could be used to direct clients away from overloaded		However, it also could be used to direct clients away from overloaded
	surrogates.		surrogates.
	In general, transport-layer Request-Routing can be combined with		In general, transport-layer Request-Routing can be combined with DNS
	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		clients requests based on domains or sub domains with exposure to the
	the client's DNS server IP address. Hence, the DNS based methods		client's DNS server IP address. Hence, the DNS based methods could
	could be used as a first step in deciding on an appropriate		be used as a first step in deciding on an appropriate surrogate with
	surrogate with more accurate refinement made by the		more accurate refinement made by the transport-layer Request-Routing
	transport-layer Request-Routing system.		system.
	4. Application-Layer Request-Routing		4. Application-Layer Request-Routing
	Application-layer Request-Routing systems perform deeper		Application-layer Request-Routing systems perform deeper examination
	examination of client's packets beyond the transport layer		of client's packets beyond the transport layer header. Deeper
	header. Deeper examination of client's packets provides		examination of client's packets provides fine-grained Request-Routing
	fine-grained Request-Routing control down to the level of		control down to the level of individual objects. The process could
	individual objects. The process could be performed in real		be performed in real time at the time of the object request. The
	time at the time of the object request. The exposure to the		exposure to the client's IP address combined with the fine-grained
	client's IP address combined with the fine-grained knowledge		knowledge of the requested objects enable application-layer Request-
	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		best surrogate.
	the best surrogate.
	4.1 Header Inspection		4.1 Header Inspection
	Some application level protocols such as HTTP [4], RTSP [3],		Some application level protocols such as HTTP [4], RTSP [3], and SSL
	and SSL [2] provide hints in the initial portion of the session		[2] provide hints in the initial portion of the session about how the
	about how the client request must be directed. These hints may come		client request must be directed. These hints may come from the URL
	from the URL of the content or other parts of the MIME request header		of the content or other parts of the MIME request header such as
	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 [7]. In many cases, this information		requested content by its URL [6]. In many cases, this information
	is sufficient to disambiguate the content and suitably direct the		is 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 decision just by examining the prefix or suffix of the URL.		Routing 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		In this approach, the client's request is first resolved to a virtual
	virtual surrogate. Consequently, the surrogate returns an		surrogate. Consequently, the surrogate returns an application-
	application-specific code such as the 302 (in the case of		specific code such as the 302 (in the case of HTTP [4] or RTSP [3])
	HTTP [4] or RTSP [3]) to redirect the client to the actual		to redirect the client to the actual delivery node.
	delivery node.
	This technique is relatively simple to implement. However, the		This technique is relatively simple to implement. However, the main
	main drawback of this method is the additional latency involved in		drawback of this method is the additional latency involved in sending
	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
	In-Path element examines the client's content requests and performs		In-Path element examines the client's content requests and performs
	Request-Routing decisions.		Request-Routing decisions.
	The In-Path element then splices the client connection to a		The In-Path element then splices the client connection to a
	skipping to change at page 9, line 35		skipping to change at page 10, line 21
	implications of URL-parsing in the path of the network traffic.		implications of URL-parsing in the path of the network traffic.
	However, it is generally the case that the return traffic is much		However, it is generally the case that the return traffic is much
	larger than the forward traffic.		larger than the forward traffic.
	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 Mime Header-Based Request-Routing		4.1.2 Header-Based Request-Routing
	This technique involves the task of using MIME-headers such as		This technique involves the task of using HTTP [4] such as Cookie,
	Cookie, Language, and User-Agent, in order to select a surrogate.		Language, and User-Agent, in order to select a surrogate.
	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		Cookie based Request-Routing provides content service differentiation
	differentiation based on the client. This approach works provided		based on the client. This approach works provided that the cookies
	that the cookies belong to the client. In addition, it is possible		belong to the client. In addition, it is possible to direct a
	to direct a connection from a multi-session transaction to be		connection from a multi-session transaction to be directed to the
	directed to the same server to achieve session-level		same server to achieve session-level persistence.
	persistence.
	The language header can be used to direct traffic to a		The language header can be used to direct traffic to a language-
	language-specific delivery node. The user-agent header helps		specific delivery node. The user-agent header helps identify the
	identify the type of client device. For example, a voice-browser,		type of client device. For example, a voice-browser, PDA, or cell
	PDA, or cell phone can indicate the type of delivery node that has		phone can indicate the type of delivery node that has content
	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
	Identifier. This identifier is generated by a web server and used		Identifier. This identifier is generated by a web server and used by
	by the web client in succeeding sessions to identify itself and		the web client in succeeding sessions to identify itself and avoid an
	avoid an entire security authentication exchange. In order to		entire security authentication exchange. In order to inspect the
	inspect the session identifier, an In-Path element would observe		session identifier, an In-Path element would observe the responses of
	the responses of the web server and determine the session identifier		the web server and determine the session identifier which is then
	which is then used to associate the session to a specific server.		used to associate the session to a specific server. The remaining
	The remaining sessions are directed based on the stored		sessions are directed based on the stored session identifier.
	session identifier.
	4.2 Content Modification		4.2 Content Modification
	This technique enables a content provider to take direct control		This technique enables a content provider to take direct control over
	over Request-Routing decisions without the need for specific		Request-Routing decisions without the need for specific witching
	witching devices or directory services in the path between the		devices or directory services in the path between the client and the
	client and the origin server. Basically, a content provider can		origin server. Basically, a content provider can directly
	directly communicate to the client the best surrogate that can		communicate to the client the best surrogate that can serve the
	serve the request. Decisions about the best surrogate can be made		request. Decisions about the best surrogate can be made on a per-
	on a per-object basis or it can depend on a set of metrics. The		object basis or it can depend on a set of metrics. The overall goal
	overall goal is to improve scalability and the performance for		is to improve scalability and the performance for delivering the
	delivering the modified content, including all embedded objects.		modified content, 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 objects,		document that contains plain text together with some embedded
	such as GIF or JPEG images. The embedded objects are referenced using		objects, such as GIF or JPEG images. The embedded objects are
	embedded HTML directives. In general, embedded HTML directives direct		referenced using embedded HTML directives. In general, embedded HTML
	the client to retrieve the embedded objects from the origin server.		directives direct the client to retrieve the embedded objects from
	A content provider can now modify references to embedded objects		the origin server. A content provider can now modify references to
	such that they could be fetched from the best surrogate. This		embedded objects such that they could be fetched from the best
	technique is also known as URL rewriting. The basic types of URL		surrogate. This technique is also known as URL rewriting.
	rewriting are discussed in the following subsections.
			Content modification techniques must not violate the architectural
			concepts of the Internet [9]. Special considerations must be made to
			ensure that the task of modifying the content is performed in a
			manner that is consistent with RFC 3238 [9] that specifies the
			architectural considerations for intermediaries that perform
			operations or modifications on content.
			The basic types of URL rewriting are discussed in the following
			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		In this scheme, a content provider rewrites the embedded URLs before
	before the content is positioned on the origin server. In this		the content is positioned on the origin server. In this case, URL
	case, URL rewriting can be done either manually or by using a		rewriting can be done either manually or by using a software tools
	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 with DNS Request-Routing to direct related DNS queries		combination with DNS Request-Routing to direct related DNS queries
	into the domain name space of the service provider. Dynamic		into the domain name space of the service provider. Dynamic Request-
	Request-Routing based on client specifics are then done using		Routing based on client specifics are then done using the DNS
	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		identity of the client is known and can be considered when rewriting
	rewriting the embedded URLs. In particular, an automated process		the embedded URLs. In particular, an automated process can
	can determine, on-demand, which surrogate would serve the		determine, on-demand, which surrogate would serve the requesting
	requesting client best. The embedded URLs can then be		client best. The embedded URLs can then be rewritten to direct
	rewritten to direct the client to retrieve the objects from the		the client to retrieve the objects from the best surrogate rather
	best surrogate rather than from the origin server.		than from the origin server.
	4.2.3 Content Modification Limitations		4.2.3 Content Modification Limitations
	Content modification as a Request-Routing mechanism suffers from		Content modification as a Request-Routing mechanism suffers from the
	the following limitations:		following limitations:
	1. The first request from a client to a specific site must		o The first request from a client to a specific site must be served
	be served from the origin server.		from the origin server.
	2. Content that has been modified to include references to		o Content that has been modified to include references to nearby
	nearby surrogates rather than to the origin server should		surrogates rather than to the origin server should be marked as
	be marked as non-cacheable. Alternatively, such pages can		non-cacheable. Alternatively, such pages can be marked to be
	be marked to be cacheable only for a relatively short period		cacheable only for a relatively short period of time. Rewritten
	of time. Rewritten URLs on cached pages can cause problems,		URLs on cached pages can cause problems, because they can get
	because they can get outdated and point to surrogates		outdated and point to surrogates that are no longer available or
	that are no longer available or no longer good choices.		no longer good choices.
	5. Combination of Multiple Mechanisms		5. Combination of Multiple Mechanisms
	There are environments in which a combination of different		There are environments in which a combination of different mechanisms
	mechanisms can be beneficial and advantageous over using one of		can be beneficial and advantageous over using one of the proposed
	the proposed mechanisms alone. The following example illustrates		mechanisms alone. The following example illustrates how the
	how the mechanisms can be used in combination.		mechanisms can be used in combination.
	A basic problem of DNS Request-Routing is the resolution		A basic problem of DNS Request-Routing is the resolution granularity
	granularity that allows resolution on a per-domain level only. A		that allows resolution on a per-domain level only. A per-object
	per-object redirection cannot easily be achieved. However, content		redirection cannot easily be achieved. However, content modification
	modification can be used together with DNS Request-Routing to		can be used together with DNS Request-Routing to overcome this
	overcome this problem. With content modification, references to		problem. With content modification, references to different objects
	different objects on the same origin server can be rewritten to		on the same origin server can be rewritten to point into different
	point into different domain name spaces. Using DNS Request-Routing,		domain name spaces. Using DNS Request-Routing, requests for those
	requests for those objects can now dynamically be directed to		objects can now dynamically be directed to different surrogates.
	different surrogates.
	6. Security Considerations		6. Security Considerations
	The main objective of this document is to provide a summary of current		The main objective of this document is to provide a summary of
	Request-Routing techniques. Such techniques are currently implemented		current Request-Routing techniques. Such techniques are currently
	in the Internet. The document acknowledges that security must be		implemented in the Internet. The document acknowledges that security
	addressed by any entity that implements any technique that redirects		must be addressed by any entity that implements any technique that
	client's requests. However, the details of such techniques are beyond		redirects client's requests. In [9] RFC 3238 addresses the main
	the scope of this document.		requirements for entities that intent to modify requests for content
			in the Internet.
	7. Acknowledgements		The details of security techniques are beyond the scope of this
			document.
	The authors acknowledge the contributions and comments of Ian Cooper,		7. Additional Authors and Acknowledgements
	Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean (CrystalBall).
	8. References		The following people have contributed to the task of authoring this
			document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann
			(Lucent), Doug Potter.
	[1] Postel, J., "File Transfer Protocol", RFC 765, June 1980,		The authors acknowledge the contributions and comments of Ian Cooper,
			Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean
			(CrystalBall).
	[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC		Normative References
	846, January 1999.
	[3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming		[1] Postel, J.l, "File Transfer Protocol", RFC 765, June 1980.
	Protocol", RFC 2326, April 1998.
	[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,		[2] T. Dierks et. al, "The TLS Protocol Version 1", RFC 846, July
	Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --		1999.
	HTTP/1.1", RFC 2616, June 1999.
	[5] Day, M., Cain, B. and G. Tomlinson, " A Model for Content		[3] H. Schulzrinne et. al, "Real Time Streaming Protocol", RFC 2326,
	Internetworking (CDI)", http://www.ietf.org/internet-drafts/		April 1998.
	draft-ietf-cdi-model-02.txt (Group Last Call).
	[6] Partridge, C., Mendez, T., Milliken W., "Host Anycasting		[4] R. Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1",
	Service", RFC 1546, November 1993.		RFC 2616, June 1999.
	[7] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource		[5] C. Partridge et al., "Host Anycasting Service", RFC 1546,
	Locators (URL)", RFC 1738,May 1994.		November 1993.
	[8] H. Schulzrinne, H., Fokus, G., Casner, S., Frederick, R.,		[6] T. Berners-Lee et al, "Uniform Resource Locators (URL)", RFC
	Jacobson, V., "RTP: A Transport Protocol for Real-Time		1738, May 1994.
			[7] H. Schulzrinneet al, "RTP: A Transport Protocol for Real-Time
	Applications", RFC 1889, January 1996.		Applications", RFC 1889, January 1996.
	9. Authors' Addresses		[8] M. Day et al, "A Model for Content Internetworking (CDI)",
			Internet-Draft: http://www.ietf.org/internet-drafts/ draft-ietf-
			cdi-model-02.txt (groups Last Call), May 2002.
			[9] S. Floyd et al, "IAB Architectural and Policy Considerations for
			Open Pluggable Edge Services", RFC 3238, January 2002.
			Informative References
			[10] D. Eastlake et al, "Reserved Top Level DNS Names", RFC 2606,
			June 1999.
			Authors' Addresses
	Abbie Barbir
	Nortel Networks
	3500 Carling Avenue, Nepean Ontario K2H 8E9 Canada
	EMail: abbieb@nortelnetworks.com
	Brad Cain		Brad Cain
	Storigen Systems		Storigen Systems
	650 Suffolk Street		650 Suffolk Street
	Lowell, MA 01854 US		Lowell, MA 01854
			USA
	Phone: +1 978-323-4454		Phone: +1 978-323-4454
	EMail: bcain@storigen.com		EMail: bcain@storigen.com
	Fred Douglis		Abbie Barbir
	IBM Research		Nortel Networks
	EMail: fdouglis@us.ibm.com		3500 Carling Avenue
			Nepean, Ontario K2H 8E9
	Mark Green		Canada
	CacheFlow
	650 Almanor Avenue
	Sunnyvale, CA 94085, US
	EMail: markg@cacheflow.com
	Markus Hofmann		Phone: +1 613 763 5229
	Lucent Technologies		EMail: abbieb@nortelnetworks.com
	Room 4F-513
	101 Crawfords Corner Rd.
	Holmdel, NJ 07733, US
	EMail: hofmann@bell-labs.com
	Raj Nair		Raj Nair
	Cisco Systems		Cisco
	50 Nagog Park		50 Nagog Park
	Acton, MA 01720, US		Acton, MA 01720
	EMail: rnair@cisco.com		USA
	Doug Potter		EMail: rnair@cisco.com
	Cisco Systems
	50 Nagog Park
	Acton, MA 01720, US
	EMail: dougpott@cisco.com
	Oliver Spatscheck		Oliver Spatscheck
	AT&T Labs		AT&T
	Room B131
	180 Park Ave, Bldg 103		180 Park Ave, Bldg 103
	Florham Park, NJ 07932, US		Florham Park, NJ 07932
			USA
	EMail: spatsch@research.att.com		EMail: spatsch@research.att.com
	Appendix A
	Measurements		Appendix A. Measurements
	Request-Routing systems can use a variety of metrics in order		Request-Routing systems can use a variety of metrics in order to
	to determine the best surrogate that can serve a client's request.		determine the best surrogate that can serve a client's request. In
	In general, these metrics are based on network measurements and		general, these metrics are based on network measurements and feedback
	feedback from surrogates. It is possible to combine multiple		from surrogates. It is possible to combine multiple metrics using
	metrics using both proximity and surrogate feedback for best		both proximity and surrogate feedback for best surrogate selection.
	surrogate selection. The following sections describe several		The following sections describe several well known metrics as well as
	well known metrics as well as the major techniques for obtaining		the major techniques for obtaining them.
	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 a DNS Request-Routing
	system, the measurements are made to the client's local DNS server.		system, the measurements are made to the client's local DNS server.
	However, when the IP address of the client is accessible more		However, when the IP address of the client is accessible more
	accurate proximity measurements can be obtained.		accurate proximity measurements can be obtained.
	Furthermore, proximity measurements can be exchanged between		Furthermore, proximity measurements can be exchanged between
	surrogates and the requesting entity. In many cases, proximity		surrogates and the requesting entity. In many cases, proximity
	measurements are "one-way" in that they measure either the forward		measurements are "one-way" in that they measure either the forward or
	or reverse path of packets from the surrogate to the requesting		reverse path of packets from the surrogate to the requesting entity.
	entity. This is important as many paths in the Internet are		This is important as many paths in the Internet are asymmetric.
	asymmetric.
	In order to obtain a set of proximity measurements, a network		In order to obtain a set of proximity measurements, a network may
	may employ active probing techniques and/or passive measurement		employ active probing techniques and/or passive measurement
	techniques. The following sections describe these two 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		probed using one or more techniques to determine one or more metrics
	metrics from each surrogate or set of surrogates. An example of		from each surrogate or set of surrogates. An example of a probing
	a probing technique is an ICMP ECHO Request that is periodically		technique is an ICMP ECHO Request that is periodically sent from each
	sent from each surrogate or set of surrogates to a potential		surrogate or set of surrogates to a potential requesting entity.
	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 is to use an algorithm to divide address space into blocks		solution is to use an algorithm to divide address space into blocks
	and to probe random addresses within those blocks. Limitations		and to probe random addresses within those blocks. Limitations of
	of active probing techniques include:		active probing techniques include:
	1. Measurements can only be taken periodically.		o Measurements can only be taken periodically.
	2. Firewalls and NATs disallow probes.
	3. Probes often cause security alarms to be triggered on		o Firewalls and NATs disallow probes.
	intrusion detection systems.
			o Probes often cause security alarms to be triggered on intrusion
			detection systems.
	A.1.2 Passive Measurement		A.1.2 Passive Measurement
	Passive measurements could be obtained when a client performs data		Passive measurements could be obtained when a client performs data
	transfers to or from a surrogate. Here, a bootstrap mechanism is		transfers to or from a surrogate. Here, a bootstrap mechanism is
	used to direct the client to a bootstrap surrogate. Once the client		used to direct the client to a bootstrap surrogate. Once the client
	connects, the actual performance of the transfer is measured. This		connects, the actual performance of the transfer is measured. This
	data is then fed back into the Request-Routing system.		data is then fed back into the Request-Routing system.
	An example of passive measurement is to watch the packet loss		An example of passive measurement is to watch the packet loss from a
	from a client to a surrogate by observing TCP behavior. Latency		client to a surrogate by observing TCP behavior. Latency
	measurements can also be learned by observing TCP behavior. The		measurements can also be learned by observing TCP behavior. The
	limitations of passive measurement approach are directly related		limitations of passive measurement approach are directly related to
	to the bootstrapping mechanism. Basically, a good mechanism is		the bootstrapping mechanism. Basically, a good mechanism is needed
	needed to ensure that not every surrogate is tested per client		to ensure that not every surrogate is tested per client in order to
	in order to obtain the data.		obtain the data.
	A.1.3 Metric Types		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.
	* 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		determine the surrogate (or set of surrogates) that has the least
	least delay to the requesting entity. These measurements		delay to the requesting entity. These measurements can be
	can be obtained using either an active probing approach or a		obtained using either an active probing approach or a
	passive network measurement system.		passive network measurement system.
	* Packet Loss: Packet loss measurements can be used as a		o Packet Loss: Packet loss measurements can be used as a selection
	selection metric. A passive measurement approach can easily		metric. A passive measurement approach can easily obtain packet
	obtain packet loss information from TCP header information.		loss information from TCP header information. Active probing can
	Active probing can periodically measure packet loss from		periodically measure packet loss from probes.
	probes.
	* 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.
	* BGP Information: BGP AS PATH and MED attributes can be used		o BGP Information: BGP AS PATH and MED attributes can be used to
	to determine the "BGP distance" to a given prefix/length		determine the "BGP distance" to a given prefix/length pair. In
	pair. In order to use BGP information for proximity		order to use BGP information for proximity measurements, it must
	measurements, it must be obtained at each surrogate		be obtained at each surrogate site/location.
	site/location.
	A.2 Surrogate Feedback		A.1.4 Surrogate Feedback
	The Request-Routing system can use feedback from surrogates in		In order to select a "least-loaded" delivery node. Feedback can be
	order to select a "least-loaded" delivery node. Feedback can		delivered from each surrogate or can be aggregated by site or by
	be delivered from each surrogate or can be aggregated by site or		location.
	by location.
	A.2.1 Probing		A.1.4.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.		surrogate by issuing an HTTP request and observing the behavior. The
	The problems with probing for surrogate information are:		problems with probing for surrogate information are:
	1. It is difficult to obtain "real-time" information.		o It is difficult to obtain "real-time" information.
	2. 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.2.2 Well Known Metrics		A.1.4.2 Well Known Metrics
	The following provides a list of several of the popular metrics		The following provides a list of several of the popular metrics that
	that are used for surrogate feedback:		are used for surrogate feedback:
	* Surrogate CPU Load.		o Surrogate CPU Load.
	* Interface Load / Dropped packets.
	* Number of connections being served.		o Interface Load/Dropped packets.
	* Storage I/O Load.
			o Number of connections being served.
			o Storage I/O Load.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2002). 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		kind, provided that the above copyright notice and this paragraph are
	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 assigns.
	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
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 118 change blocks.
	434 lines changed or deleted		424 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/