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

From: Bruce Davie <[email-masked]>
Date: Thu, 14 Jul 2011 15:50:40 -0400

I suppose the question of how much detail to put in this draft is a bit of a judgement call. I certainly didn't want to include details of protocols that are not yet specified at all and which will get full drafts dedicated to them in the near future (like RRI). 

It could possibly be argued that we've included a bit too much detail on the redirection methods using DNS and HTTP, but it seemed worthwhile at this stage to document the different redirection procedures in some detail, as they are not currently documented anywhere else (except, in some cases, in draft-peterson-cdni-strawman). It might make sense for those details to move somewhere else eventually, as long as the overall picture can be grasped by someone reading the Framework. 

Bruce

On Jul 11, 2011, at 4:01 AM, He Xiaoyan wrote:

> Hi Bruce,
> > 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. 
> > 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.
>  
> I can understand details of a CDNI interface should be defined in the dedicated specs, but could you clarify more on the criteria of this draft on determining which protocols/messages involved in CDNI procedures should be enumerated but which should not be.  As in the examples of this doc, some HTTP and DNS messages even with the URL and special domain names have been explicitly enumerated, but some as you mentioned should be leaved to the dedicated interfaces specs.
> Thanks.  
>  
> Best Regards
> Xiaoyan(Susan) He
> 发件人: Bruce Davie [mailto:[email-masked]] 
> 发送时间: 2011年7月9日 1:03
> 收件人: He Xiaoyan
> 抄送: [email-masked]
> 主题: Re: 答复: [CDNi] New Version Notification for draft-davie-cdni-framework-00.txt
>  
>  
> 
> On Jul 8, 2011, at 4:29 AM, He Xiaoyan wrote:
> 
> 
> Hi Bruce,
> 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. 
> 
> 
>  
> 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.
>  
> 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 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.
>  
> 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. 
> 
> 
>  
> 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.
>  
>  
> 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 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?
>  
>  
> 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
>  
>  
>  
>  
> 
> 
>  
> 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
>  
> 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
>  
>