draft-ietf-cdi-known-request-routing-01
"Abbie Barbir"<[email protected]> Wed, 8 May 2002 10:37:08 -0400
| Newsgroups | gmane.ietf.cdi |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C1F69D.D38217C2
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C1F69D.D38217C2"
------_=_NextPart_001_01C1F69D.D38217C2
Content-Type: text/plain;
charset="iso-8859-1"
Please publish the attached as as Internet-Draft
<<draft-ietf-cdi-known-request-routing-01.txt>>
thanks
------_=_NextPart_001_01C1F69D.D38217C2
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>draft-ietf-cdi-known-request-routing-01</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=2 FACE="Courier New">Please publish the attached as as Internet-Draft</FONT>
<BR><FONT FACE="Arial" SIZE=2 COLOR="#000000"> <<draft-ietf-cdi-known-request-routing-01.txt>> </FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">thanks</FONT>
</P>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C1F69D.D38217C2--
------_=_NextPart_000_01C1F69D.D38217C2
Content-Type: text/plain;
name="draft-ietf-cdi-known-request-routing-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-cdi-known-request-routing-01.txt"
Network Working Group A. Barbir
Internet-Draft Nortel Networks
Expires: November 8, 2002 B. Cain
Storigen =
Systems=20
F. Douglis
IBM Research
M. Green
CacheFlow
M. Hofmann
Lucent
R. Nair
D. Potter
Cisco
O. Spatscheck
AT&T Labs
=20
May 8, 2002
Known CN Request-Routing Mechanisms=20
draft-ietf-cdi-known-request-routing-01.txt
=20
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 08, 2002.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Cain, et. al. Expires November 8, 2002 [Page =
1]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
Abstract
The work presents a summary of Request-Routing techniques that are=20
used to direct client requests to surrogates based on various=20
policies and a possible set of metrics. In this memo the term=20
Request-Routing represents techniques that are commonly called=20
content routing or content redirection. In principle,=20
Request-Routing techniques can be classified under: DNS=20
Request-Routing, Transport-layer Request-Routing, and=20
Application-layer Request-Routing. =20
Table of Content
1. Introduction ................................................2
2. DNS based Request-Routing Mechanisms ........................3
2.1 Single Reply ................................................4
2.2 Multiple Replies ............................................4
2.3 Multi-Level Resolution ......................................4
2.3.1 NS Redirection ..............................................4
2.3.2 CNAME Redirection ...........................................5
2.4 Anycast .....................................................5
2.5 Object Encoding .............................................6
2.6 DNS Request-Routing Limitations .............................6
3. Transport-Layer Request-Routing .............................7
4. Application-Layer Request-Routing ...........................8
4.1 Header Inspection ...........................................8
4.1.1 URL-Based Request-Routing ...................................8
4.1.1.1 302 Redirection .............................................8
4.1.1.2 In-Path Element .............................................9
4.1.2 Mime Header-Based Request-Routing ...........................9
4.1.3 Site-Specific Identifiers ...................................10
4.2 Content Modification ........................................10
4.2.1 A-priori URL Rewriting ......................................10
4.2.2 On-Demand URL Rewriting .....................................11
4.2.3 Content Modification Limitations ............................11
5. Combination of Multiple Mechanisms ..........................11
6. Security Considerations .....................................12
7. Acknowledgements ............................................12
8. References ..................................................12
9. Authors' Addresses ..........................................12
Appendix A ..................................................14
A.1 Proximity Measurements ......................................14
A.1.1 Active Probing ..............................................14
A.1.2 Passive Measurement .........................................15
A.1.3 Metric Types ................................................15
A.2 Surrogate Feedback ..........................................16
A.2.1 Probing .....................................................16
A.2.2 Well Known Metrics ..........................................16
Cain, et. al. Expires November 8, 2002 [Page =
2]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
1. Introduction
The document provides a summary of current known techniques that=20
could be used to direct client requests to surrogates based on=20
various policies and a possible set of metrics. The task of=20
directing clients' requests to surrogates is also called=20
Request-Routing, Content Routing or Content Redirection.=20
Request-Routing techniques are commonly used in Content Networks=20
(also known as Content Delivery Networks)[5]. Content Networks=20
include network infrastructure that exists in layers 4 through 7.=20
Content Networks deal with the routing and forwarding of requests=20
and responses for content. Content Networks rely on layer 7=20
protocols such as HTTP [4] for transport.
Request-Routing techniques are generally used to direct client=20
requests for objects to a surrogate or a set of surrogates that=20
could best serve that content. Request-Routing mechanisms could
be used to direct client requests to surrogates that are within a=20
Content Network (CN) [5].=20
Request-Routing techniques are used as a vehicle to extend the=20
reach and scale of Content Delivery Networks. There exist multiple=20
Request-Routing mechanisms. At a high-level, these may be classified =
under: DNS Request-Routing, transport-layer Request-Routing, and=20
application-layer Request-Routing.
A request routing system uses a set of metrics in an attempt to=20
direct users to surrogate that can best serve the request. For=20
example, the choice of the surrogate could be based on network=20
proximity, bandwidth availability, surrogate load and availability
of content. Appendix A provides a summary of metrics and=20
measurement techniques that could be used in the selection of=20
the best surrogate.
=20
The memo is organized as follows: Section 2 provides a summary of=20
known DNS based Request-Routing techniques. Section 3 discusses=20
transport-layer Request-Routing methods. In section 4=20
application-layer Request-Routing mechanisms are explored. Section=20
5 provides insight on combining the various methods that were=20
discussed in the earlier sections in order to optimize the=20
performance of the Request-Routing System. Appendix A provides=20
a summary of possible metrics and measurements techniques that could =
be used by the Request-Routing system to choose a given surrogate.
2. DNS based Request-Routing Mechanisms
DNS based Request-Routing techniques are common due to the ubiquity=20
of DNS as a directory service. In DNS based Request-Routing=20
techniques, a specialized DNS server is inserted in the DNS=20
Cain, et. al. Expires November 8, 2002 [Page =
3]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
resolution process. The server is capable of returning a different=20
set of A, NS or CNAME records based on user defined policies,=20
metrics, or a combination of both. =20
2.1 Single Reply=20
In this approach, the DNS server is authoritative for the entire=20
DNS domain or a sub domain. The DNS server returns the IP address=20
of the best surrogate in an A record to the requesting DNS server.=20
The IP address of the surrogate could also be a virtual IP(VIP)=20
address of the best set of surrogates for requesting DNS server.
2.2 Multiple Replies
In this approach, the Request-Routing DNS server returns multiple=20
replies such as several A records for various surrogates. Common=20
implementations of client site DNS server's cycles through the=20
multiple replies in a Round-Robin fashion. The order in which the=20
records are returned can be used to direct multiple clients using=20
a single client site DNS server.
2.3 Multi-Level Resolution
In this approach multiple Request-Routing DNS servers can be=20
involved in a single DNS resolution. The rationale of utilizing=20
multiple Request-Routing DNS servers in a single DNS resolution=20
is to allow one to distribute more complex decisions from a=20
single server to multiple, more specialized, Request-Routing DNS=20
servers. The most common mechanisms used to insert multiple=20
Request-Routing DNS servers in a single DNS resolution is the=20
use of NS and CNAME records. An example would be the case where=20
a higher level DNS server operates within a territory,=20
directing the DNS lookup to a more specific DNS server within that=20
territory to provide a more accurate resolution.
2.3.1 NS Redirection
A DNS server can use NS records to redirect the authority of the=20
next level domain to another Request-Routing DNS server. The,=20
technique allows multiple DNS server to be involved in the name=20
resolution process. For example, a client site DNS server=20
resolving a.b.c.com would eventually request a resolution of=20
a.b.c.com from the name server authoritative for c.com. The name=20
server authoritative for this domain might be a Request-Routing=20
NS server. In this case the Request-Routing DNS server can either=20
return a set of A records or can redirect the resolution of the=20
request a.b.c.com to the DNS server that is authoritative for=20
.c.com using NS records.
One drawback of using NS records is that the number of=20
Request-Routing DNS servers are limited by the number of parts in=20
Cain, et. al. Expires November 8, 2002 [Page =
4]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
the DNS name. This problem results from DNS policy that causes a=20
client site DNS server to abandon a request if no additional parts=20
of the DNS name are resolved in an exchange with an authoritative=20
DNS server.=20
A second drawback is that the last DNS server can determine the=20
TTL of the entire resolution process. Basically, the last DNS=20
server can return in the authoritative section of its response its=20
own NS record. The client will use this cached NS record for=20
further request resolutions until it expires.
Another drawback is that some implementations of bind voluntarily
cause timeouts to simplify their implementation in cases in which a=20
NS level redirect points to a name server for which no valid A=20
record is returned or cached. This is especially a problem if the=20
domain of the name server does not match the domain currently=20
resolved, since in this case the A records, which might be passed=20
in the DNS response, are discarded for security reasons. Another=20
drawback is the added delay in resolving the request due to the=20
use of multiple DNS servers.
2.3.2 CNAME Redirection
In this scenario, the Request-Routing DNS server returns a CNAME=20
record to direct resolution to an entirely new domain. In=20
principle, the new domain might employ a new set of Request-Routing=20
DNS servers.=20
One disadvantage of this approach is the additional overhead of=20
resolving the new domain name. The main advantage of this approach=20
is that the number of Request-Routing DNS servers is independent=20
of the format of the domain name.=20
2.4 Anycast
Anycast [6] is an inter-network service that is applicable to=20
networking situations where a host, application, or user wishes to=20
locate a host which supports a particular service but, if several=20
servers support the service, does not particularly care which server =
is used. In an anycast service, a host transmits a datagram to an=20
anycast address and the inter-network is responsible for providing=20
best effort delivery of the datagram to at least one, and=20
preferably only one, of the servers that accept datagrams for the=20
anycast address.
The motivation for anycast is that it considerably simplifies the=20
task of finding an appropriate server. For example, users, instead=20
of consulting a list of servers and choosing the closest one, could=20
simply type the name of the server and be connected to the nearest=20
Cain, et. al. Expires November 8, 2002 [Page =
5]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
one. By using anycast, DNS resolvers would no longer have to be=20
configured with the IP addresses of their servers, but rather could=20
send a query to a well-known DNS anycast address. =20
Furthermore, to combine measurement and redirection, the=20
Request-Routing DNS server can advertise an anycast address as its=20
IP address. The same address is used by multiple physical DNS=20
servers. In this scenario, the Request-Routing DNS server that is=20
the closest to the client site DNS server in terms of OSPF and=20
BGP routing will receive the packet containing the DNS resolution=20
request. The server can use this information to make a Request-
Routing decision. Drawbacks of this approach are listed below:
* The DNS server may not be the closest server in terms of=20
routing to the client.
* Typically, routing protocols are not load sensitive. Hence,=20
the closest server may not be the one with the least network
latency.
* The server load is not considered during the Request-
Routing process.
2.5 Object Encoding
Since only DNS names are visible during the DNS Request-Routing,=20
some solutions encode the object type, object hash, or similar=20
information into the DNS name. This might vary from a simple=20
division of objects based on object type (such as images.a.b.c.com=20
and streaming.a.b.c.com) to a sophisticated schema in which the=20
domain name contains a unique identifier (such as a hash) of the=20
object. The obvious advantage is that object information is=20
available at resolution time. The disadvantage is that the client=20
site DNS server has to perform multiple resolutions to retrieve a=20
single Web page, which might increase rather than decrease the=20
overall latency.
2.6 DNS Request-Routing Limitations=20
Some limitations of DNS based Request-Routing techniques are=20
described below:
1. DNS only allows resolution at the domain level. However, an=20
ideal request resolution system should service requests=20
per object level. =20
2. In DNS based Request-Routing systems servers may be required=20
to return DNS entries with a short time-to-live (TTL) values.=20
This may be needed in order to be able to react quickly in the=20
face of outages. This in return may increase the volume of=20
requests to DNS servers.
Cain, et. al. Expires November 8, 2002 [Page =
6]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
3. Some DNS implementations do not always adhere to DNS standards.=20
For example, many DNS implementations do not honor the DNS TTL=20
field.
4. DNS Request-Routing is based only on knowledge of the client
DNS server, as client addresses are not relayed within DNS
requests. This limits the ability of the Request-Routing system=20
to determine a client's proximity to the surrogate.
5. DNS servers can request and allow recursive resolution of DNS
names. For recursive resolution of requests, the Request-
Routing DNS server will not be exposed to the IP address of the=20
client's site DNS server. In this case, the Request-Routing DNS=20
server will be exposed to the address of the DNS server that is=20
recursively requesting the information on behalf of the client's =
site DNS server. For example, imgs.company.com might be resolved =
by a CN, but the request for the resolution might come from=20
dns1.company.com as a result of the recursion.
6. Users that share a single client site DNS server will be=20
redirected to the same set of IP addresses during the TTL=20
interval. This might lead to overloading of the surrogate=20
during a flash crowd.
7. Some implementations of bind can cause DNS timeouts to occur
while handling exceptional situations. For example, timeouts=20
can occur for NS redirections to unknown domains.
3. Transport-Layer Request-Routing
At the transport-layer finer levels of granularity can be achieved=20
by the close inspection of client's requests. In this approach, the
Request-Routing system inspects the information available in the=20
first packet of the client's request to make surrogate selection=20
decisions. The inspection of the client's requests provides data=20
about the client's IP address, port information, and layer 4=20
protocol. The acquired data could be used in combination with=20
user-defined policies and other metrics to determine the selection=20
of a surrogate that is better suited to serve the request. The=20
techniques that are used to hand off the session to a more=20
appropriate surrogate are beyond the scope of this document.=20
In general, the forward-flow traffic (client to newly selected=20
surrogate) will flow through the surrogate originally chosen by DNS. =
The reverse-flow (surrogate to client) traffic, which normally=20
transfers much more data than the forward flow, would typically=20
take the direct path.
Cain, et. al. Expires November 8, 2002 [Page =
7]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
The overhead associated with transport-layer Request-Routing makes=20
it better suited for long-lived sessions such as FTP [1]and RTSP =
[3].=20
However, it also could be used to direct clients away from =
overloaded=20
surrogates.
In general, transport-layer Request-Routing can be combined with=20
DNS based techniques. As stated earlier, DNS based methods resolve=20
clients requests based on domains or sub domains with exposure to=20
the client's DNS server IP address. Hence, the DNS based methods=20
could be used as a first step in deciding on an appropriate=20
surrogate with more accurate refinement made by the=20
transport-layer Request-Routing system.
4. Application-Layer Request-Routing
Application-layer Request-Routing systems perform deeper=20
examination of client's packets beyond the transport layer=20
header. Deeper examination of client's packets provides=20
fine-grained Request-Routing control down to the level of=20
individual objects. The process could be performed in real=20
time at the time of the object request. The exposure to the=20
client's IP address combined with the fine-grained knowledge=20
of the requested objects enable application-layer Request-
Routing systems to provide better control over the selection of=20
the best surrogate.
4.1 Header Inspection
Some application level protocols such as HTTP [4], RTSP [3],=20
and SSL [2] provide hints in the initial portion of the session=20
about how the client request must be directed. These hints may come=20
from the URL of the content or other parts of the MIME request =
header=20
such as Cookies.
4.1.1 URL-Based Request-Routing
Application level protocols such as HTTP and RTSP describe the=20
requested content by its URL [7]. In many cases, this information=20
is sufficient to disambiguate the content and suitably direct the=20
request. In most cases, it may be sufficient to make Request-
Routing decision just by examining the prefix or suffix of the URL.
4.1.1.1 302 Redirection
In this approach, the client's request is first resolved to a=20
virtual surrogate. Consequently, the surrogate returns an=20
application-specific code such as the 302 (in the case of=20
HTTP [4] or RTSP [3]) to redirect the client to the actual=20
delivery node.
Cain, et. al. Expires November 8, 2002 [Page =
8]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
This technique is relatively simple to implement. However, the=20
main drawback of this method is the additional latency involved in=20
sending the redirect message back to the client.
4.1.1.2 In-Path Element
In this technique, an In-Path element is present in the network in=20
the forwarding path of the client's request. The In-Path element=20
provides transparent interception of the transport connection. The=20
In-Path element examines the client's content requests and performs=20
Request-Routing decisions.=20
The In-Path element then splices the client connection to a=20
connection with the appropriate delivery node and passes along the=20
content request. In general, the return path would go through the=20
In-Path element. However, it is possible to arrange for a direct=20
return by passing the address translation information to the=20
surrogate or delivery node through some proprietary means.
The primary disadvantage with this method is the performance=20
implications of URL-parsing in the path of the network traffic.=20
However, it is generally the case that the return traffic is much=20
larger than the forward traffic.
The technique allows for the possibility of partitioning the traffic =
among a set of delivery nodes by content objects identified by URLs. =
This allows object-specific control of server loading. For example,=20
requests for non-cacheable object types may be directed away from a=20
cache.
4.1.2 Mime Header-Based Request-Routing
This technique involves the task of using MIME-headers such as=20
Cookie, Language, and User-Agent, in order to select a surrogate.
=20
Cookies can be used to identify a customer or session by a web site. =
Cookie based Request-Routing provides content service=20
differentiation based on the client. This approach works provided=20
that the cookies belong to the client. In addition, it is possible=20
to direct a connection from a multi-session transaction to be=20
directed to the same server to achieve session-level=20
persistence.=20
The language header can be used to direct traffic to a=20
language-specific delivery node. The user-agent header helps=20
identify the type of client device. For example, a voice-browser,=20
PDA, or cell phone can indicate the type of delivery node that has=20
content specialized to handle the content request.
Cain, et. al. Expires November 8, 2002 [Page =
9]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
4.1.3 Site-Specific Identifiers
Site-specific identifiers help authenticate and identify a session=20
from a specific user. This information may be used to direct a=20
content request.
An example of a site-specific identifier is the SSL Session=20
Identifier. This identifier is generated by a web server and used=20
by the web client in succeeding sessions to identify itself and=20
avoid an entire security authentication exchange. In order to=20
inspect the session identifier, an In-Path element would observe=20
the responses of the web server and determine the session identifier =
which is then used to associate the session to a specific server.=20
The remaining sessions are directed based on the stored=20
session identifier.=20
4.2 Content Modification
This technique enables a content provider to take direct control=20
over Request-Routing decisions without the need for specific=20
witching devices or directory services in the path between the=20
client and the origin server. Basically, a content provider can=20
directly communicate to the client the best surrogate that can=20
serve the request. Decisions about the best surrogate can be made=20
on a per-object basis or it can depend on a set of metrics. The=20
overall goal is to improve scalability and the performance for=20
delivering the modified content, including all embedded objects.
In general, the method takes advantage of content objects that=20
consist of basic structure that includes references to additional,=20
embedded objects. For example, most web pages, consist of an HTML=20
document that contains plain text together with some embedded =
objects,=20
such as GIF or JPEG images. The embedded objects are referenced =
using=20
embedded HTML directives. In general, embedded HTML directives =
direct=20
the client to retrieve the embedded objects from the origin server.=20
A content provider can now modify references to embedded objects=20
such that they could be fetched from the best surrogate. This=20
technique is also known as URL rewriting. The basic types of URL=20
rewriting are discussed in the following subsections.
4.2.1 A-priori URL Rewriting
In this scheme, a content provider rewrites the embedded URLs=20
before the content is positioned on the origin server. In this=20
case, URL rewriting can be done either manually or by using a=20
software tools that parse the content and replace embedded URLs.=20
Cain, et. al. Expires November 8, 2002 [Page =
10]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
A-priori URL rewriting alone does not allow consideration of client=20
specifics for Request-Routing. However, it can be used in=20
combination with DNS Request-Routing to direct related DNS queries=20
into the domain name space of the service provider. Dynamic=20
Request-Routing based on client specifics are then done using=20
the DNS approach.
4.2.2 On-Demand URL Rewriting
On-Demand or dynamic URL rewriting, modifies the content when the=20
client request reaches the origin server. At this time, the=20
identity of the client is known and can be considered when=20
rewriting the embedded URLs. In particular, an automated process=20
can determine, on-demand, which surrogate would serve the=20
requesting client best. The embedded URLs can then be=20
rewritten to direct the client to retrieve the objects from the=20
best surrogate rather than from the origin server.
4.2.3 Content Modification Limitations
Content modification as a Request-Routing mechanism suffers from=20
the following limitations:
1. The first request from a client to a specific site must=20
be served from the origin server.
2. Content that has been modified to include references to=20
nearby surrogates rather than to the origin server should=20
be marked as non-cacheable. Alternatively, such pages can=20
be marked to be cacheable only for a relatively short period =
of time. Rewritten URLs on cached pages can cause problems,=20
because they can get outdated and point to surrogates=20
that are no longer available or no longer good choices.
5. Combination of Multiple Mechanisms
There are environments in which a combination of different=20
mechanisms can be beneficial and advantageous over using one of=20
the proposed mechanisms alone. The following example illustrates=20
how the mechanisms can be used in combination.
A basic problem of DNS Request-Routing is the resolution=20
granularity that allows resolution on a per-domain level only. A=20
per-object redirection cannot easily be achieved. However, content=20
modification can be used together with DNS Request-Routing to=20
overcome this problem. With content modification, references to=20
different objects on the same origin server can be rewritten to=20
point into different domain name spaces. Using DNS Request-Routing,=20
requests for those objects can now dynamically be directed to=20
different surrogates.
Cain, et. al. Expires November 8, 2002 [Page =
11]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
6. Security Considerations
The main objective of this document is to provide a summary of current=20
Request-Routing techniques. Such techniques are currently implemented=20
in the Internet. The document acknowledges that security must be=20
addressed by any entity that implements any technique that redirects=20
client's requests. However, the details of such techniques are beyond=20
the scope of this document.
7. Acknowledgements
The authors acknowledge the contributions and comments of Ian =
Cooper,
Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean =
(CrystalBall).
8. References
[1] Postel, J., "File Transfer Protocol", RFC 765, June 1980,
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC
846, January 1999.
[3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol", RFC 2326, April 1998.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] Day, M., Cain, B. and G. Tomlinson, " A Model for Content=20
Internetworking (CDI)", http://www.ietf.org/internet-drafts/
draft-ietf-cdi-model-02.txt (Group Last Call).=20
[6] Partridge, C., Mendez, T., Milliken W., "Host Anycasting=20
Service", RFC 1546, November 1993.
[7] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource=20
Locators (URL)", RFC 1738,May 1994.
[8] H. Schulzrinne, H., Fokus, G., Casner, S., Frederick, R.,=20
Jacobson, V., "RTP: A Transport Protocol for Real-Time=20
Applications", RFC 1889, January 1996.=20
9. Authors' Addresses
Abbie Barbir
Nortel Networks
3500 Carling Avenue, Nepean Ontario K2H 8E9 Canada
EMail: [email protected]
Cain, et. al. Expires November 8, 2002 [Page =
12]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
Brad Cain
Storigen Systems
650 Suffolk Street
Lowell, MA 01854 US
Phone: +1 978-323-4454
EMail: [email protected]
Fred Douglis
IBM Research=20
EMail: [email protected]=20
Mark Green
CacheFlow
650 Almanor Avenue
Sunnyvale, CA 94085, US
EMail: [email protected]
Markus Hofmann
Lucent Technologies
Room 4F-513
101 Crawfords Corner Rd.
Holmdel, NJ 07733, US
EMail: [email protected]
Raj Nair
Cisco Systems
50 Nagog Park
Acton, MA 01720, US
EMail: [email protected]
Doug Potter
Cisco Systems
50 Nagog Park
Acton, MA 01720, US
EMail: [email protected]
Oliver Spatscheck
AT&T Labs
Room B131
180 Park Ave, Bldg 103
Florham Park, NJ 07932, US
EMail: [email protected]
Cain, et. al. Expires November 8, 2002 [Page =
13]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
Appendix A
Measurements
Request-Routing systems can use a variety of metrics in order=20
to determine the best surrogate that can serve a client's request.
In general, these metrics are based on network measurements and=20
feedback from surrogates. It is possible to combine multiple=20
metrics using both proximity and surrogate feedback for best=20
surrogate selection. The following sections describe several=20
well known metrics as well as the major techniques for obtaining=20
them.
A.1 Proximity Measurements
Proximity measurements can be used by the Request-Routing system to=20
direct users to the "closest" surrogate. In a DNS Request-Routing=20
system, the measurements are made to the client's local DNS server.=20
However, when the IP address of the client is accessible more=20
accurate proximity measurements can be obtained.
Furthermore, proximity measurements can be exchanged between=20
surrogates and the requesting entity. In many cases, proximity=20
measurements are "one-way" in that they measure either the forward=20
or reverse path of packets from the surrogate to the requesting=20
entity. This is important as many paths in the Internet are=20
asymmetric.
In order to obtain a set of proximity measurements, a network=20
may employ active probing techniques and/or passive measurement=20
techniques. The following sections describe these two techniques.
A.1.1 Active Probing
Active probing is when past or possible requesting entities are=20
probed using one or more techniques to determine one or more=20
metrics from each surrogate or set of surrogates. An example of=20
a probing technique is an ICMP ECHO Request that is periodically=20
sent from each surrogate or set of surrogates to a potential=20
requesting entity.=20
In any active probing approach, a list of potential requesting=20
entities need to be obtained. This list can be generated=20
dynamically. Here, as requests arrive, the requesting entity=20
addresses can be cached for later probing. Another potential=20
solution is to use an algorithm to divide address space into blocks=20
and to probe random addresses within those blocks. Limitations
of active probing techniques include:
1. Measurements can only be taken periodically.
2. Firewalls and NATs disallow probes.
Cain, et. al. Expires November 8, 2002 [Page =
14]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
3. Probes often cause security alarms to be triggered on =20
intrusion detection systems.
A.1.2 Passive Measurement
Passive measurements could be obtained when a client performs data=20
transfers to or from a surrogate. Here, a bootstrap mechanism is=20
used to direct the client to a bootstrap surrogate. Once the client=20
connects, the actual performance of the transfer is measured. This=20
data is then fed back into the Request-Routing system.
An example of passive measurement is to watch the packet loss=20
from a client to a surrogate by observing TCP behavior. Latency=20
measurements can also be learned by observing TCP behavior. The=20
limitations of passive measurement approach are directly related=20
to the bootstrapping mechanism. Basically, a good mechanism is=20
needed to ensure that not every surrogate is tested per client=20
in order to obtain the data.
A.1.3 Metric Types
The following sections list some of the metrics, which can be used
for proximity calculations. =20
* Latency: Network latency measurements metrics are used to
determine the surrogate (or set of surrogates) that has the
least delay to the requesting entity. These measurements=20
can be obtained using either an active probing approach or a
passive network measurement system.
* 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.
* Hop Counts: Router hops from the surrogate to the requesting
entity can be used as a proximity measurement.
* BGP Information: BGP AS PATH and MED attributes can be used=20
to determine the "BGP distance" to a given prefix/length=20
pair. In order to use BGP information for proximity=20
measurements, it must be obtained at each surrogate=20
site/location.
Cain, et. al. Expires November 8, 2002 [Page =
15]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
A.2 Surrogate Feedback
The Request-Routing system can use feedback from surrogates in=20
order to select a "least-loaded" delivery node. Feedback can=20
be delivered from each surrogate or can be aggregated by site or=20
by location.=20
A.2.1 Probing
Feedback information may be obtained by periodically probing a=20
surrogate by issuing an HTTP request and observing the behavior.=20
The problems with probing for surrogate information are:
1. It is difficult to obtain "real-time" information.
2. Non-real-time information may be inaccurate.
Consequently, feedback information can be obtained by agents that=20
reside on surrogates that can communicate a variety of metrics about =
=20
their nodes.
A.2.2 Well Known Metrics
The following provides a list of several of the popular metrics
that are used for surrogate feedback:
* Surrogate CPU Load.
* Interface Load / Dropped packets.
* Number of connections being served.
* Storage I/O Load.
Cain, et. al. Expires November 8, 2002 [Page =
16]
Internet-Draft Known CN Request-Routing Mechanisms May 8, =
2002
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Cain, et. al. Expires November 8, 2002 [Page =
17]
------_=_NextPart_000_01C1F69D.D38217C2--