[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            B. Cain
Internet-Draft                                     Mirror Image Internet
Expires: May 15, 2001                                         F. Douglis
                                                                AT&T Labs
                                                                 M. Green
                                                                   Entera
                                                               M. Hofmann
                                                                   Lucent
                                                                  R. Nair
                                                                D. Potter
                                                                    Cisco
                                                            O. Spatscheck
                                                                AT&T Labs
                                                        November 14, 2000


                   Known CDN Request Mapping Mechanisms
                   draft-cain-cdnp-known-req-map-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 15, 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 15, 2001                  [Page 1]


Internet-Draft              Request Mapping                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 15, 2001                  [Page 2]


Internet-Draft              Request Mapping                November 2000


Abstract

    This memo presents a number of known mechanisms used to direct
    client application requests to surrogate servers based on various
    policies. In this memo we group mechanisms commonly called request
    routing, content routing or content redirection under the term
    request mapping. There exist multiple request mapping mechanisms. At
    a high-level, these may be classified under: DNS Request Mapping,
    Transport-layer Mapping, and Application-layer Mapping.

Table of Contents

    1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  5
    2.      DNS Request Mapping  . . . . . . . . . . . . . . . . . . .  6
    2.1     Basic DNS Mapping 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 Mapping Problems . . . . . . . . . . . . . . .  8
    3.      Transport-layer Mapping  . . . . . . . . . . . . . . . . . 10
    4.      Application-layer Mapping  . . . . . . . . . . . . . . . . 11
    4.1     Header Inspection  . . . . . . . . . . . . . . . . . . . . 11
    4.1.1   URL-based Mapping  . . . . . . . . . . . . . . . . . . . . 11
    4.1.1.1 302 Redirection  . . . . . . . . . . . . . . . . . . . . . 11
    4.1.1.2 In-Path Element  . . . . . . . . . . . . . . . . . . . . . 11
    4.1.2   Mime Header-based Mapping  . . . . . . . . . . . . . . . . 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 15, 2001                  [Page 3]


Internet-Draft              Request Mapping                November 2000


            Authors' Addresses . . . . . . . . . . . . . . . . . . . . 21
            Full Copyright Statement . . . . . . . . . . . . . . . . . 24

















































Cain, et. al.             Expires May 15, 2001                  [Page 4]


Internet-Draft              Request Mapping                November 2000


1. Introduction

    The term "mapping" is used to convey a more general sense than the
    word "direction". For example, one type of mapping 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 "mapping"
    is used to cover a wider variety of techniques than what might be
    implied by the term "direction".

    There exist multiple request mapping mechanisms. At a high-level,
    these may be classified under: DNS Request Mapping, Transport-layer
    Mapping, and Application-layer Mapping.






































Cain, et. al.             Expires May 15, 2001                  [Page 5]


Internet-Draft              Request Mapping                November 2000


2. DNS Request Mapping

    DNS Request Mapping is used in many CDNs because of its ubiquity as
    a directory service. The basic concept of DNS based request mapping
    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 Mapping Mechanisms

    In its simplest form the mapping DNS server is authoritative for an
    entire DNS domain or a subdomain. If a DNS resolution for the domain
    is requested, the mapping 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 mapping 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 map
    multiple clients using a single client site DNS server.

2.3 Multi-level Resolution

    To allow for multiple mapping decisions, multiple mapping DNS
    servers can be involved in a single DNS resolution. The rational of
    utilizing multiple mapping DNS servers in a single DNS resolution is
    to allow one to distribute more complex decisions from a single
    mapping DNS server to multiple, more specialized, mapping DNS
    servers. The most common mechanisms used to insert multiple mapping
    DNS servers in a single DNS resolution are the use of NS and CNAME
    records.

2.4 NS Redirection

    Using NS records, multiple mapping DNS servers can be included by
    redirecting the authority of the next level domain to another
    mapping 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
    nameserver authoritative for this domain might be a mapping DNS
    server. In this case the mapping DNS server can either return a set


Cain, et. al.             Expires May 15, 2001                  [Page 6]


Internet-Draft              Request Mapping                November 2000


    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 mapping
    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 mapping DNS server returns a CNAME for a domain to map the
    further request resolution to an entirely new domain and potentially
    a new set of mapping 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 mapping DNS servers is
    independent of the depth of the domain name. The number of mapping
    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 mapping DNS server can
    advertise an anycast address as its IP address. The same anycast
    address is used by multiple physical DNS servers. In this scenario,
    the mapping 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 mapping DNS server at
    this point knows that it is the closest (by this metric) and can use


Cain, et. al.             Expires May 15, 2001                  [Page 7]


Internet-Draft              Request Mapping                November 2000


    this information to make a mapping decision. Drawbacks of this
    solution are:

       *  It is not known if the mapping DNS server is the closest DNS
          server in terms of routing from the mapping server to the
          client.

       *  BGP is not load sensitive. So the closest server in terms of
          routing might not be the server with the least network latency.

       *  The server load is not considered during routing. If server
          load has to be considered while finding the best mapping
          server, it has to be folded into the routing metrics used by
          the routing protocol.

2.7 Object Encoding

    Since only DNS names are visible during the DNS mapping, 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 mapping 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 Mapping Problems

    The use of DNS as a request mapping 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
           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 mapping.  For example, many implementations do not


Cain, et. al.             Expires May 15, 2001                  [Page 8]


Internet-Draft              Request Mapping                November 2000


           honor the DNS TTL field.

       4.  DNS Request Mapping is based only on knowledge of the local
           DNS server, as client addresses are not relayed within DNS
           requests.  DNS request mapping 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 mapping 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 mapping 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 15, 2001                  [Page 9]


Internet-Draft              Request Mapping                November 2000


3. Transport-layer Mapping

    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 mapping'.

    Transport-layer mapping 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 mapping 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 15, 2001                 [Page 10]


Internet-Draft              Request Mapping                November 2000


4. Application-layer Mapping

    Application-layer mapping involves deeper examining of packets
    beyond the transport layer header. It works together with DNS
    request mapping and provides fine-grained mapping 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
    mapping, the request routing process is more accurate than in the
    DNS request mapping 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 mapped. 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 Mapping

    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 map 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 mapping decision.

4.1.1.1 302 Redirection

    In redirection-based mapping, 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 mapping 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
    the content routing determination. Again, metrics such as those


Cain, et. al.             Expires May 15, 2001                 [Page 11]


Internet-Draft              Request Mapping                November 2000


    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 Mapping

    This works just like the URL-based mapping 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 mapping provides content service
    differentiation based on the client. In addition, it is possible to
    map a connection from a multi-session transaction to be mapped 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 map 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 map a content
    request.



Cain, et. al.             Expires May 15, 2001                 [Page 12]


Internet-Draft              Request Mapping                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 routed 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 mapping 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 15, 2001                 [Page 13]


Internet-Draft              Request Mapping                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 mapping. It can
    be used in combination with DNS request mapping, however, to direct
    related DNS queries into the domain name space of the service
    provider (see Section 6.1). Dynamic request mapping 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 mapping 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 15, 2001                 [Page 14]


Internet-Draft              Request Mapping                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 mapping 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 mapping 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 mapping, requests for those
    objects can now dynamically be mapped to different surrogates.




































Cain, et. al.             Expires May 15, 2001                 [Page 15]


Internet-Draft              Request Mapping                November 2000


6. Measurements

    CDNs' Request Mapping 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 Mapping Systems make use of "proximity"
    measurements to direct users to the "closest" surrogate.  If a DNS
    system is used for request mapping, 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 15, 2001                 [Page 16]


Internet-Draft              Request Mapping                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 mapping 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 15, 2001                 [Page 17]


Internet-Draft              Request Mapping                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 mapping 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 feed into the Request
    Mapping 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 15, 2001                 [Page 18]


Internet-Draft              Request Mapping                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 15, 2001                 [Page 19]


Internet-Draft              Request Mapping                November 2000


8. Acknowledgements

    [Reviewers go here]
















































Cain, et. al.             Expires May 15, 2001                 [Page 20]


Internet-Draft              Request Mapping                November 2000


References

    [1]  Postel, J., "File Transfer Protocol", RFC 765, June 1980,
         <URL:http://www.rfc-editor.org/rfc/rfc765.txt>.

    [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC
         2246, January 1999,
         <URL:http://www.rfc-editor.org/rfc/rfc2246.txt>.

    [3]  Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
         Protocol", RFC 2326, April 1998,
         <URL:http://www.rfc-editor.org/rfc/rfc2326.txt>.

    [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,
         <URL:http://www.rfc-editor.org/rfc/rfc2616.txt>.

    [5]  Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering",
         draft-day-cdnp-model-02.txt (work in progress), October 2000,
         <URL:http://www.ietf.org/internet-drafts/draft-day-cdnp-model-02
         .txt>.


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 15, 2001                 [Page 21]


Internet-Draft              Request Mapping                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 15, 2001                 [Page 22]


Internet-Draft              Request Mapping                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 15, 2001                 [Page 23]


Internet-Draft              Request Mapping                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 15, 2001                 [Page 24]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/