idnits 2.17.1 draft-ietf-cdi-known-request-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([4], [5], [8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 140 has weird spacing: '... be used by...' == Line 246 has weird spacing: '... server and b...' == Line 348 has weird spacing: '... suited for l...' == Line 395 has weird spacing: '...quested conte...' == Line 535 has weird spacing: '...oint to surro...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2002) is 8091 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 765 (ref. '1') (Obsoleted by RFC 959) ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2326 (ref. '3') (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Normative reference to a draft: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. '6') ** Obsolete normative reference: RFC 1738 (ref. '7') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1889 (ref. '8') (Obsoleted by RFC 3550) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Barbir 2 Internet-Draft Nortel Networks 3 Expires: August 22, 2002 B. Cain 4 Cereva Networks 5 F. Douglis 6 AT&T Labs 7 M. Green 8 CacheFlow 9 M. Hofmann 10 Lucent 11 R. Nair 12 D. Potter 13 Cisco 14 O. Spatscheck 15 AT&T Labs 17 February 22, 2002 19 Known CN Request-Routing Mechanisms 20 draft-ietf-cdi-known-request-routing-00.txt 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 22, 2002. 45 Copyright Notice 47 Copyright (C) The Internet Society (2000). All Rights Reserved. 49 Abstract 51 The work presents a summary of Request-Routing techniques that are 52 used to direct client requests to surrogates based on various 53 policies and a possible set of metrics. In this memo the term 54 Request-Routing represents techniques that are commonly called 55 content routing or content redirection. In principle, 56 Request-Routing techniques can be classified under: DNS 57 Request-Routing, Transport-layer Request-Routing, and 58 Application-layer Request-Routing. 60 Table of Content 62 1. Introduction ................................................2 63 2. DNS based Request-Routing Mechanisms ........................3 64 2.1 Single Reply ................................................4 65 2.2 Multiple Replies ............................................4 66 2.3 Multi-Level Resolution ......................................4 67 2.3.1 NS Redirection ..............................................4 68 2.3.2 CNAME Redirection ...........................................5 69 2.4 Anycast .....................................................5 70 2.5 Object Encoding .............................................6 71 2.6 DNS Request-Routing Limitations .............................6 72 3. Transport-Layer Request-Routing .............................7 73 4. Application-Layer Request-Routing ...........................8 74 4.1 Header Inspection ...........................................8 75 4.1.1 URL-Based Request-Routing ...................................8 76 4.1.1.1 302 Redirection .............................................9 77 4.1.1.2 In-Path Element .............................................9 78 4.1.2 Mime Header-Based Request-Routing ...........................9 79 4.1.3 Site-Specific Identifiers ...................................10 80 4.2 Content Modification ........................................10 81 4.2.1 A-priori URL Rewriting ......................................10 82 4.2.2 On-Demand URL Rewriting .....................................11 83 4.2.3 Content Modification Limitations ............................11 84 5. Combination of Multiple Mechanisms ..........................11 85 6. Security Considerations .....................................12 86 7. Acknowledgements ............................................12 87 8. References ..................................................12 88 9. Authors' Addresses ..........................................12 89 Appendix A ..................................................14 90 A.1 Proximity Measurements ......................................14 91 A.1.1 Active Probing ..............................................14 92 A.1.2 Passive Measurement .........................................15 93 A.1.3 Metric Types ................................................15 94 A.2 Surrogate Feedback ..........................................16 95 A.2.1 Probing .....................................................16 96 A.2.2 Well Known Metrics ..........................................16 97 1. Introduction 99 The document provides a summary of current known techniques that 100 could be used to direct client requests to surrogates based on 101 various policies and a possible set of metrics. The task of 102 directing clients' requests to surrogates is also called 103 Request-Routing, Content Routing or Content Redirection. 105 Request-Routing techniques are commonly used in Content Networks 106 (also known as Content Delivery Networks)[5]. Content Networks 107 include network infrastructure that exists in layers 4 through 7. 108 Content Networks deal with the routing and forwarding of requests 109 and responses for content. Content Networks rely on layer 7 110 protocols such as HTTP [4] OR RTP [8] for transport. 112 Request-Routing techniques are generally used to direct client 113 requests for objects to a surrogate or a set of surrogates that 114 could best serve that content. Request-Routing mechanisms could 115 be used to direct client requests to surrogates that are within a 116 Content Network (CN) [5]. 118 Request-Routing techniques are used as a vehicle to extend the 119 reach and scale of Content Delivery Networks. There exist multiple 120 Request-Routing mechanisms. At a high-level, these may be classified 121 under: DNS Request-Routing, transport-layer Request-Routing, and 122 application-layer Request-Routing. 124 A request routing system uses a set of metrics in an attempt to 125 direct users to surrogate that can best serve the request. For 126 example, the choice of the surrogate could be based on network 127 proximity, bandwidth availability, surrogate load and availability 128 of content. Appendix A provides a summary of metrics and 129 measurement techniques that could be used in the selection of 130 the best surrogate. 132 The memo is organized as follows: Section 2 provides a summary of 133 known DNS based Request-Routing techniques. Section 3 discusses 134 transport-layer Request-Routing methods. In section 4 135 application-layer Request-Routing mechanisms are explored. Section 136 5 provides insight on combining the various methods that were 137 discussed in the earlier sections in order to optimize the 138 performance of the Request-Routing System. Appendix A provides 139 a summary of possible metrics and measurements techniques that could 140 be used by the Request-Routing system to choose a given surrogate. 142 2. DNS based Request-Routing Mechanisms 144 DNS based Request-Routing techniques are common due to the ubiquity 145 of DNS as a directory service. In DNS based Request-Routing 146 techniques, a specialized DNS server is inserted in the DNS 147 resolution process. The server is capable of returning a different 148 set of A, NS or CNAME records based on user defined policies, 149 metrics, or a combination of both. 151 2.1 Single Reply 153 In this approach, the DNS server is authoritative for the entire 154 DNS domain or a sub domain. The DNS server returns the IP address 155 of the best surrogate in an A record to the requesting DNS server. 156 The IP address of the surrogate could also be a virtual IP(VIP) 157 address of the best set of surrogates for requesting DNS server. 159 2.2 Multiple Replies 161 In this approach, the Request-Routing DNS server returns multiple 162 replies such as several A records for various surrogates. Common 163 implementations of client site DNS server's cycles through the 164 multiple replies in a Round-Robin fashion. The order in which the 165 records are returned can be used to direct multiple clients using 166 a single client site DNS server. 168 2.3 Multi-Level Resolution 170 In this approach multiple Request-Routing DNS servers can be 171 involved in a single DNS resolution. The rationale of utilizing 172 multiple Request-Routing DNS servers in a single DNS resolution 173 is to allow one to distribute more complex decisions from a 174 single server to multiple, more specialized, Request-Routing DNS 175 servers. The most common mechanisms used to insert multiple 176 Request-Routing DNS servers in a single DNS resolution is the 177 use of NS and CNAME records. An example would be the case where 178 a higher level DNS server operates within a territory, 179 directing the DNS lookup to a more specific DNS server within that 180 territory to provide a more accurate resolution. 182 2.3.1 NS Redirection 184 A DNS server can use NS records to redirect the authority of the 185 next level domain to another Request-Routing DNS server. The, 186 technique allows multiple DNS server to be involved in the name 187 resolution process. For example, a client site DNS server 188 resolving a.b.c.com would eventually request a resolution of 189 a.b.c.com from the name server authoritative for c.com. The name 190 server authoritative for this domain might be a Request-Routing 191 NS server. In this case the Request-Routing DNS server can either 192 return a set of A records or can redirect the resolution of the 193 request a.b.c.com to the DNS server that is authoritative for 194 .c.com using NS records. 196 One drawback of using NS records is that the number of 197 Request-Routing DNS servers are limited by the number of parts in 198 the DNS name. This problem results from DNS policy that causes a 199 client site DNS server to abandon a request if no additional parts 200 of the DNS name are resolved in an exchange with an authoritative 201 DNS server. 203 A second drawback is that the last DNS server can determine the 204 TTL of the entire resolution process. Basically, the last DNS 205 server can return in the authoritative section of its response its 206 own NS record. The client will use this cached NS record for 207 further request resolutions until it expires. 209 Another drawback is that some implementations of bind voluntarily 210 cause timeouts to simplify their implementation in cases in which a 211 NS level redirect points to a name server for which no valid A 212 record is returned or cached. This is especially a problem if the 213 domain of the name server does not match the domain currently 214 resolved, since in this case the A records, which might be passed 215 in the DNS response, are discarded for security reasons. Another 216 drawback is the added delay in resolving the request due to the 217 use of multiple DNS servers. 219 2.3.2 CNAME Redirection 221 In this scenario, the Request-Routing DNS server returns a CNAME 222 record to direct resolution to an entirely new domain. In 223 principle, the new domain might employ a new set of Request-Routing 224 DNS servers. 226 One disadvantage of this approach is the additional overhead of 227 resolving the new domain name. The main advantage of this approach 228 is that the number of Request-Routing DNS servers is independent 229 of the format of the domain name. 231 2.4 Anycast 233 Anycast [6] is an inter-network service that is applicable to 234 networking situations where a host, application, or user wishes to 235 locate a host which supports a particular service but, if several 236 servers support the service, does not particularly care which server 237 is used. In an anycast service, a host transmits a datagram to an 238 anycast address and the inter-network is responsible for providing 239 best effort delivery of the datagram to at least one, and 240 preferably only one, of the servers that accept datagrams for the 241 anycast address. 243 The motivation for anycast is that it considerably simplifies the 244 task of finding an appropriate server. For example, users, instead 245 of consulting a list of servers and choosing the closest one, could 246 simply type the name of the server and be connected to the nearest 247 one. By using anycast, DNS resolvers would no longer have to be 248 configured with the IP addresses of their servers, but rather could 249 send a query to a well-known DNS anycast address. 251 Furthermore, to combine measurement and redirection, the 252 Request-Routing DNS server can advertise an anycast address as its 253 IP address. The same address is used by multiple physical DNS 254 servers. In this scenario, the Request-Routing DNS server that is 255 the closest to the client site DNS server in terms of OSPF and 256 BGP routing will receive the packet containing the DNS resolution 257 request. The server can use this information to make a Request- 258 Routing decision. Drawbacks of this approach are listed below: 260 * The DNS server may not be the closest server in terms of 261 routing to the client. 263 * Typically, routing protocols are not load sensitive. Hence, 264 the closest server may not be the one with the least network 265 latency. 267 * The server load is not considered during the Request- 268 Routing process. 270 2.5 Object Encoding 272 Since only DNS names are visible during the DNS Request-Routing, 273 some solutions encode the object type, object hash, or similar 274 information into the DNS name. This might vary from a simple 275 division of objects based on object type (such as images.a.b.c.com 276 and streaming.a.b.c.com) to a sophisticated schema in which the 277 domain name contains a unique identifier (such as a hash) of the 278 object. The obvious advantage is that object information is 279 available at resolution time. The disadvantage is that the client 280 site DNS server has to perform multiple resolutions to retrieve a 281 single Web page, which might increase rather than decrease the 282 overall latency. 284 2.6 DNS Request-Routing Limitations 286 Some limitations of DNS based Request-Routing techniques are 287 described below: 289 1. DNS only allows resolution at the domain level. However, an 290 ideal request resolution system should service requests 291 per object level. 293 2. In DNS based Request-Routing systems servers may be required 294 to return DNS entries with a short time-to-live (TTL) values. 295 This may be needed in order to be able to react quickly in the 296 face of outages. This in return may increase the volume of 297 requests to DNS servers. 299 3. Some DNS implementations do not always adhere to DNS standards. 300 For example, many DNS implementations do not honor the DNS TTL 301 field. 303 4. DNS Request-Routing is based only on knowledge of the client 304 DNS server, as client addresses are not relayed within DNS 305 requests. This limits the ability of the Request-Routing system 306 to determine a client's proximity to the surrogate. 308 5. DNS servers can request and allow recursive resolution of DNS 309 names. For recursive resolution of requests, the Request- 310 Routing DNS server will not be exposed to the IP address of the 311 client's site DNS server. In this case, the Request-Routing DNS 312 server will be exposed to the address of the DNS server that is 313 recursively requesting the information on behalf of the client's 314 site DNS server. For example, imgs.company.com might be resolved 315 by a CN, but the request for the resolution might come from 316 dns1.company.com as a result of the recursion. 318 6. Users that share a single client site DNS server will be 319 redirected to the same set of IP addresses during the TTL 320 interval. This might lead to overloading of the surrogate 321 during a flash crowd. 323 7. Some implementations of bind can cause DNS timeouts to occur 324 while handling exceptional situations. For example, timeouts 325 can occur for NS redirections to unknown domains. 327 3. Transport-Layer Request-Routing 329 At the transport-layer finer levels of granularity can be achieved 330 by the close inspection of client's requests. In this approach, the 331 Request-Routing system inspects the information available in the 332 first packet of the client's request to make surrogate selection 333 decisions. The inspection of the client's requests provides data 334 about the client's IP address, port information, and layer 4 335 protocol. The acquired data could be used in combination with 336 user-defined policies and other metrics to determine the selection 337 of a surrogate that is better suited to serve the request. The 338 techniques that are used to hand off the session to a more 339 appropriate surrogate are beyond the scope of this document. 341 In general, the forward-flow traffic (client to newly selected 342 surrogate) will flow through the surrogate originally chosen by DNS. 343 The reverse-flow (surrogate to client) traffic, which normally 344 transfers much more data than the forward flow, would typically 345 take the direct path. 347 The overhead associated with transport-layer Request-Routing makes 348 it better suited for long-lived sessions such as FTP [1]and RTSP [3]. 349 However, it also could be used to direct clients away from overloaded 350 surrogates. 352 In general, transport-layer Request-Routing can be combined with 353 DNS based techniques. As stated earlier, DNS based methods resolve 354 clients requests based on domains or sub domains with exposure to 355 the client's DNS server IP address. Hence, the DNS based methods 356 could be used as a first step in deciding on an appropriate 357 surrogate with more accurate refinement made by the 358 transport-layer Request-Routing system. 360 4. Application-Layer Request-Routing 362 Application-layer Request-Routing systems perform deeper 363 examination of client's packets beyond the transport layer 364 header. Deeper examination of client's packets provides 365 fine-grained Request-Routing control down to the level of 366 individual objects. The process could be performed in real 367 time at the time of the object request. The exposure to the 368 client's IP address combined with the fine-grained knowledge 369 of the requested objects enable application-layer Request- 370 Routing systems to provide better control over the selection of 371 the best surrogate. 373 4.1 Header Inspection 375 Applications such as HTTP [4], RTSP [3], and SSL [2] provide hints 376 in the initial portion of the session about how the client request 377 must be directed. These hints may come from the URL of the content 378 or other parts of the MIME request header such as Cookies. 380 4.1.1 URL-Based Request-Routing 382 A Uniform Resource Locator (URL) [7] consists of a naming scheme 383 followed by a string whose format is a function of the naming 384 scheme. The string must start with a constant prefix "URL:". 385 Within the URL of a object, the first element is the name of the 386 scheme, separated from the rest of the object by a colon. The rest 387 of the URL follows the colon in a format depending on the scheme. 388 For example, an FTP URL may optionally specify the FTP data transfer 389 type by which an object is to be retrieved. Most of the methods 390 correspond to the FTP Data Types such as ASCII and IMAGE for the 391 retrieval of a document, as specified in FTP by the "TYPE" Command. 392 The data type is specified by a suffix to the URL. 394 In a similar fashion, HTTP and RTSP content requests describe the 395 requested content by its URL. In many cases, this information 396 is sufficient to disambiguate the content and suitably direct the 397 request. In most cases, it may be sufficient to make Request- 398 Routing decision just by examining the prefix or suffix of the URL. 400 4.1.1.1 302 Redirection 402 In this approach, the client's request is first resolved to a 403 virtual surrogate. Consequently, the surrogate returns an 404 application-specific code such as the 302 (in the case of 405 HTTP [4] or RTSP [3]) to redirect the client to the actual 406 delivery node. 408 This technique is relatively simple to implement. However, the 409 main drawback of this method is the additional latency involved in 410 sending the redirect message back to the client. 412 4.1.1.2 In-Path Element 414 In this technique, an In-Path element is present in the network in 415 the forwarding path of the client's request. The In-Path element 416 provides transparent interception of the transport connection. The 417 In-Path element examines the client's content requests and performs 418 Request-Routing decisions. 420 The In-Path element then splices the client connection to a 421 connection with the appropriate delivery node and passes along the 422 content request. In general, the return path would go through the 423 In-Path element. However, it is possible to arrange for a direct 424 return by passing the address translation information to the 425 surrogate or delivery node through some proprietary means. 427 The primary disadvantage with this method is the performance 428 implications of URL-parsing in the path of the network traffic. 429 However, it is generally the case that the return traffic is much 430 larger than the forward traffic. 432 The technique allows for the possibility of portioning the traffic 433 among a set of delivery nodes by content objects identified by URLs. 434 This allows object-specific control of server loading. For example, 435 requests for non-cacheable object types may be directed away from a 436 cache. 438 4.1.2 Mime Header-Based Request-Routing 440 This technique involves the task of using MIME-headers such as 441 Cookie, Language, and User-Agent, in order to select a surrogate. 443 Cookies can be used to identify a customer or session by a web site. 444 Cookie based Request-Routing provides content service 445 differentiation based on the client. This approach works provided 446 that the cookies belong to the client. In addition, it is possible 447 to direct a connection from a multi-session transaction to be 448 directed to the same server to achieve session-level 449 persistence. 451 The language header can be used to direct traffic to a 452 language-specific delivery node. The user-agent header helps 453 identify the type of client device. For example, a voice-browser, 454 PDA, or cell phone can indicate the type of delivery node that has 455 content specialized to handle the content request. 457 4.1.3 Site-Specific Identifiers 459 Site-specific identifiers help authenticate and identify a session 460 from a specific user. This information may be used to direct a 461 content request. 463 An example of a site-specific identifier is the SSL Session 464 Identifier. This identifier is generated by a web server and used 465 by the web client in succeeding sessions to identify itself and 466 avoid an entire security authentication exchange. In order to 467 inspect the session identifier, an In-Path element would observe 468 the responses of the web server and determine the session identifier 469 which is then used to associate the session to a specific server. 470 The remaining sessions are directed based on the stored 471 session identifier. 473 4.2 Content Modification 475 This technique enables a content provider to take direct control 476 over Request-Routing decisions without the need for specific 477 witching devices or directory services in the path between the 478 client and the origin server. Basically, a content provider can 479 directly communicate to the client the best surrogate that can 480 serve the request. Decisions about the best surrogate can be made 481 on a per-object basis or it can depend on a set of metrics. The 482 overall goal is to improve scalability and the performance for 483 delivering the modified content, including all embedded objects. 485 In general, the method takes advantage of content objects that 486 consist of basic structure that includes references to additional, 487 embedded objects. For example, most web pages, consist of an HTML 488 document that contains plain text together with some embedded objects, 489 such as GIF or JPEG images. The embedded objects are referenced using 490 embedded HTML directives. In general, embedded HTML directives direct 491 the client to retrieve the embedded objects from the origin server. 492 A content provider can now modify references to embedded objects 493 such that they could be fetched from the best surrogate. This 494 technique is also known as URL rewriting. The basic types of URL 495 rewriting are discussed in the following subsections. 497 4.2.1 A-priori URL Rewriting 499 In this scheme, a content provider rewrites the embedded URLs 500 before the content is positioned on the origin server. In this 501 case, URL rewriting can be done either manually or by using a 502 software tools that parse the content and replace embedded URLs. 504 A-priori URL rewriting alone does not allow consideration of client 505 specifics for Request-Routing. However, it can be used in 506 combination with DNS Request-Routing to direct related DNS queries 507 into the domain name space of the service provider. Dynamic 508 Request-Routing based on client specifics are then done using 509 the DNS approach. 511 4.2.2 On-Demand URL Rewriting 513 On-Demand or dynamic URL rewriting, modifies the content when the 514 client request reaches the origin server. At this time, the 515 identity of the client is known and can be considered when 516 rewriting the embedded URLs. In particular, an automated process 517 can determine, on-demand, which surrogate would serve the 518 requesting client best. The embedded URLs can then be 519 rewritten to direct the client to retrieve the objects from the 520 best surrogate rather than from the origin server. 522 4.2.3 Content Modification Limitations 524 Content modification as a Request-Routing mechanism suffers from 525 the following limitations: 527 1. The first request from a client to a specific site must 528 be served from the origin server. 530 2. Content that has been modified to include references to 531 nearby surrogates rather than to the origin server should 532 be marked as non-cacheable. Alternatively, such pages can 533 be marked to be cacheable only for a relatively short period 534 of time. Rewritten URLs on cached pages can cause problems, 535 because they can get outdated and point to surrogates 536 that are no longer available or no longer good choices. 538 5. Combination of Multiple Mechanisms 540 There are environments in which a combination of different 541 mechanisms can be beneficial and advantageous over using one of 542 the proposed mechanisms alone. The following example illustrates 543 how the mechanisms can be used in combination. 545 A basic problem of DNS Request-Routing is the resolution 546 granularity that allows resolution on a per-domain level only. A 547 per-object redirection cannot easily be achieved. However, content 548 modification can be used together with DNS Request-Routing to 549 overcome this problem. With content modification, references to 550 different objects on the same origin server can be rewritten to 551 point into different domain name spaces. Using DNS Request-Routing, 552 requests for those objects can now dynamically be directed to 553 different surrogates. 555 6. Security Considerations 557 The main objective of this document is to provide a summary of current 558 Request-Routing techniques. Such techniques are currently implemented 559 in the Internet. The document acknowledges that security must be 560 addressed by any entity that implements any technique that redirects 561 client's requests. However, the details of such techniques are beyond 562 the scope of this document. 564 7. Acknowledgements 566 The authors acknowledge the contributions and comments of Ian Cooper 567 (Equinix), Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean 568 (CrystalBall). 570 8. References 572 [1] Postel, J., "File Transfer Protocol", RFC 765, June 1980, 574 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC 575 2246, January 1999. 577 [3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 578 Protocol", RFC 2326, April 1998. 580 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 581 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 582 HTTP/1.1", RFC 2616, June 1999. 584 [5] Day, M., Cain, B. and G. Tomlinson, " A Model for Content 585 Internetworking (CDI)", http://www.ietf.org/internet-drafts/ 586 draft-day-cdnp-model-09.txt (Group Last Call). 588 [6] Partridge, C., Mendez, T., Milliken W., "Host Anycasting 589 Service", RFC 1546, November 1993. 591 [7] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource 592 Locator (URL), RFC 1738,May 1994. 594 [8] H. Schulzrinne, H., Fokus, G., Casner, S., Frederick, R., 595 Jacobson, V., "RTP: A Transport Protocol for Real-Time 596 Applications", RFC 1889, January 1996. 598 9. Authors' Addresses 600 Abbie Barbir 601 Nortel Networks 602 3500 Carling Avenue, Nepean Ontario K2H 8E9 Canada 603 EMail: abbieb@nortelnetworks.com 604 Brad Cain 605 Cereva Networks 606 EMail: bcain@cereva.com 608 Fred Douglis 609 AT&T Labs 610 Room B137 611 180 Park Ave, Bldg 103 612 Florham Park, NJ 07932, US 613 EMail: douglis@research.att.com 615 Mark Green 616 CacheFlow 617 650 Almanor Avenue 618 Sunnyvale, CA 94085, US 619 EMail: markg@cacheflow.com 621 Markus Hofmann 622 Lucent Technologies 623 Room 4F-513 624 101 Crawfords Corner Rd. 625 Holmdel, NJ 07733, US 626 EMail: hofmann@bell-labs.com 628 Raj Nair 629 Cisco Systems 630 50 Nagog Park 631 Acton, MA 01720, US 632 EMail: rnair@cisco.com 634 Doug Potter 635 Cisco Systems 636 50 Nagog Park 637 Acton, MA 01720, US 638 EMail: dougpott@cisco.com 640 Oliver Spatscheck 641 AT&T Labs 642 Room B131 643 180 Park Ave, Bldg 103 644 Florham Park, NJ 07932, US 645 EMail: spatsch@research.att.com 646 Appendix A 648 Measurements 650 Request-Routing systems can use a variety of metrics in order 651 to determine the best surrogate that can serve a client's request. 652 In general, these metrics are based on network measurements and 653 feedback from surrogates. It is possible to combine multiple 654 metrics using both proximity and surrogate feedback for best 655 surrogate selection. The following sections describe several 656 well known metrics as well as the major techniques for obtaining 657 them. 659 A.1 Proximity Measurements 661 Proximity measurements can be used by the Request-Routing system to 662 direct users to the "closest" surrogate. In a DNS Request-Routing 663 system, the measurements are made to the client's local DNS server. 664 However, when the IP address of the client is accessible more 665 accurate proximity measurements can be obtained. 667 Furthermore, proximity measurements can be exchanged between 668 surrogates and the requesting entity. In many cases, proximity 669 measurements are "one-way" in that they measure either the forward 670 or reverse path of packets from the surrogate to the requesting 671 entity. This is important as many paths in the Internet are 672 asymmetric. 674 In order to obtain a set of proximity measurements, a network 675 may employ active probing techniques and/or passive measurement 676 techniques. The following sections describe these two techniques. 678 A.1.1 Active Probing 680 Active probing is when past or possible requesting entities are 681 probed using one or more techniques to determine one or more 682 metrics from each surrogate or set of surrogates. An example of 683 a probing technique is an ICMP ECHO Request that is periodically 684 sent from each surrogate or set of surrogates to a potential 685 requesting entity. 687 In any active probing approach, a list of potential requesting 688 entities need to be obtained. This list can be generated 689 dynamically. Here, as requests arrive, the requesting entity 690 addresses can be cached for later probing. Another potential 691 solution is to use an algorithm to divide address space into blocks 692 and to probe random addresses within those blocks. Limitations 693 of active probing techniques include: 695 1. Measurements can only be taken periodically. 696 2. Firewalls and NATs disallow probes. 698 3. Probes often cause security alarms to be triggered on 699 intrusion detection systems. 701 A.1.2 Passive Measurement 703 Passive measurements could be obtained when a client performs data 704 transfers to or from a surrogate. Here, a bootstrap mechanism is 705 used to direct the client to a bootstrap surrogate. Once the client 706 connects, the actual performance of the transfer is measured. This 707 data is then fed back into the Request-Routing system. 709 An example of passive measurement is to watch the packet loss 710 from a client to a surrogate by observing TCP behavior. Latency 711 measurements can also be learned by observing TCP behavior. The 712 limitations of passive measurement approach are directly related 713 to the bootstrapping mechanism. Basically, a good mechanism is 714 needed to ensure that not every surrogate is tested per client 715 in order to obtain the data. 717 A.1.3 Metric Types 719 The following sections list some of the metrics, which can be used 720 for proximity calculations. 722 * Latency: Network latency measurements metrics are used to 723 determine the surrogate (or set of surrogates) that has the 724 least delay to the requesting entity. These measurements 725 can be obtained using either an active probing approach or a 726 passive network measurement system. 728 * Packet Loss: Packet loss measurements can be used as a 729 selection metric. A passive measurement approach can easily 730 obtain packet loss information from TCP header information. 731 Active probing can periodically measure packet loss from 732 probes. 734 * Hop Counts: Router hops from the surrogate to the requesting 735 entity can be used as a proximity measurement. 737 * BGP Information: BGP AS PATH and MED attributes can be used 738 to determine the "BGP distance" to a given prefix/length 739 pair. In order to use BGP information for proximity 740 measurements, it must be obtained at each surrogate 741 site/location. 743 A.2 Surrogate Feedback 745 The Request-Routing system can use feedback from surrogates in 746 order to select a "least-loaded" delivery node. Feedback can 747 be delivered from each surrogate or can be aggregated by site or 748 by location. 750 A.2.1 Probing 752 Feedback information may be obtained by periodically probing a 753 surrogate by issuing an HTTP request and observing the behavior. 754 The problems with probing for surrogate information are: 756 1. It is difficult to obtain "real-time" information. 757 2. Non-real-time information may be inaccurate. 759 Consequently, feedback information can be obtained by agents that 760 reside on surrogates that can communicate a variety of metrics about 761 their nodes. 763 A.2.2 Well Known Metrics 765 The following provides a list of several of the popular metrics 766 that are used for surrogate feedback: 768 * Surrogate CPU Load. 769 * Interface Load / Dropped packets. 770 * Number of connections being served. 771 * Storage I/O Load. 773 Full Copyright Statement 775 Copyright (C) The Internet Society (2000). All Rights Reserved. 777 This document and translations of it may be copied and furnished to 778 others, and derivative works that comment on or otherwise explain it 779 or assist in its implementation may be prepared, copied, published 780 and distributed, in whole or in part, without restriction of any 781 kind, provided that the above copyright notice and this paragraph 782 are included on all such copies and derivative works. However, this 783 document itself may not be modified in any way, such as by removing 784 the copyright notice or references to the Internet Society or other 785 Internet organizations, except as needed for the purpose of 786 developing Internet standards in which case the procedures for 787 copyrights defined in the Internet Standards process must be 788 followed, or as required to translate it into languages other than 789 English. 791 The limited permissions granted above are perpetual and will not be 792 revoked by the Internet Society or its successors or assigns. 794 This document and the information contained herein is provided on an 795 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 796 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 797 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 798 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 799 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.