RFC 3568

Known Content Network (CN) Request-Routing Mechanisms

📅 published July 2003, from ietf

Known Content Network (CN) Request-Routing Mechanisms 💖

  • RFC: 3568
  • Stream: Network Working Group
  • Authors: A. Barbir (Nortel Networks), B. Cain (Storigen Systems), R. Nair (Consultant), O. Spatscheck (AT&T) 👯‍♀️
  • Category: Informational 📘
  • Date: July 2003 🗓️
  • Obsoletes / Updates: There's no Obsoletes or Updates line in the header, so this doc doesn't list anything it replaces or changes. 🙅‍♀️

Status of this Memo 📜

bestie, this memo just provides information for the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited. 🌸

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🦋

This doc is a summary of Request-Routing techniques, which are the ways of steering client requests to surrogates based on different policies and a possible set of metrics. It covers the techniques that were commonly used in the industry on or before December 2000. In this memo, Request-Routing is the thing people usually call content routing or content redirection. 💅 In principle, Request-Routing techniques can be sorted into three groups: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. ✨

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  DNS based Request-Routing Mechanisms . . . . . . . . . . . . 3
    2.1.  Single Reply . . . . . . . . . . . . . . . . . . . . . 3
    2.2.  Multiple Replies . . . . . . . . . . . . . . . . . . . 3
    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.2.  Header-Based Request-Routing . . . . . . . . . 9
          4.1.3.  Site-Specific Identifiers. . . . . . . . . . .10
    4.2.  Content Modification . . . . . . . . . . . . . . . . .10
          4.2.1.  A-priori URL Rewriting . . . . . . . . . . . .11
          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.  Additional Authors and Acknowledgements  . . . . . . . . . .12
A.  Measurements . . . . . . . . . . . . . . . . . . . . . . . .13
    A.1.  Proximity Measurements . . . . . . . . . . . . . . . .13
          A.1.1.  Active Probing . . . . . . . . . . . . . . . .13
          A.1.2.  Metric Types . . . . . . . . . . . . . . . . .14
          A.1.3.  Surrogate Feedback . . . . . . . . . . . . . .14
8.  Normative References . . . . . . . . . . . . . . . . . . . .15
9.  Informative References . . . . . . . . . . . . . . . . . . .15
10. Intellectual Property and Copyright Statements . . . . . . .17
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .18
12. Full Copyright Statement . . . . . . . . . . . . . . . . . .19

1. Introduction 🌷

okay so this doc is basically a recap of the request routing techniques the industry was using before December 2000. 📚 Request routing is how you send client requests to surrogates based on different policies and a possible set of metrics. Honestly the whole job of pointing clients at surrogates goes by a few names: Request-Routing, Content Routing, or Content Redirection. 🎀

Request-Routing techniques are commonly used in Content Networks (also known as Content Delivery Networks) [8]. Content Networks include network infrastructure that exists in layers 4 through 7. 🧚 They deal with routing and forwarding requests and responses for content, and they rely on layer 7 protocols such as HTTP [4] for transport. 🌈

Request-Routing techniques are generally used to send client requests for objects to a surrogate, or a set of surrogates, that could best serve that content. 💅 Request-Routing mechanisms could also be used to send client requests to surrogates that live inside a Content Network (CN) [8]. 🫶

Request-Routing techniques are used to extend the reach and scale of Content Delivery Networks, and there are multiple Request-Routing mechanisms out there. ✨ At a high level, they can be classified under: DNS Request-Routing, transport-layer Request-Routing, and application-layer Request-Routing. 🦋

A request routing system uses a set of metrics to try to direct users to the surrogate that can best serve the request. 🎯 For example, the choice of surrogate could be based on network proximity, bandwidth availability, surrogate load, and availability of content. Appendix A has a rundown of metrics and measurement techniques that could be used to pick the best surrogate. 📊

Here's how the memo is laid out: Section 2 summarizes known DNS based Request-Routing techniques. 🌐 Section 3 talks about transport-layer Request-Routing methods. Section 4 explores application-layer Request-Routing mechanisms. 🔍 Section 5 covers how you can combine the methods from the earlier sections to optimize the performance of the Request-Routing System. 🔥 And Appendix A gives a summary of possible metrics and measurement techniques that the Request-Routing system could use to choose a given surrogate. 👑

2. DNS based Request-Routing Mechanisms 🌍

DNS based Request-Routing techniques are super common because DNS is everywhere [10][12][13]. 💖 With these techniques, a specialized DNS server gets slotted into the DNS resolution process. That server can return a different set of A, NS, or CNAME records based on user defined policies, metrics, or a combination of both. 🧠 [11] RFC 2782 (DNS SRV) gives guidance on using DNS for load balancing, and it describes some of the limitations and suggests appropriate usage of DNS based techniques. 🌸 The next sections give a summary of some of the techniques in use. 🎀

2.1. Single Reply 🦋

In this approach, the DNS server is authoritative for the entire DNS domain or a subdomain. 👑 The DNS server returns the IP address of the best surrogate in an A record to the requesting DNS server. The IP address could also be a virtual IP (VIP) address for the best set of surrogates for the requesting DNS server. 💅

2.2. Multiple Replies 🌈

In this approach, the Request-Routing DNS server returns multiple replies, such as several A records for various surrogates. 🍓 Common implementations of client site DNS servers cycle through the multiple replies in a Round-Robin fashion. The order in which the records come back can be used to direct multiple clients that all use a single client site DNS server. 🧚

2.3. Multi-Level Resolution ⭐

In this approach, multiple Request-Routing DNS servers can be involved in a single DNS resolution. The reason for using multiple Request-Routing DNS servers in one resolution is to split more complex decisions from a single server across multiple, more specialized, Request-Routing DNS servers. 🫶 The most common ways of slotting multiple Request-Routing DNS servers into a single resolution are NS and CNAME records. 💜 For example, a higher level DNS server might operate within a territory and direct the DNS lookup to a more specific DNS server within that territory to give a more accurate resolution. 🗺️

2.3.1. NS Redirection 🔁

A DNS server can use NS records to redirect the authority of the next level domain to another Request-Routing DNS server. This technique lets multiple DNS servers be involved in the name resolution process. 🤹‍♀️ For example, a client site DNS server resolving a.b.example.com [10] would eventually request a resolution of a.b.example.com from the name server authoritative for example.com. That name server might be a Request-Routing NS server. 🧁 In this case, the Request-Routing DNS server can either return a set of A records, or it can redirect the resolution of the request for a.b.example.com to the DNS server that is authoritative for example.com using NS records. 💅

One drawback of using NS records is that the number of Request-Routing DNS servers is limited by the number of parts in the DNS name. 😬 This problem comes from DNS policy that makes a client site DNS server give up on a request if no additional parts of the DNS name get 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. Basically, the last DNS server can put its own NS record in the authoritative section of its response. The client will then use this cached NS record for further request resolutions until it expires. ⏳

Another drawback is that some implementations of bind voluntarily cause timeouts to simplify their implementation, in cases where an NS level redirect points to a name server for which no valid A record is returned or cached. 🙈 This is especially a problem when the domain of the name server doesn't match the domain currently being resolved. In that case, the A records that might be passed in the DNS response are discarded for security reasons. 🔐 Another drawback is the added delay in resolving the request due to the use of multiple DNS servers. 🐢

2.3.2. CNAME Redirection 🎀

In this scenario, the Request-Routing DNS server returns a CNAME record to send resolution to an entirely new domain. 🦄 In principle, the new domain might use a new set of Request-Routing DNS servers. 🌟

One disadvantage of this approach is the extra overhead of resolving the new domain name. 😮‍💨 The main advantage is that the number of Request-Routing DNS servers is independent of the format of the domain name. 🥰

2.4. Anycast ✨

okay so anycast [5] is an inter-network service for when a host, app, or user wants to reach a host that offers a particular service, but if a bunch of servers offer it, it doesn't really matter which one you get 💅 🌸. the host sends a datagram to an anycast address, and the inter-network does its best to deliver it to at least one, and ideally only one, of the servers that accept datagrams for that address 🦋.

the motivation is that it makes finding the right server way easier 💖. instead of scrolling a list of servers and picking the closest one, a user could just type the server's name and land on the nearest one, literally no effort 🙈. with anycast, DNS resolvers wouldn't need to be configured with the IP addresses of their servers either. they could just send queries to a well-known DNS anycast address 🧚.

also, to combine measurement and redirection, the Request-Routing DNS server can advertise an anycast address as its IP address 👑. the same address is used by multiple physical DNS servers. so the Request-Routing DNS server that's closest to the client site DNS server in terms of OSPF and BGP routing is the one that gets the packet with the DNS resolution request 🔥. the server can use that info to make its Request-Routing decision.

the drawbacks, though 😭:

  • the DNS server may not be the closest server in terms of routing to the client.
  • routing protocols usually aren't load sensitive. so the closest server might not be the one with the least network latency 💀.
  • server load isn't considered during the Request-Routing process.

2.5. Object Encoding 🎀

since only DNS names are visible during DNS Request-Routing, some solutions stuff the object type, object hash, or similar info right into the DNS name 🍓. this can be as simple as splitting objects by type, like images.a.b.example.com and streaming.a.b.example.com, or as fancy as a schema where the domain name contains a unique identifier (like a hash) for the object 🌈. the obvious perk is that object info is available at resolution time ✨. the downside is that the client site DNS server has to do multiple resolutions to pull up a single web page, which might make the overall latency worse instead of better 😭.

2.6. DNS Request-Routing Limitations 💜

this section lists some limitations of DNS based Request-Routing techniques. the tea ☕:

  • DNS only allows resolution at the domain level. but an ideal request resolution system would handle requests per object level 🦋.
  • in DNS based Request-Routing systems, servers may be required to return DNS entries with a short time-to-live (TTL) value. this might be needed so they can react quickly when things go down 🚨. but that can increase the volume of requests hitting DNS servers.
  • some DNS implementations don't always follow DNS standards 🙃. for example, lots of DNS implementations don't honor the DNS TTL field.
  • DNS Request-Routing is based only on knowing the client DNS server, because client addresses aren't relayed within DNS requests 🫠. that limits how well the Request-Routing system can figure out how close a client is to the surrogate.
  • DNS servers can request and allow recursive resolution of DNS names. with recursive resolution, the Request-Routing DNS server won't see the IP address of the client's site DNS server 👀. instead, it sees the address of whichever DNS server is doing the recursive lookup on behalf of the client's site DNS server. for example, imgs.example.com might be resolved by a CN, but the request could come from dns1.example.com because of the recursion 💅.
  • users who share a single client site DNS server get sent to the same set of IP addresses during the TTL interval. this might overload the surrogate during a flash crowd 😩.
  • some implementations of bind can cause DNS timeouts while handling exceptional situations 🙈. for example, timeouts can happen for NS redirections to unknown domains.

DNS based request routing techniques can have serious limitations, honestly 💀. for example, using these techniques can overburden third party DNS servers, which should not be allowed [19]. in [11], RFC 2782 gives warnings about using DNS for load balancing ⚠️. readers are encouraged to read the RFC to really get the limitations 📚.

3. Transport-Layer Request-Routing 🦋

at the transport layer, you can get finer levels of granularity by closely inspecting the client's requests 🔍. in this approach, the Request-Routing system inspects the info in the first packet of the client's request to make surrogate selection decisions. that inspection gives data about the client's IP address, port info, and layer 4 protocol 🫶. the data can be combined with user-defined policies and other metrics to pick a surrogate that's better suited to serve the request ✨. the techniques [20][18][15] used to hand the session off to a more appropriate surrogate are beyond the scope of this document, so we're skipping them here 🙅‍♀️.

in general, the forward-flow traffic (client to newly selected surrogate) goes through the surrogate that DNS originally picked 🧚. the reverse-flow traffic (surrogate to client) usually moves way more data than the forward flow, so it typically takes the direct path 🚀.

the overhead of transport-layer Request-Routing [21][19] is better suited to long-lived sessions like FTP [1] and RTSP [3] 🎀. still, it can also be used to steer clients away from overloaded surrogates 💫.

transport-layer Request-Routing can be combined with DNS based techniques too 💕. like we said earlier, DNS based methods resolve client requests based on domains or subdomains, and they're exposed to the client's DNS server IP address 👀. so DNS based methods could be a first step in picking an appropriate surrogate, with the transport-layer Request-Routing system doing the more accurate refinement after that 🌈.

4. Application-Layer Request-Routing 👑

application-layer Request-Routing systems go deeper than the transport layer header, examining the client's packets more closely 🔬. that deeper look gives fine-grained Request-Routing control, all the way down to individual objects ✨. the process can happen in real time, at the moment the object is requested ⏰. being exposed to the client's IP address plus fine-grained knowledge of the requested objects lets application-layer Request-Routing systems pick the best surrogate with way more control 💅.

4.1. Header Inspection 🎀

some application-level protocols, like HTTP [4], RTSP [3], and SSL [2], give hints at the start of the session about how the client request should be directed 🧭. those hints can come from the URL of the content, or from other parts of the MIME request header, like Cookies 🍪.

4.1.1. URL-Based Request-Routing 🔗

application-level protocols like HTTP and RTSP describe the requested content by its URL [6]. in lots of cases, that info is enough to tell the content apart and route the request properly 💖. in most cases, just checking the prefix or suffix of the URL may be enough to make the Request-Routing decision 🙌.

4.1.1.1. 302 Redirection 🦋

in this approach, the client's request is first resolved to a virtual surrogate 🎭. then the surrogate returns an application-specific code, such as the 302 (for HTTP [4] or RTSP [3]), to redirect the client to the actual delivery node 🚚.

this technique is relatively simple to implement 🫶. but the main drawback is the extra latency from sending the redirect message back to the client 🐢.

4.1.1.2. In-Path Element 🛣️

in this technique, an In-Path element sits in the network, in the forwarding path of the client's request 🛤️. the In-Path element transparently intercepts the transport connection 👀. it examines the client's content requests and makes the Request-Routing decisions 🧠.

the In-Path element then splices the client connection onto a connection with the appropriate delivery node and passes along the content request 🪡. in general, the return path goes back through the In-Path element. but it's possible to arrange a direct return by passing the address translation info to the surrogate or delivery node through some proprietary means 🤫.

the main disadvantage here is the performance hit from parsing URLs in the path of the network traffic 😬. but it's generally the case that return traffic is much larger than forward traffic, so it's not all bad 🙂.

this technique allows partitioning traffic among a set of delivery nodes by content objects identified by URLs 🍰. that means object-specific control of server loading ⚖️. for example, requests for non-cacheable object types may be directed away from a cache 🙅‍♀️.

4.1.2. Header-Based Request-Routing 🎧

this technique uses HTTP [4] headers such as Cookie, Language, and User-Agent to select a surrogate 🔎. some examples of using this technique are given in [20] 📖.

cookies can be used by a web site to identify a customer or session 🍪. cookie based Request-Routing provides content service differentiation based on the client 💜. this approach only works as long as the cookies belong to the client 🫣. it's also possible to direct a connection from a multi-session transaction to the same server, which gives session-level persistence 🔁.

the Language header can 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 which type of delivery node has content specialized to handle the request 🎙️.

4.1.3. Site-Specific Identifiers 🪪

site-specific identifiers help authenticate and identify a session from a specific user 🔐. this info may be used to direct a content request 💫.

an example of a site-specific identifier is the SSL Session Identifier 🗝️. a web server generates it, and the web client uses it in later sessions to identify itself and skip a whole security authentication exchange 🏃‍♀️. to inspect the session identifier, an In-Path element would observe the web server's responses and figure out the session identifier, which it then uses to associate the session with a specific server 🕵️‍♀️. the remaining sessions are directed based on the stored session identifier 🌸.

4.2. Content Modification 💅

okay so this technique lets a content provider take direct control over Request-Routing decisions 🎀 without needing special switching devices or directory services sitting in the path between the client and the origin server. basically, the content provider can directly tell the client which surrogate is the best one to serve the request ✨. The choice can be made per object, or it can depend on a set of metrics. The big goal is better scalability and performance for delivering the modified content, including all the embedded objects 🦋.

so here's the general idea. content objects have a basic structure that includes references to extra, embedded objects. most web pages consist of an HTML document with plain text plus some embedded objects, like GIF or JPEG images 🌸. those embedded objects are pulled in with embedded HTML directives, which tell the client to fetch them from the origin server. a content provider can now rewrite those references so the objects get fetched from the best surrogate instead 🧚. this is also called URL rewriting.

content modification techniques MUST NOT violate the architectural concepts of the Internet [9]. you also MUST make special considerations so the job of modifying content is done in a way that matches RFC 3238 [9], which lays out the architectural considerations for intermediaries that perform operations or modifications on content. no shortcuts, bestie 😤

the basic types of URL rewriting are in the subsections below 👑.

4.2.1. A-priori URL Rewriting

in this scheme, the content provider rewrites the embedded URLs before the content is put on the origin server 💖. this can be done by hand, or with software tools that parse the content and replace the embedded URLs.

a-priori URL rewriting on its own doesn't let you think about client specifics for Request-Routing 🙈. but it can be combined with DNS Request-Routing to point related DNS queries into the service provider's domain name space. after that, the dynamic Request-Routing based on client specifics happens through the DNS approach ✨.

4.2.2. On-Demand URL Rewriting

on-demand (or dynamic) URL rewriting changes the content when the client request actually reaches the origin server 🌈. at that point the client's identity is known, so it can be taken into account while the embedded URLs get rewritten. an automated process can figure out, on demand, which surrogate would serve that client best 💅. then the embedded URLs get rewritten so the client fetches the objects from that best surrogate instead of the origin server 🫶.

4.2.3. Content Modification Limitations

content modification as a Request-Routing mechanism has a bunch of limitations [23] 💀. for example:

  • the first request from a client to a specific site MUST be served from the origin server.
  • content that's been modified to point at nearby surrogates instead of the origin server SHOULD be marked as non-cacheable. another option is to mark those pages as cacheable only for a relatively short period of time. rewritten URLs on cached pages can cause trouble, since they can get outdated and point at surrogates that are no longer available or are no longer good choices 😭.

5. Combination of Multiple Mechanisms 🔥

sometimes mixing mechanisms is way better than using just one of them alone ✨. here's an example of how they can work together.

a basic problem with DNS Request-Routing is its resolution granularity, which only works on a per-domain level 🙃. you can't easily do a per-object redirection that way. content modification can fix that, though. with content modification, references to different objects on the same origin server can be rewritten to point into different domain name spaces. then, with DNS Request-Routing, requests for those objects can be dynamically sent to different surrogates 🎀.

6. Security Considerations 🔐

okay bestie, this section is serious, so listen up 💀. the main goal of this document is to give a summary of current Request-Routing techniques. these techniques are already implemented on the Internet. security MUST be addressed by any entity that implements any technique that redirects client requests. RFC 3238 [9] covers the main requirements for entities that want to modify requests for content on the Internet 🛡️.

some active probing techniques will set off intrusion detection systems and firewalls 🚨. so implementers RECOMMENDED be aware of routing protocol security [25]. (yes, we're keeping that wording exactly as the original has it.)

it's really important to note how TLS [2] affects request routing in CNs 🧐. specifically, when TLS is used, the full URL isn't visible to the content network unless it terminates the TLS session. this document focuses on HTTP techniques. TLS-based techniques that require terminating TLS sessions on Content Peering Gateways [8] are beyond the scope of this document 🙅‍♀️.

the details of security techniques are also beyond the scope of this document 🫶.

7. Additional Authors and Acknowledgements 🌸

the following people helped write this document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann (Lucent), Doug Potter 💖.

the authors thank Ian Cooper, Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean (CrystalBall) for their contributions and comments 🙌.

Appendix A. Measurements 🧚

Request-Routing systems can use a variety of metrics to figure out the best surrogate for a client's request 📊. these metrics are usually based on network measurements and feedback from surrogates. you can combine multiple metrics, using both proximity and surrogate feedback, for best surrogate selection ✨. the following sections describe several well-known metrics and the main techniques for getting them 🦋.

A.1. Proximity Measurements

proximity measurements can help the Request-Routing system send users to the "closest" surrogate 📍. in this document, proximity means round-trip time ⏱️. in a DNS Request-Routing system, the measurements are made to the client's local DNS server. however, when the client's IP address is accessible, more accurate proximity measurements can be obtained [24].

proximity measurements can be exchanged between surrogates and the requesting entity 🤝. in lots of cases, they're "one-way," meaning they measure either the forward or the reverse path of packets from the surrogate to the requesting entity. this matters because lots of Internet paths are asymmetric [24] 🙃.

to get a set of proximity measurements, a network MAY employ active probing techniques 🔍.

A.1.1. Active Probing

active probing is when past or possible requesting entities get probed, using one or more techniques, to figure out one or more metrics from each surrogate (or set of surrogates) 🛸. an example is an ICMP ECHO Request that's periodically sent from each surrogate (or set of surrogates) to a potential requesting entity.

with any active probing approach, you need a list of potential requesting entities 📝. that list can be generated dynamically: as requests arrive, the requesting entity addresses can be cached for later probing. another option is to use an algorithm that divides the address space into blocks and probes random addresses within those blocks. limitations of active probing include:

  • measurements can only be taken periodically ⏰.
  • firewalls and NATs disallow probes 🧱.
  • probes often trigger security alarms on intrusion detection systems 🚨.

A.1.2. Metric Types

here are some of the metrics you can use for proximity calculations 💅.

  • Latency: network latency measurements 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 active probing techniques.
  • 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 to determine the "BGP distance" to a given prefix/length pair 🗺️. to use BGP information for proximity measurements, it MUST be obtained at each surrogate site/location.

it's important to note that AS PATH information can be meaningless as a good selection metric 🙈 [24].

A.1.3. Surrogate Feedback

surrogate feedback is there to help select a "least-loaded" delivery node 🎯. feedback can be delivered from each surrogate, or it can be aggregated by site or by location.

A.1.3.1. Probing

feedback information MAY be obtained by periodically probing a surrogate, issuing an HTTP request and observing the behavior 👀. the problems with probing for surrogate information are:

  • it's difficult to obtain "real-time" information 😩.
  • non-real-time information MAY be inaccurate.

so, feedback information can be obtained by agents that live on surrogates and can communicate a variety of metrics about their nodes 🤖✨.

8. Normative References 📚

  • [1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
  • [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] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
  • [6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
  • [7] Schulzrinne, H., Casner, S., Federick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
  • [8] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.
  • [9] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.

9. Informative References ✨

okay so these are the "extra reading" refs, the stuff the doc leans on for background but doesn't need you to implement anything from 🧠📚

  • [10] Eastlake, D. and A, Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. 🌸
  • [11] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2002. 🧚
  • [12] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 💜
  • [13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1035, November 1987. 💜
  • [14] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. 🎀
  • [15] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. 🦋
  • [16] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998. ✨
  • [17] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001. 🌈
  • [18] M. Welsh et al., "SEDA: An Architecture for Well-Conditioned, Scalable Internet Services", Proceedings of the Eighteenth Symposium on Operating Systems Principles (SOSP-18) 2001, October 2001. 🔥
  • [19] A. Shaikh, "On the effectiveness of DNS-based Server Selection", INFOCOM 2001, August 2001. 👑
  • [20] C. Yang et al., "An effective mechanism for supporting content-based routing in scalable Web server clusters", Proc. International Workshops on Parallel Processing 1999, September 1999. 🍓
  • [21] R. Liston et al., "Using a Proxy to Measure Client-Side Web Performance", Proceedings of the Sixth International Web Content Caching and Distribution Workshop (WCW'01) 2001, August 2001. 🦋
  • [22] W. Jiang et al., "Modeling of packet loss and delay and their effect on real-time multimedia service quality", Proceedings of NOSSDAV 2000, June 2000. 💖
  • [23] K. Johnson et al., "The measured performance of content distribution networks", Proceedings of the Fifth International Web Caching Workshop and Content Delivery Workshop 2000, May 2000. ⭐
  • [24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM Transactions 1999, June 1999. 🫶
  • [25] F. Wang et al., "Secure routing protocols: Theory and Practice", Technical report, North Carolina State University 1997, May 1997. 💅

10. Intellectual Property Statement 💖

so the IETF is basically saying "we're not picking a side on whether any IP rights apply to the tech in here, and we're not claiming we've hunted down every possible right either" 🙃 if you want the nitty gritty on how rights work for standards-track stuff, that's in BCP-11. copies of any claimed rights, plus any assurances about licenses, or the outcome of trying to get a general license or permission for implementers or users, can be requested from the IETF Secretariat. 📬

and if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to practice this standard, the IETF wants you to say so. send that info to the IETF Executive Director. 🫶

11. Authors' Addresses 🌸

these are the humans who wrote it, with the contact info they listed 🧑‍💻

Abbie Barbir
Nortel Networks
3500 Carling Avenue
Nepean, Ontario  K2H 8E9
Canada

Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com


Brad Cain
Storigen Systems
650 Suffolk Street
Lowell, MA  01854
USA

Phone: +1 978-323-4454
EMail: bcain@storigen.com


Raj Nair
6 Burroughs Rd
Lexington, MA  02420
USA

EMail: nair_raj@yahoo.com


Oliver Spatscheck
AT&T
180 Park Ave, Bldg 103
Florham Park, NJ  07932
USA

EMail: spatsch@research.att.com

copyright is The Internet Society (2003), all rights reserved, but the vibe is super generous 🥰

you're allowed to copy and share this doc and translations of it. you can also make derivative works that comment on or explain it, or help you implement it, and publish and distribute those however you want, in whole or in part, with no real restrictions. the one catch is the copyright notice and this paragraph have to stay on every copy and derivative work. the doc itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet orgs. the exceptions are when you're developing Internet standards (then the Internet Standards process copyright procedures must be followed), or when you're translating it into languages other than English. 🌈

those permissions are perpetual and the Internet Society or its successors or assignees won't revoke them. ✨

the doc and the info in it come "AS IS", 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. 💜

📦 where this page comes from