Re: Requirements for Content Distribution (section 3 comments)

[brad cain <bcain@mediaone.net>]

John Robertson wrote:
> 
> 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.

Yes but I don't think this falls into the "distribution" layer of
the architecture... Isn't this more request routing?

In the known mechanisms draft we do talk about "in-line" request
routing which can happen either:
	1. at the host side via a proxy or layer-7 router
	2. at the server side via a url re-writer 


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

Again, isn't this just the #2 "in-line" case I described above?

I think the distribution requirements of these examples are orthogonal
to the request routing requirements.  I think you have described
the request routing scenarios without the distribution piece.


-brad