Re: Requirements for Content Distribution (section 3 comments)

["Lisa Amini" <aminil@us.ibm.com>]

"John Robertson" <jrobertson@gw.novell.com>@ops.ietf.org on 01/24/2001
05:26:07 PM

   Sent by:     owner-cdn@ops.ietf.org


   To:     <cdn@ops.ietf.org>, <stephen.thomas@transnexus.com>
   cc:
   Subject:     Re: Requirements for Content Distribution (section 3
   comments)




   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.

   I believe this has requirements which are not limited to distribution.
   But I also think it should be covered on a more generic scale.  That is,
   do we really need to consider a model beyond en-route requirements
   vs re-directed requirements?

   Referring to the above diagram, the advertising requirements/protocols
   should cover the ability for an en-route node (URI rewriter or a
   interception proxy) to communicate (similiar to the way hitmetering
   ability is communicated RFC2227) to the origin that it can supply
   feedback on usage. The origin can then use this info to contact a
   cdn to inject the content into the cdn, the origin would then
   alter it's pages so the urls for the injected content would be
   serviced by the cdn.

   IMO, the notification that the en-route node has this capability
   is part of the advertising protocol for distribution; the format
   of the info sent from the en-route node should be part of the
   accounting/feedback requirements; the request to inject the content
   into CDN-C fits within routing, distribution and accounting
   requirements -- this is based on having the distribution requirements
   draft include the replication, advertising and signalling components
   discussed in the gen-arch document (the current distribution draft
   includes only the advertising component, I believe the next version
   should be expanded to reflect replication and accounting also).

   BTW, I'm not partial to the en-route vs re-directed naming convention,
   but I couldn't find a similiar distinction in existing drafts --
   suggestions?


       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.


   Are there additional requirements with this model which would not
   be covered with what was described in the notes for section A?

   --Lisa


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