Subject: [CDNi] New Version Notification for draft-davie-cdni-framework-00.txt

From: Bruce Davie <[email-masked]>
Date: Tue, 5 Jul 2011 08:44:53 -0400

This draft may be of interest to the CDNI WG. 

If you have comments, please copy them to the CDNI list.

Bruce Davie

Begin forwarded message:

> From: [email-masked]
> Date: July 1, 2011 6:35:23 PM EDT
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: New Version Notification for draft-davie-cdni-framework-00.txt
> 
> A new version of I-D, draft-davie-cdni-framework-00.txt has been successfully submitted by Bruce Davie and posted to the IETF repository.
> 
> Filename:	 draft-davie-cdni-framework
> Revision:	 00
> Title:		 Framework for CDN Interconnection
> Creation date:	 2011-07-01
> WG ID:		 Individual Submission
> Number of pages: 47
> 
> Abstract:
>   This document presents a framework for Content Distribution Network
>   Interconnection (CDNI).  The purpose of the framework is to provide
>   an overall picture of the problem space of CDNI and to describe the
>   relationships among the various components necessary to interconnect
>   CDNs.  CDN Interconnection requires the specification of several
>   interfaces and mechanisms to address issues such as request routing,
>   metadata exchange, and the acquisition of content by one CDN from
>   another.  The intent of this document is to outline what each
>   interface needs to accomplish, and to describe how these interfaces
>   and mechanisms fit together, while leaving their detailed
>   specification to other documents.
> 
> 
> 
> 
> 
> The IETF Secretariat

---

From: Kevin J Ma <[email-masked]>
Date: Thu, 7 Jul 2011 03:30:20 -0400

Hi Bruce,

  The draft looks good and it reads well.  I had a couple comments:

  Section 2 focuses on redirection, but does not discuss transparent
  proxying.  It probably does not make sense in geo-footprint or
  capacity offload cases, but might certain resiliency cases benefit
  from not redirecting, e.g., if network interruptions are transient?

  In Section 3.2, though there is a note in the first paragraph about
  the use of HTTP redirection inside uCDN and dCDN, it is perhaps
  worth mentioning more explicitly that steps 3/4/5 and 7/8/9 may be
  combined?  The use of intra-CDN HTTP redirects is not necessarily
  germane to CDNI, but the additional steps could be construed to
 imply that HTTP redirects are inherently more complex than DNS?

  In Section 3.2.1, there is an allusion to a solution to the cookie
  problem, possibly in a future version of the draft.  Section 5.2 of
  draft-peterson-cdni-strawman-01 discusses a possible solution.  Is
  the intent to roll something similar into the framework document?

  In Section 3.7, prepositioning is shown as a notification to the
  dCDN which then pulls the content from the uCDN.  Could there be a
  case where the uCDN might push content to the dCDN?

  In section 4.5, in response to the question of metadata vs control,
  I had interpreted metadata as affecting distribution, i.e., things
  checked on each end user request, e.g., content sunrise/sunset,
  geo-restrictions, etc., whereas control was for actions originating
  from the CSP or uCDN, e.g., purge, pre-positioning, etc.?

  In Section 5, do you see an additional case whereby the CSP could
  use the CDNI interfaces for interacting with the uCDN rather than
  having to rely on interfaces outside the scope of CDNI, i.e., where
  the CSP has a management agent (MA) for accessing the control,
  metadata, and logging interfaces, in order to manage distribution,
  while leaving the request routing to the uCDN or CDN exchange?

   #####################################       ##################
   #                                   #       #                #
   #       Organization A              #       # Organization B #
   #                                   #       #                #
   #     --------       -------------  #       #  -----------   #
   #    /   CSP  \     /   uCDN(MA)  \ #       # /   uCDN    \  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  | C  |==========CDNI=====>| C  |   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  | L  |==========CDNI=====>| L  |   |  #
   #    |        |*****|  +----+     | #       # |  +----+   |  #
   #    |        |     |             | #       # |  +----+   |  #
   #    |        |     |             | #       # |  | RR |   |  #
   #    |        |     |             | #       # |  +----+   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  | D  |==========CDNI=====>| D  |   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    \        /     \             / #       # \           /  #
   #     --------       -------------  #       #  -----------   #
   #                                   #       #                #
   #####################################       ##################

thanx!

--  Kevin J. Ma

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Davie
Sent: Tuesday, July 05, 2011 8:45 AM
To: [email-masked]
Subject: [CDNi] New Version Notification for draft-davie-cdni-framework-00.txt

Bruce Davie

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Date: July 1, 2011 6:35:23 PM EDT
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-davie-cdni-framework-00.txt

Abstract:

The IETF Secretariat

---

From: He Xiaoyan <[email-masked]>
Date: Fri, 08 Jul 2011 16:29:12 +0800

Hi Bruce,

Some comments/questions on this well worked and valuable draft:

1.       Regarding the reference model of figure 1, as a delivery node in a
downstream CDN may contact the RR of an Upstream CDN such as step 8 showed
in figure 3.

An interface between these two blocks in the figure 1 should be added.

2. In the context of CDNi, a content provider (CP) contracts only with an
upstream CDN, but not multiple CDNs for content delivery acceleration. The
upstream CDN generally would like to keep the CP relationship exclusive, and
won’t expose it to connected CDNs. What’s your view on this, could there a
new paragraph be added in this framework draft to address this?  I can make
a proposal on this if it is thought valuable. 

3.       Regarding the example on recursive redirection, several comments as
follows:

*          It is not mentioned in step2 under figure 4, how the RR of an
upstream CDN finds the address of the RR of its downstream CDN, I think this
should be specified.

*  It is also not mentioned the factors based on what the downstream CDN
will select the delivery node for the end user, as this will affect the
parameters conveyed via the request router interface, I think description on
such actions should be specified.

* On the disadvantages of recursive redirection, exposing more internal
structure e.g. request routing and edge caches is listed. I can not
understand this clearly, could you give more explanation here? As in the
iterative redirection, a delivery node of a downstream CDN can also ‘see’
the address of the RR of the Upstream CDN. Which to me means  the edge
caches and RR of each CDN also expose to its peers.

* The protocols used in queries between the two RRs are not specified, the
existing protocols used could be HTTP and DNS, some of my colleagues and I
also drafted a contribution on recursive
redirection(http://www.ietf.org/internet-drafts/draft-xiaoyan-cdni-requestro
uting-01.txt), if it is ok for you, I can make some proposal on this part
and merge some text of my draft into this framework draft.

4.       HTTP and DNS based iterative redirection, Recursive redirection are
all mentioned in this document, do you have any preference on these methods
selection? I think some guideline or principle on method selection should be
specified, such as the method for a content could be arranged by the CSP to
the upCDN and then to the downCDN? 

Thanks.

Best Regards

Xiaoyan(Susan) He

  _____  

发件人: [email-masked] [mailto:[email-masked]] 代表 Bruce
Davie
发送时间: 2011年7月5日 20:45
收件人: [email-masked]
主题: [CDNi] New Version Notification for draft-davie-cdni-framework-00.txt

Bruce Davie

Begin forwarded message:

To: [email-masked]

A new version of I-D, draft-davie-cdni-framework-00.txt has been
successfully submitted by Bruce Davie and posted to the IETF repository.

Abstract:

The IETF Secretariat

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 8 Jul 2011 11:23:32 -0400

Hi Xiaoyan,

I had a quick comment your second question, with respect to multiple CDNs;
I wanted to clarify what was meant by "but not multiple CDNs"?

> 2. In the context of CDNi, a content provider (CP) contracts only with an upstream CDN, but not multiple CDNs for content delivery acceleration.

I agree that CPs may not have business relationships with all of the CDNs
involved in delivering their content (i.e., they may contract with uCDNs,
but not with all dCDNs), but I do not think that we should rule out CPs
having business relationships with multiple CDNs (e.g., multiple uCDNs and
some dCDNs, which may also be uCDNs).  I interpreted Figure 11 in Section 5
to support this view?  This does bring up a separate question of how CDNs
optimize delivery of content which is spread across multiple uCDNs, but
that is probably beyond the initial scope of CDNI, as Bruce alludes to?

thanx!

--  Kevin J. Ma

From: [email-masked] [mailto:[email-masked]] On Behalf Of He Xiaoyan
Sent: Friday, July 08, 2011 4:29 AM
To: 'Bruce Davie'; [email-masked]
Subject: [CDNi] 答复: New Version Notification for draft-davie-cdni-framework-00.txt

Hi Bruce,

1.   Regarding the reference model of figure 1, as a delivery node in a downstream CDN may contact the RR of an Upstream CDN such as step 8 showed in figure 3.
An interface between these two blocks in the figure 1 should be added.

2. In the context of CDNi, a content provider (CP) contracts only with an upstream CDN, but not multiple CDNs for content delivery acceleration. The upstream CDN generally would like to keep the CP relationship exclusive, and won’t expose it to connected CDNs. What’s your view on this, could there a new paragraph be added in this framework draft to address this?  I can make a proposal on this if it is thought valuable.

3.   Regarding the example on recursive redirection, several comments as follows:
  It is not mentioned in step2 under figure 4, how the RR of an upstream CDN finds the address of the RR of its downstream CDN, I think this should be specified.

•  It is also not mentioned the factors based on what the downstream CDN will select the delivery node for the end user, as this will affect the parameters conveyed via the request router interface, I think description on such actions should be specified.

• On the disadvantages of recursive redirection, exposing more internal structure e.g. request routing and edge caches is listed. I can not understand this clearly, could you give more explanation here? As in the iterative redirection, a delivery node of a downstream CDN can also ‘see’ the address of the RR of the Upstream CDN. Which to me means  the edge caches and RR of each CDN also expose to its peers.

• The protocols used in queries between the two RRs are not specified, the existing protocols used could be HTTP and DNS, some of my colleagues and I also drafted a contribution on recursive redirection(http://www.ietf.org/internet-drafts/draft-xiaoyan-cdni-requestrouting-01.txt), if it is ok for you, I can make some proposal on this part and merge some text of my draft into this framework draft.

4.   HTTP and DNS based iterative redirection, Recursive redirection are all mentioned in this document, do you have any preference on these methods selection? I think some guideline or principle on method selection should be specified, such as the method for a content could be arranged by the CSP to the upCDN and then to the downCDN?

Thanks.

Best Regards
Xiaoyan(Susan) He
________________________________
发件人: [email-masked] [mailto:[email-masked]] 代表 Bruce Davie
发送时间: 2011年7月5日 20:45
收件人: [email-masked]
主题: [CDNi] New Version Notification for draft-davie-cdni-framework-00.txt

Bruce Davie

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Bruce Davie <[email-masked]>
Date: Fri, 8 Jul 2011 11:53:32 -0400

>   from not redirecting, e.g., if network interruptions are transient?

Well, I think we want to leave transparent proxies off the table, not least because of this statement in the Charter:
"In particular, the WG will not define: 
[...]
- Support for Transparent Caching across CDNs. "

That said, we may be able to add something about the fact that a uCDN always has the option of not redirecting whenever it chooses.

>  imply that HTTP redirects are inherently more complex than DNS?

Yes, we talked about this among the authors actually. The reason for putting in those extra steps is for contrast between iterative and recursive methods. But I agree we could add a note of clarification here.

>   the intent to roll something similar into the framework document?

Yes, the careful reader will have noticed that a lot of text made its way already from the strawman to the framework (along with the co-author). We'll make a note to address this issue more fully in the next version.

>   case where the uCDN might push content to the dCDN?

Well, it depends on how you define "push". As I see it, the CI PREP at the start of the example effectively initiates a push of data, but we rely on dCDN to issue the HTTP GET so that data actually flows. Certainly I can think of other ways of doing it, and of course there is no way the framework can exhaustively list all options (especially since the acquisition protocol is out of scope, so we are using an obvious available protocol).

I guess the best resolution I can think of here is to say "This is not the only way to do it". (This is a pretty general issue with the Framework, as I see it - we're trying to explain things by example but I don't think we can ever cover all possibilities that way.)

>   from the CSP or uCDN, e.g., purge, pre-positioning, etc.?

The reason that we have the sort of open ended text there at present is because we don't really seem to have this distinction completely nailed down as either an author team or a WG. While CDNI distribution metadata is pretty well defined in the Problem Statement, you can still achieve quite a bit of the distribution control using the control interface. So I think this is a topic for discussion at the WG.

>   while leaving the request routing to the uCDN or CDN exchange?

I guess what you are describing here seems similar in intent to what we showed in Figure 12, with the removal of the request routing piece. We certainly do see cases where some subset of the CDNI interfaces might be used (e.g. a CDNI exchange might only do a subset of the interfaces). I feel in this case, you are asking about the validity of using CDNI interfaces for a CSP-uCDN interface, which feels to me to be out of scope for a WG focused on the inter-CDN interfaces (even if it would be nice to have this ability).

Thank you

Bruce

---

From: Kevin J Ma <[email-masked]>
Date: Fri, 8 Jul 2011 12:35:33 -0400

Hi Bruce,

  The additional clarifications and caveats alluded to below sound good.

  With respect to the last point:

  > I guess what you are describing here seems similar in intent to what we showed in Figure 12, with the removal of the request routing piece. We certainly do see cases where some subset of the CDNI interfaces might be used.

 I was thinking more about an opposite to Figure 13.  I guess I just wanted
 to clarify if any subset is acceptable (e.g., just C/L/D), or if there is a
 specific distinction for what is shown in Figure 13 (i.e. only RR).  If
  the latter, then it might be helpful to explain the distinction further
  (e.g., is RR always required)?

thanx.

From: Bruce Davie [mailto:[email-masked]]
Sent: Friday, July 08, 2011 11:54 AM
To: Kevin J Ma
Cc: [email-masked]
Subject: Re: [CDNi] New Version Notification for draft-davie-cdni-framework-00.txt

Hi Bruce,

thanx!

Thank you

Bruce

--  Kevin J. Ma

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bruce Davie
Sent: Tuesday, July 05, 2011 8:45 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] New Version Notification for draft-davie-cdni-framework-00.txt

Bruce Davie

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Bruce Davie <[email-masked]>
Date: Fri, 8 Jul 2011 13:02:50 -0400

> Some comments/questions on this well worked and valuable draft:

Thanks for the feedback. I'm going to make one preliminary comment because I think it will apply to several comments below (and maybe some future comments by others).

We're really trying hard not to turn this doc into either the requirements document or one of the interface specs. I was inspired by one comment at the BOF "How is anyone going to figure out how all these pieces fit together"? So the framework tries to answer that question. It isn't a spec for any particular interface, it doesn't even set the requirements for any interface. It tries to show (by examples and deployment scenarios mostly) how the pieces work together. 

> An interface between these two blocks in the figure 1 should be added.

The reference model is a verbatim copy from the Problem Statement, so I'll defer any changes to the authors of that doc. But I think this comment may require adding a bit more detail to the reference model than is really needed.  

> 2. In the context of CDNi, a content provider (CP) contracts only with an upstream CDN, but not multiple CDNs for content delivery acceleration. The upstream CDN generally would like to keep the CP…

In fact, I fully expect that a CSP may contract with multiple uCDNs, just as today's CSPs contract with multiple CDNs in the absence of CDNI. It may be worth making the point explicitly.

Also, we do expect that there is generally no relationship between a CSP and dCDN (subject to the comment above), we can certainly make this point more explicitly. 

> Ÿ          It is not mentioned in step2 under figure 4, how the RR of an upstream CDN finds the address of the RR of its downstream CDN, I think this should be specified.

Right, I was assuming that the RRI interface gets bootstrapped somehow as described in draft-jenkins-cdni-problem-statement, but we can make this more explicit.

>  
> Ÿ  It is also not mentioned the factors based on what the downstream CDN will select the delivery node for the end user, as this will affect the parameters conveyed via the request router interface, I think description on such actions should be specified.

I think the dCDN should be able to make autonomous decisions about which delivery node to choose for the end user. However, you are correct that if too little information about the user is provided, that will make it hard for dCDN to do a good job. I would see this discussion as appropriate for other documents such as Requirements or the RRI spec itself. Nevertheless, you make a good point that should be captured somewhere.

>  
> Ÿ On the disadvantages of recursive redirection, exposing more internal structure e.g. request routing and edge caches is listed. I can not understand this clearly, could you give more explanation here? As in the iterative redirection, a delivery node of a downstream CDN can also ‘see’ the address of the RR of the Upstream CDN. Which to me means  the edge caches and RR of each CDN also expose to its peers.

Iterative redirection does not allow uCDN to see much of the structure of dCDN, because he just sends the user on to talk to the RR of dCDN. By contrast, recursive redirection has dCDN providing address of his delivery nodes back to uCDN. I agree this should be more clear than it is.

>  
> Ÿ The protocols used in queries between the two RRs are not specified, the existing protocols used could be HTTP and DNS, some of my colleagues and I also drafted a contribution on recursive redirection(http://www.ietf.org/internet-drafts/draft-xiaoyan-cdni-requestrouting-01.txt), if it is ok for you, I can make some proposal on this part and merge some text of my draft into this framework draft.

No, this should be in the draft the specifies  the RRI, I don't want to start specifying those interfaces in detail inside the framework, as noted above.

> 4.       HTTP and DNS based iterative redirection, Recursive redirection are all mentioned in this document, do you have any preference on these methods selection? I think some guideline or princip…

It depends which author you talk to :-) We've tried hard to lay out the design space in an even handed way at this point (your question suggests we succeeded). Picking a favorite may not be appropriate, I certainly don't want to do so at this time.

Bruce

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 8 Jul 2011 20:43:12 +0000

> I do not think that we should rule out CPs having business relationships with multiple CDNs (e.g., multiple uCDNs and some dCDNs, which may also be uCDNs).

I agree. Some CPs have existing relationships with multiple CDNs today.

With CDNI, the relationships may be quite complex: a particular CP may have a direct relationship with both CDN Provider A and CDN Provider B as uCDNs, and might have an indirect relationship with CDN Provider A as an offloading dCDN for CDN Provider B (and vice versa).

CDNI should avoid dictating these future business arrangements.

> This does bring up a separate question of how CDNs optimize delivery of content which is spread across multiple uCDNs, but that is probably beyond the initial scope of CDNI, as Bruce alludes to?

I would tend to agree that it is too early to optimize across uCDNs. It may be more a matter of business agreements rather than simple technology.

-- Rich

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin J Ma
Sent: Friday, July 08, 2011 11:24 AM
To: He Xiaoyan; 'Bruce Davie'; [email-masked]
Subject: Re: [CDNi] 答复: New Version Notification for draft-davie-cdni-framework-00.txt

Hi Xiaoyan,

thanx!

--  Kevin J. Ma

Hi Bruce,

Thanks.

Best Regards
Xiaoyan(Susan) He

Bruce Davie

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: He Xiaoyan <[email-masked]>
Date: Mon, 11 Jul 2011 14:55:46 +0800

Hi Kevin, Richard at all,

Apologize for my ambiguously statement in last email.

For the words” multiple CDNs”, it means multiple dCDNs involved in
delivering a content in the context of CDNi which contrast to the specific
uCDN.

I did not mean ruling out CPs having business relationships with multiple
CDNs. What I wanted to express is that under the circumstance of CDNI, for a
delivery chain of a content, there should no relationship between a CP and
the involved dCDNs, and furthermore, the upstream CDN generally would like
to keep the CP relationship exclusive, and won’t expose it to its connected
dCDNs.   

Of course, the CP may have business relationships with multiple CDNs, they
all are interpreted as uCDNs and hence multiple delivery chains may be
involved. This is not the case 

Relative to the question I asked.

Hope this helps.

Thanks. 

Best Regards

Xiaoyan(Susan) He

  _____  

发件人: Kevin J Ma [mailto:[email-masked]] 
发送时间: 2011年7月8日 23:24
收件人: He Xiaoyan; 'Bruce Davie'; [email-masked]
主题: RE: [CDNi] 答复: New Version Notification for
draft-davie-cdni-framework-00.txt

Hi Xiaoyan,

> 2. In the context of CDNi, a content provider (CP) contracts only with an
upstream CDN, but not multiple CDNs for content delivery acceleration.

thanx!

--  Kevin J. Ma

From: [email-masked] [mailto:[email-masked]] On Behalf Of He
Xiaoyan
Sent: Friday, July 08, 2011 4:29 AM
To: 'Bruce Davie'; [email-masked]
Subject: [CDNi] 答复: New Version Notification for
draft-davie-cdni-framework-00.txt

Hi Bruce,

Thanks.

Best Regards

Xiaoyan(Susan) He

  _____  

Bruce Davie

Begin forwarded message:

To: [email-masked]

Abstract:

The IETF Secretariat

---

From: Bruce Davie <[email-masked]>
Date: Mon, 25 Jul 2011 17:30:13 -0400

Kevin,
 I realized I never got back to you on your last question, but here is a quick (i.e. possibly half-baked) answer for now. In general, I think that using any subset of the interfaces is acceptable, as long as you meet the needs of some use case. So, as far as the framework goes, I would say that the examples in this section (Section 5) and definitely not meant to be exhaustive, and we can make that clearer in the next rev.

Bruce

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 25 Jul 2011 21:12:08 -0400

understood.  thanx.

From: Bruce Davie [mailto:[email-masked]]
Sent: Monday, July 25, 2011 5:30 PM
To: Kevin J Ma
Cc: [email-masked]
Subject: Re: [CDNi] New Version Notification for draft-davie-cdni-framework-00.txt

Kevin,

Bruce

Hi Bruce,

thanx.

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Jul 2011 09:41:33 -0400

Does that mean that this document is for discussion purposes, but we have no plans of publishing it as an RFC? That impacts the level of review. For the former, it gives us a framework to say, "Yes, this is possible." For the latter, it means we need to dig out all of the nits.

---

From: Bruce Davie <[email-masked]>
Date: Thu, 28 Jul 2011 10:08:58 -0400

Eric,
One of the planned deliverables for the WG is a Framework, which would be published as an RFC. It would be an informational RFC. I hope that this draft might be a starting point for such an RFC. The WG will have to comment on that. However, I think all of the following would apply to the Framework: not a requirements doc (we have one of those) and not an interface spec (they are listed as separate deliverables of the WG).

I hope we can talk today about what should and should not be in the Framework.

Bruce

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 28 Jul 2011 14:18:14 +0000

> Does that mean that this document is for discussion purposes, but we have no plans of publishing it as an RFC? That impacts the level of review.

The Framework document is an item in the CDNI charter.

>From http://datatracker.ietf.org/wg/cdni/charter/:

- A "framework" document providing a description of the different 
components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" 
discussing the security concerns and threats, the trust model and 
privacy issues specific to CDNI. 
...
Jun 2012  Submit CDNI framework to IESG as Informational  

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
Sent: Thursday, July 28, 2011 9:42 AM
To: Bruce Davie
Cc: [email-masked]
Subject: Re: [CDNi] ??: New Version Notification for draft-davie-cdni-framework-00.txt

> We're really trying hard not to turn this doc into either the requirements document or one of the interface specs. I was inspired by one comment at the BOF "How is anyone going to figure out how al…

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 28 Jul 2011 13:46:22 -0700

Hi Bruce.

Since the framework draft provides an overview of CDNI
architecture/model, it might be useful to provide some description of
the CDNI components for Upstream CDN and Downstream CDN, as well as
non-CDNI components in the diagram for completeness.  Also, describe the
functional purpose of the CDNI Interfaces.  The non-CDNI interfaces
should also be covered for completeness.  This information can be
inserted in Sect 1 where the Reference Model is shown.

I think the document can be structured based on the CDNI functions and
CDNI interfaces.  The Building Blocks section is really part of Request
Routing operation.  I'd suggest that CDNI operations can be organized
based on Request Routing, Metadata distribution, Logging, Control.  So
it doesn't come across that we are favoring Request Routing even though
that is a critical part of CDNI.  For each:

Request Routing: DNS, HTTP, Iterative, Recursive, Dynamic, Prepositioned

Metadata: Geo-blocking, availability windows, access control (URI
signature, whitelist/blacklist), prepositioned/dynamic, deletion,
request mapping to uCDN acquisition

Logging: Events such as content delivery, distribution, deletion, CDNI
request routing, etc.

Control: Deletion, etc.

I would consider moving the Deployment Models to the front before
getting into the CDNI Operations details.  This allows the reader to
digest first the CDNI components and interfaces and interactions between
them, then deployment models, and then how it all come together in
operations.  The flow may be better this way from the readability
perspective.

Just a thought ... J

Kent

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Davie (bdavie)
Sent: Tuesday, July 05, 2011 5:45 AM
To: [email-masked]
Subject: [CDNi] New Version Notification
fordraft-davie-cdni-framework-00.txt

Bruce Davie

Begin forwarded message:

To: [email-masked]

Abstract:

The IETF Secretariat