Network Working Group B. Cain Internet-Draft Mirror Image Internet Expires: May 18, 2001 F. Douglis AT&T Labs M. Green Entera M. Hofmann Lucent R. Nair D. Potter Cisco O. Spatscheck AT&T Labs November 17, 2000 Known CDN Request-Routing Mechanisms draft-cain-cdnp-known-request-routing-00.txt 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 May 18, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Discussion List & Archives This document and related documents are discussed on the cdn mailing list. To join the list, send mail to cdn-request@ops.ietf.org. To Cain, et. al. Expires May 18, 2001 [Page 1] Internet-Draft Request-Routing November 2000 contribute to the discussion, send mail to cdn@ops.ietf.org. The archives are at ftp://ops.ietf.org/pub/lists/cdn.*. Cain, et. al. Expires May 18, 2001 [Page 2] Internet-Draft Request-Routing November 2000 Abstract This memo presents a number of known mechanisms used to direct client application requests to surroagte servers based on various policies. In this memo we group mechanisms commonly called content routing or content redirection under the term request-routing. There exist multiple request-routing mechanisms. At a high-level, these may be classified under: DNS request-routing, transport-layer request-routing, and application-layer request-routing. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 2. DNS Request-Routing . . . . . . . . . . . . . . . . . . . 6 2.1 Basic DNS Request-Routing Mechanisms . . . . . . . . . . . 6 2.2 Multiple Replies . . . . . . . . . . . . . . . . . . . . . 6 2.3 Multi-Level Resolution . . . . . . . . . . . . . . . . . . 6 2.4 NS Redirection . . . . . . . . . . . . . . . . . . . . . . 6 2.5 CNAME Redirection . . . . . . . . . . . . . . . . . . . . 7 2.6 Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7 Object Encoding . . . . . . . . . . . . . . . . . . . . . 8 2.8 DNS Request-Routing Problems . . . . . . . . . . . . . . . 8 3. Transport-Layer Request-Routing . . . . . . . . . . . . . 10 4. Application-Layer Request-Routing . . . . . . . . . . . . 11 4.1 Header Inspection . . . . . . . . . . . . . . . . . . . . 11 4.1.1 URL-Based Request-Routing . . . . . . . . . . . . . . . . 11 4.1.1.1 302 Redirection . . . . . . . . . . . . . . . . . . . . . 11 4.1.1.2 In-Path Element . . . . . . . . . . . . . . . . . . . . . 11 4.1.2 Mime Header-Based Request-Routing . . . . . . . . . . . . 12 4.1.3 Site-Specific Identifiers . . . . . . . . . . . . . . . . 12 4.2 Content Modification . . . . . . . . . . . . . . . . . . . 13 4.2.1 Content Modification Overview . . . . . . . . . . . . . . 13 4.2.2 Basic Content Modification Mechanism . . . . . . . . . . . 13 4.2.2.1 A-priori URL Rewriting . . . . . . . . . . . . . . . . . . 13 4.2.2.2 On-Demand URL Rewriting . . . . . . . . . . . . . . . . . 14 4.2.2.3 Content Modification Problems . . . . . . . . . . . . . . 14 5. Combination of Multiple Mechanisms . . . . . . . . . . . . 15 6. Measurements . . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Proximity Measurements . . . . . . . . . . . . . . . . . . 16 6.1.1 Probing . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.2 Passive Measurement . . . . . . . . . . . . . . . . . . . 17 6.1.3 Metric Types . . . . . . . . . . . . . . . . . . . . . . . 17 6.2 Surrogate Feedback . . . . . . . . . . . . . . . . . . . . 18 6.2.1 Probing . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2.2 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2.3 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . 21 Cain, et. al. Expires May 18, 2001 [Page 3] Internet-Draft Request-Routing November 2000 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . 24 Cain, et. al. Expires May 18, 2001 [Page 4] Internet-Draft Request-Routing November 2000 1. Introduction The term "request-routing" is used to convey a more general sense than the word "direction". For example, one type of request-routing is based on what is commonly called the HTTP "redirect" mechanism. However, there are methods that direct requests to SURROGATES without relying on a particular protocol's redirection methods. Hence, the term "request-routing" is used to cover a wider variety of techniques than what might be implied by the term "direction". There exist multiple request-routing mechanisms. At a high-level, these may be classified under: DNS request-routing, transport-layer request-routing, and application-layer request-routing. Cain, et. al. Expires May 18, 2001 [Page 5] Internet-Draft Request-Routing November 2000 2. DNS Request-Routing DNS request-routing is used in many CDNs because of its ubiquity as a directory service. The basic concept of DNS based request-routing is to insert a DNS server in the DNS resolution process. The server returns a different set of IP addresses, or a different ordering of entries in the returned set, depending on various metrics (see Section 6). The overall goal is to improve the performance and scalability of the objects represented by the domain name resolved. 2.1 Basic DNS Request-Routing Mechanisms In its simplest form the request-routing DNS server is authoritative for an entire DNS domain or a subdomain. If a DNS resolution for the domain is requested, the request-routing DNS server will determine the IP address of the best surrogate, in terms of a metric as defined in Section 6. This IP address is returned in an A record to the client site DNS server, and it may actually be a virtual IP (VIP) address of the best set of surrogates for the client site DNS server. 2.2 Multiple Replies To increase the reliability of the solution, the request-routing DNS server can return multiple replies. Common implementations of client site DNS servers use those multiple replies in order while rotating them. Therefore, the order in which the records are returned, as the number of times a particular entry is repeated, can be used to direct multiple clients using a single client site DNS server. 2.3 Multi-Level Resolution To allow for multiple request-routing decisions, multiple request-routing DNS servers can be involved in a single DNS resolution. The rational of utilizing multiple request-routing DNS servers in a single DNS resolution is to allow one to distribute more complex decisions from a single request-routing DNS server to multiple, more specialized, request-routing DNS servers. The most common mechanisms used to insert multiple request-routing DNS servers in a single DNS resolution are the use of NS and CNAME records. 2.4 NS Redirection Using NS records, multiple request-routing DNS servers can be included by redirecting the authority of the next level domain to another request-routing DNS server. For example, the client site DNS server resolving a.b.c.com would eventually request a resolution of a.b.c.com from the name server authoritative for c.com. The Cain, et. al. Expires May 18, 2001 [Page 6] Internet-Draft Request-Routing November 2000 nameserver authoritative for this domain might be a request-routing DNS server. In this case the request-routing DNS server can either return a set of A records or can redirect the resolution of the request a.b.c.com to the DNS server that is authoritative for b.c.com using NS records. One drawback in the use of NS records is that the number of request-routing DNS servers is limited by the number of parts in the DNS name. This problem results from the DNS policy that causes a client site DNS server to abandon a request if no additional parts of the DNS name are resolved in an exchange with an authoritative DNS server. A second drawback is that the last DNS server can determine the TTL of the entire resolution process. The reason is that the last DNS server can return in the authoritative section of its response its own NS record. The TTL for this record is solely determined by the last DNS server. This cached NS record will be used by the client site DNS server for further resolutions until it expires. Another drawback is that some implementations of bind voluntarily cause timeouts (typically 5 seconds) to simplify their implementation in cases in which a NS-level redirect points to a name server for which no valid A record is returned or cached. This is especially a problem if the domain of the name server does not match the domain currently resolved, since in this case the A records which might be passed in the DNS response are discarded for security reasons. Empirical measurements of DNS lookups to sites with NS-level redirection using this type of setup have a high incidence of DNS timeouts. 2.5 CNAME Redirection Multi-level redirection using CNAMEs works similarly to NS records in that a request-routing DNS server returns a CNAME for a domain to direct the further request-routing resolution to an entirely new domain and potentially a new set of request-routing DNS servers. The disadvantage of this approach is mainly the additional overhead of resolving the new domain name. One advantage is that the number of request-routing DNS servers is independent of the depth of the domain name. The number of request-routing DNS servers is only restricted by the resource limits defined on the client site DNS server. Another advantage is the avoidance of some DNS timeouts. 2.6 Anycast To combine measurement and redirection, the request-routing DNS server can advertise an anycast address as its IP address. The same anycast address is used by multiple physical DNS servers. In this Cain, et. al. Expires May 18, 2001 [Page 7] Internet-Draft Request-Routing November 2000 scenario, the request-routing DNS server that is the closest to the client site DNS server in terms of OSPF and BGP routing will receive the packet containing the DNS resolution request. The request-routing DNS server at this point knows that it is the closest (by this metric) and can use this information to make a request-routing decision. Drawbacks of this solution are: * It is not known if the request-routing DNS server is the closest DNS server in terms of routing from the request-routing server to the client. * BGP is not load sensitive. So the closest server in terms of request-routing might not be the server with the least network latency. * The server load is not considered during request-routing. If server load has to be considered while finding the best request-routing server, it has to be folded into the request-routing metrics used by the request-routing protocol. 2.7 Object Encoding Since only DNS names are visible during the DNS request-routing, some solutions encode the object type, object hash or similar information into the DNS name. This might vary from a simple division of objects based on object type (such as images.a.b.c.com and streaming.a.b.c.com) to a sophisticate schema in which the domain name contains a unique identifier (such as a hash) of the object. The obvious advantage is that object information is available during the request-routing process. The disadvantage is that the client site DNS server has to perform multiple DNS resolutions to retrieve a single Web page, which might increase rather than decrease the overall latency. 2.8 DNS Request-Routing Problems The use of DNS as a request-routing mechanism comes with several problems: 1. DNS only allows resolution on a per-domain level, not a per-object level. An ideal request resolution service would service requests with per-object detail. Client-side direction services allow this kind of resolution because of their direct inspection of client requests. 2. DNS systems are typically not designed for very high volumes of requests. This occurs in CDNs that desire near real-time direction of requests to surrogates, because they must return DNS entries with a short time-to-live (TTL) in order to offer Cain, et. al. Expires May 18, 2001 [Page 8] Internet-Draft Request-Routing November 2000 a different response in the face of changing conditions. 3. DNS server and client implementations do not always adhere to the DNS standards and therefore cause problems with DNS request request-routing. For example, many implementations do not honor the DNS TTL field. 4. DNS request-routing is based only on knowledge of the local DNS server, as client addresses are not relayed within DNS requests. DNS request-routing inherently makes use of an assumption that users select a DNS server that is "close" to them. Although this is true in many cases, it is not always valid. This causes problems, especially for proximity-based measurements that are made using an active probing technique. In this case, proximity measurements are made to the user's DNS server. 5. DNS servers can request and allow recursive resolution of DNS names. If recursive resolution is used during the resolution of the DNS request, the request-routing DNS server does not see the IP address of the client site DNS server, but instead sees the address of the DNS server that is recursively requesting the information --- possibly a DNS server operated by the site for which the request-routing DNS server is resolving content. For example, imgs.company.com might be resolved by a CDN, but the request for the resolution might come from dns1.company.com as a result of recursion. 6. When a large number of clients share a single client site DNS server, they will all be redirected to the same set of IP addresses during the TTL interval. This might lead to overload of the surrogate or surrogates behind this IP address if during a flash crowd the number of clients requesting documents from that single IP address exceeds the capacity of the surrogate or surrogates. 7. Some implementations of bind cause DNS timeouts to occur while exceptional situations are handled. These "exceptional" circumstances include NS redirections to unknown domains. Cain, et. al. Expires May 18, 2001 [Page 9] Internet-Draft Request-Routing November 2000 3. Transport-Layer Request-Routing The first stage of CDN selection is typically accomplished using the DNS mechanisms described previously. As described in Section 2, this first level decision must be made based on the information available at the time, specifically the domain name being resolved and the IP address of the client-side DNS server. While this level of information is adequate in many cases, finer levels of granularity can be achieved by inspecting the subsequent request from the client browser to the surrogate chosen by DNS. The simplest of the approaches used today is transport-layer request-routing. Transport-layer request-routing makes use of the information available in the first packet of the client request to make surrogate selection decisions. The specific metrics used are identical to those used at DNS time (see Section 6) but include the client's IP address (rather than the client's DNS server) and the layer 4 protocol and port information carried in that first packet in the decision making process. Handing off the session to a more appropriate surrogate is accomplished in a variety of proprietary means beyond the scope of this document. Typically the forward-flow traffic (client to newly selected surrogate) will flow through the surrogate originally chosen by DNS. The reverse-flow (surrogate to client) traffic, which normally transfers much more data than the forward flow, typically takes the direct path. The overhead associated with transport-layer request-routing makes the most sense for longer-lived flows such as FTP [1] or RTSP [3] or to direct away from overloaded surrogates. Cain, et. al. Expires May 18, 2001 [Page 10] Internet-Draft Request-Routing November 2000 4. Application-Layer Request-Routing Application-layer request-routing involves deeper examining of packets beyond the transport layer header. It works together with DNS request-routing and provides fine-grained request-routing control down to the level of individual objects and can be effected in real time at the time of the object request. As in the case of transport-layer request-routing, the request-routing process is more accurate than in the DNS request-routing case, because it is based on the client's own IP address rather than that of a DNS client site server. 4.1 Header Inspection Applications such as HTTP [4], RTSP [3], SSL [2], etc. provide hints in the initial portion of the session about how the client request must be directed. These hints may come from the URL of the content or other parts of the Mime request header such as Cookies. 4.1.1 URL-Based Request-Routing HTTP and RTSP content requests describe the requested content by its URL. In many cases, this information is sufficient to disambiguate the content and suitably direct the request. In practice, it is often enough to use a sub-string, such as a prefix or suffix, of the URL to make the request-routing decision. 4.1.1.1 302 Redirection In redirection-based request-routing, the client is first resolved to a virtual surrogate which in turn returns an application-specific return code such as the 302 (in the case of HTTP or RTSP) indicating to the client the IP address of the delivery node that is chosen based on suitable metrics as described in Section 6. The advantage of this type of application-aware request-routing is simplicity in implementation. However, the main drawback of this method is the additional latency involved in sending the redirect message back to the client. 4.1.1.2 In-Path Element An In-Path element is a network element in the forwarding path of the client's request. The In-Path element provides transparent interception of the transport connection. This is accomplished by accepting the connection request and establishing sequence numbers via the three-way handshake with the client. This allows the In-Path element to examine the content requests and glean the request header information such as the URL, match it with a URL template, and make Cain, et. al. Expires May 18, 2001 [Page 11] Internet-Draft Request-Routing November 2000 the content request-routing determination. Again, metrics such as those described in Section 6 may be employed. Finally, the In-Path element splices the client connection to a connection with the appropriate delivery node and passes along the content request. The return path would pass through the In-Path element. However, it is possible to arrange for a direct return by passing the address translation information to the surrogate or delivery node through some proprietary means. The primary disadvantage with this method is the performance implications of URL-parsing in the path of the network traffic. However, it is generally the case that the return traffic is much larger than the forward traffic. Traffic may be partitioned and load balanced among a set of delivery nodes by content objects identified by URLs. This allows object-specific control of server loading. For example, requests for non-cacheable objects may be directed away from a cache. 4.1.2 Mime Header-Based Request-Routing This works just like the URL-based request-routing except that other mime-headers in the content request are used to make the content-rule selection. Some useful mime-headers are: Cookie, Language, and User-Agent. Cookies are used to identify a customer or session by a web site. Cookie-based request-routing provides content service differentiation based on the client. In addition, it is possible to direct a connection from a multi-session transaction to be directed to the same server to achieve session-level persistence. Note that client IP address is by itself not a reliable indicator of a session due to the presence of proxies that aggregate multiple clients at a single point. The language header can be used to direct traffic to a language-specific delivery node. The user-agent header helps identify the type of client device. For example, a voice-browser, PDA, or cell phone can indicate the type of delivery node that has content specialized to handle the content request. 4.1.3 Site-Specific Identifiers Site-specific identifiers help authenticate and identify a session from a specific user. This information may be used to direct a content request. Cain, et. al. Expires May 18, 2001 [Page 12] Internet-Draft Request-Routing November 2000 One example of a site-specific identifier is the SSL Session Identifier. This identifier is generated by a web server and used by the web client in succeeding sessions to identify itself and avoid an entire security authentication exchange. In order to inspect the session identifier, an In-Path element. would observe the responses of the web server and determine the session identifier which is then used to associate the session to a specific server. The remaining sessions are directed based on the stored session identifier. Note that SSL Session Identifiers cannot be observed by the redirect method. 4.2 Content Modification 4.2.1 Content Modification Overview Content modification enables a content provider to take direct control over request-routing without the need for specific switching devices or directory services sitting in-between the client and the origin server. By modifying the content according to the client's specifics, a content provider can directly communicate to the client which surrogate can serve it best. Decisions about the best surrogate can be made on a per-object basis and can depend on various metrics (see Section 6). The overall goal is to improve scalability and the performance for delivering the modified content, including all embedded objects. 4.2.2 Basic Content Modification Mechanism Typically, content objects are made up a basic structure that includes references to additional, embedded content objects. Most web pages, for example, consist of an HTML document that contains plain text together with some embedded objects, such as GIF or JPEG images. The embedded objects are referenced using embedded HTML directives. A similar scheme is used for streaming content, which is typically embedded within a SMIL document. Traditionally, embedded HTML or SMIL directives tell the client to fetch embedded objects from the origin server. A content provider can now modify references to embedded objects so that the client is told to fetch an embedded object from the best surrogate (instead of from the origin server). This type of content modification is also referred to as URL Rewriting. It can be done a-priori in a static way, or more dynamically on-demand. The following subsections explore both alternatives. 4.2.2.1 A-priori URL Rewriting A content provider can modify its content and rewrite embedded URLs a-priori, i.e. before the content is put on the origin server and made available to clients. In this case, rewriting can be done Cain, et. al. Expires May 18, 2001 [Page 13] Internet-Draft Request-Routing November 2000 either manually or by using a software tool that parses the content and replaces embedded URLs. A-priori URL rewriting alone does not allow consideration of client specifics for request-routing. It can be used in combination with DNS request-routing, however, to direct related DNS queries into the domain name space of the service provider (see Section 6.1). Dynamic request-routing based on client specifics is then done using the DNS approach. 4.2.2.2 On-Demand URL Rewriting With dynamic URL rewriting, the content is modified when the client request reaches the origin server. At this time, the identity of the client is known and can be considered when rewriting embedded URLs. In particular, an automated process can determine, on-demand, which surrogate would serve the requesting client best. (For a discussion on which metrics can be used and how to get proximity measures, see Section 6.1.) Embedded URLs can then be rewritten so that the client is told to fetch referenced object from the best surrogate rather than from the origin server. 4.2.2.3 Content Modification Problems The use of content modification as a request-routing mechanism comes with several drawbacks: 1. The first request from a client to a specific site always has to be served from the origin server. 2. Content that has been modified to include references to nearby surrogates rather than to the origin server should be marked as non-cacheable and should not be cached. Alternatively, such pages can be marked to be cacheable only for a relative short period of time. Rewritten URLs on cached pages can cause problems, because they can be outdated and point to surrogates that are no longer available or no longer good choices. 3. On-demand URL rewriting (including content parsing, information retrieval, and URL rewriting) has to be done in real-time, which poses the question of performance and processing capabilities. Cain, et. al. Expires May 18, 2001 [Page 14] Internet-Draft Request-Routing November 2000 5. Combination of Multiple Mechanisms There are environments in which a combination of different mechanisms can be beneficial and advantageous over using one of the proposed mechanisms alone. The following example illustrates how the mechanisms can be used in combination. A basic problem of DNS request-routing is the resolution granularity that allows resolution on a per-domain level only. A per-object redirection cannot easily be achieved. However, content modification can be used together with DNS request-routing to overcome this problem. With content modification, references to different objects on the same origin server can be rewritten to point into different domain name spaces. Using DNS request-routing, requests for those objects can now dynamically be directed to different surrogates. Cain, et. al. Expires May 18, 2001 [Page 15] Internet-Draft Request-Routing November 2000 6. Measurements CDNs' Request-routing systems make use of a variety of metrics for the decision of which surrogate to select for a user request. These metrics are based on both network measurements and feedback from surrogates. It is common practice to combine multiple metrics using both proximity and surrogate feedback for best surrogate selection. There are infinite possibilities for metrics as well as metric combinations; the following sections describe several well-known metrics as well as the two major techniques for obtaining metrics. 6.1 Proximity Measurements Some CDN request-routing Systems make use of "proximity" measurements to direct users to the "closest" surrogate. If a DNS system is used for request-routing, then these measurements are made to the client's local DNS server; this heuristic is not always accurate. In a client-side direction model, the IP address of the client is directly exposed and therefore more accurate proximity measurements can be obtained. Proximity measurements are used between the CDN surrogate set and the requesting entity. In many cases, proximity measurements are "one-way" in that they measure only either the forward or reverse path of packets from the surrogate to the requesting entity. This is important as many paths in the Internet are asymmetric. In order to obtain a set of proximity measurements, a CDN may employ active probing techniques and/or passive measurement techniques. The following sections describe these two techniques. 6.1.1 Probing In order to obtain a set of proximity measurements, a CDN may employ an active probing technique. Active probing is when past or possible requesting entities are probed using one or more techniques to determine one or more metrics from each surrogate (or set). An example of a probing technique would be an ICMP ECHO Request periodically sent from each surrogate (or set) to a potential requesting entity. The problems with an active probing approach are: 1. Measurements can only be taken periodically. 2. Firewalls and NATs disallow probes. Cain, et. al. Expires May 18, 2001 [Page 16] Internet-Draft Request-Routing November 2000 3. Probes often cause security alarms to be triggered on intrusion detection systems. In any active probing approach, a list of potential requesting entities needs to be obtained. This list can be generated dynamically: as requests arrive, the requesting entity addresses can be cached for later probing. Another potential solution is to use an algorithm to divide address space into blocks and to probe those blocks. 6.1.2 Passive Measurement The other measurement technique makes use of passive measurements which are obtained when a client actually transfers data to/from a surrogate. In this technique, a bootstrap mechanism is used to direct the client to a bootstrap surrogate. Once the client connects, the actual performance of the transfer is measured. This data is then fed back into the request-routing system. An example of passive measurement is to watch the packet loss from a client to a surrogate by observing TCP behavior. Latency measurements can also be learned by observing TCP behavior (as TCP's congestion control is partly based on RTT). The problems with a passive measurement approach are mostly related to the bootstrapping mechanism. A good mechanism is needed to that every surrogate doesn't need to be "tested" per client to obtain the measurement information. 6.1.3 Metric Types The following sections list some of the metrics which can be used for proximity calculations. This list is not meant to be exhaustive. * 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 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. Cain, et. al. Expires May 18, 2001 [Page 17] Internet-Draft Request-Routing November 2000 * BGP Information: BGP AS PATH and MED attributes can be used to determine the "BGP distance" to a given prefix/length pair. In order to use BGP information for proximity measurements, it must be obtained at each surrogate site/location. 6.2 Surrogate Feedback Some CDN request-routing mechanisms make use of surrogate feedback information in order to select a "least-loaded" surrogate. Feedback can be delivered from each surrogate or can be aggregated by site or by location. This feedback information is fed into the request-routing system. CDNs often make use of both proximity and surrogate feedback to make decisions. Examples of surrogate feedback metrics include: CPU load, interface load, interface dropped packets, number of connections, etc. 6.2.1 Probing Feedback information may be obtained by periodically probing a surrogate for example by issuing a HTTP request and observing the behavior. 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. 6.2.2 Monitoring Feedback information may also be obtained by agents that reside on surrogates. These agents can communicate a variety of metrics about the surrogates. 6.2.3 Metrics The following quickly summarizes several of the well known metrics which 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 May 18, 2001 [Page 18] Internet-Draft Request-Routing November 2000 7. Security Considerations This is a preliminary draft for discussion purposes only submitted prior to the formation of the working group. As such, security considerations have been mostly deferred until after the working group is constituted. [This document is not expected to be a formal submission of the working group in its current form.] This document in particular is a summary of mechanisms documented elsewhere. Please consult the referenced documents for any mechanism specific security considerations. Cain, et. al. Expires May 18, 2001 [Page 19] Internet-Draft Request-Routing November 2000 8. Acknowledgements [Reviewers go here] Cain, et. al. Expires May 18, 2001 [Page 20] Internet-Draft Request-Routing November 2000 References [1] Postel, J., "File Transfer Protocol", RFC 765, June 1980, . [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC 2246, 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 CDN Peering", draft-day-cdnp-model-02.txt (work in progress), October 2000, . Authors' Addresses Brad Cain Mirror Image Internet 49 Dragon Court Woburn, MA 01801 US Phone: +1 781 276 1904 EMail: brad.cain@mirror-image.com Fred Douglis AT&T Labs Room B137 180 Park Ave, Bldg 103 Florham Park, NJ 07932 US Phone: +1 973 360 8775 EMail: douglis@research.att.com Cain, et. al. Expires May 18, 2001 [Page 21] Internet-Draft Request-Routing November 2000 Mark Green Entera, Inc. 40971 Encyclopedia Circle Fremont, CA 94538 US Phone: +1 510 770 5268 EMail: markg@entera.com Markus Hofmann Lucent Technologies Room 4F-513 101 Crawfords Corner Rd. Holmdel, NJ 07733 US Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com Raj Nair Cisco Systems 50 Nagog Park Acton, MA 01720 US Phone: +1 978 206 3029 EMail: rnair@cisco.com Doug Potter Cisco Systems 50 Nagog Park Acton, MA 01720 US Phone: +1 978 206 ???? EMail: dougpott@cisco.com Cain, et. al. Expires May 18, 2001 [Page 22] Internet-Draft Request-Routing November 2000 Oliver Spatscheck AT&T Labs Room B131 180 Park Ave, Bldg 103 Florham Park, NJ 07932 US Phone: +1 973 360 ???? EMail: spatsch@research.att.com Cain, et. al. Expires May 18, 2001 [Page 23] Internet-Draft Request-Routing November 2000 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Cain, et. al. Expires May 18, 2001 [Page 24]