Re: Requirements for Content Distribution (section 3 comments)

["John Robertson" <jrobertson@gw.novell.com>]

3. Content Distribution Architecture

   Would it be worth noting two existing models for content
   distribution that have been deployed?  Neither of these models
   handles peered relationships, but could be extended to do so.

    A.  DNS Re-routing and/or URI Re-writing:

      +----------+
     +----------+|   +---------+
    +----------+|    |  CDN C  |
    | CDN C's  | <-- | (agent  |
    | surrogate|     |  for D) |
    +__________+    _+---------+ _
          ^         /|          |\
          |        /              \
          |(iii)  /(ii)            \
          |      /                  \
          V    |/_                   \
    +----------+     +----------+     +-----------+
    |          | (i) | Optional | (i) |  "CDN D"  |
    |  CLIENT  |<--->|   URI    |<--->|  ORIGIN   |
    |          |     | rewriter |     |           |
    +----------+     +----------+     +-----------+

    i)  In the first step, the CLIENT makes a request for content.
    CDN D, the ORIGIN content provider has a relationship with CDN C.
    This relationship requires that CDN D use content URI's that resolve
    to CDN C's DNS server for resolution.  Some content providers modify
    their own source URIs for compliance, others provide a URI re-writer
    as a proxy, in front of their host server.

    In either case, the important characteristic is that the CLIENT
    requests content directly from the ORIGIN.

    ii)  When subsequent CLIENT requests for content are preparing to be
    issued, the CLIENT issues an IP resolution request through DNS
    protocols.  Because targeted URIs are prepended with CDN C's domain
    name, resolution of the IP address of these URIs is sent to CDN C's
    DNS server.

    CDN C is thus able to target the best/closest surrogate CDN server to
    provide content.  [In this approach, CDN C would be able to resolve
    to other, peered CDNs.]

    iii)  After the URI has been resolved to the IP address of a host,
    the CLIENT issues a request, to CDN C's surrogate, which then
    responds to the requests with the ORIGIN's content.


    B.   Proxy/Cache Hierarchies and Preferential Caching

                     +--------+     +----------+     +--------+
                     |        |     |  CDN D's | (i) | CDN E  |
                     | CLIENT |<--->|  Proxy   |<--->| ORIGIN |
                     |        |     | Surrogate|     |        |
                     +--------+    _+----------+     +--------+
                                   /|    ^
                                  /      |
                                 /(i)    |(i)
                                /        |
                              |/_        V
    +--------+     +----------+     +----------+     +--------+
    |        |     |  CDN A's | (i) |  CDN B's | (i) | CDN C  |
    | CLIENT |<--->|  Proxy   |<--->|  Proxy   |<--->| ORIGIN |
    |        |     | Surrogate|     | Surrogate|     |        |
    +--------+     +----------+     +----------+     +--------+

    
    i)  In the above diagram, (i) labeled arrows represent private
    network boundaries.

    In essence, content follows the existing Internet routed path with
    no special treatment of the route.  Proxies, at the borders of the
    private sub-nets, though would be able to preferentially cache CDN
    content and peered CDN content en route.  In addition to caching,
    these proxies would track delivery and generate ACCOUNTING events.

    The proxies would also be able to control cache inventory and both
    inventory costs and prices.  The intent being flexible 
    'marketplace' style peering arrangements.



Regards,
John Robertson
Novell, Inc.
Email jrobertson@novell.com