Subject: [CDNi] Advanced Use Cases

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 Nov 2011 18:33:15 +0100

Authors of draft-fmn-cdni-advanced-use-cases,

(as a WG co-chair)

The abstract of the document states:
"
  The purpose of this draft is to complement the current CDNi WG use-
  cases with a catalogue of advanced, longer-term CDN interconnection
  use cases. 
"

Also, from looking at the I-D, it seems that some of these advanced use cases are indeed beyond the current scope of the working group:
	* e.g. "The first use case introduces a Caching-CDN interconnection that put emphasis on the in-the network caching mechanism." 
	* e.g. Use case 2 for CDN-CDN interconnection at (very) large scale i.e. "there do exist non-linearities which do not occur at small to medium scale,
  but occur at large scale". "So this proposal aims at recommending that this "cdn-cdn interconnections at large scale" use case be considered in case of WG re-chartering (once the present goals will be reached).
	* e.g. Use Case 4: Dynamic expansion of CDN capacity and geographical reach : "The newly created resources are provided by the network provider but under the control of the CDN provider."
	* e.g. "Relationship between CDNI and Information-Centric Networking"
	
Based on this, would it be an acceptable approach for you guys to:
	* keep progressing this document as a standalone document investigating uses cases beyond current scope, and
	* only potentially feed into ietf-cdni-usecases (and possibly ietf-cdni-requirements) the very specific subset of your document that relates to the current scope of the WG?

Cheers

Francois

On 31 Oct 2011, at 17:38, Theodore Zahariadis wrote:

> Dear Alan,
> 
> I also fully agree with your point. As the timeframe is rather short I think that both the Framework and the Metadata should be built around one document.
> 
> However, the draft we have sent is the result of many discussions, PhC and research done by a large number of companies and participants from 6 project.
> So, I believe it is worth a discussion. Unfortunately, I’ll not be able to participate at this IETF meeting, but our colleague Emile Stephan (Orange) will and he may present the draft.
> Of course there are two options:
> a)      To try to merge the two documents towards a joined WG working document, which could be also the base for the Framework and the Metadata specification or
> b)      Keep the one that you are already working on and just extend/update this one as forward looking one.
> In either case, I will be very happy to help and contribute.
> 
> Best Regards,
> Theodore
> 
> 
> 
> 
> From: Alan Kavanagh [mailto:[email-masked]] 
> Sent: Monday, October 31, 2011 6:03 PM
> To: [email-masked]; 'Kent Leung (kleung)'; 'Mark de Jong'
> Cc: [email-masked]; 'ZhouZhipeng'
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> Hi Theodore
> 
> I do tend to agree with your point, though i would like one Use Case document as the baseline for which the Framework adn Metadata etc use to be built around. I do see the merit in taking on work that should be fullfilled within a given time limit and im all for that as long as we ensure all use cases are captured and not ignored. Im not too picky on where it should be done (current use case or another doc).
> 
> Alan
> 
> From: Theodore Zahariadis [mailto:[email-masked]] 
> Sent: October-30-11 7:29 AM
> To: Alan Kavanagh; 'Kent Leung (kleung)'; 'Mark de Jong'
> Cc: [email-masked]; 'ZhouZhipeng'
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> Dear all,
> 
> I think that a good approach would be to proceed in cdni-use cases to ensure realistic/short-term use cases and then proceed to the advanced use cases that the Future Media Networks (FMN) cluster of projects have submitted under the cdni-advanced-use-cases ID.
> 
> Best Regards,
> Theodore
> 
> 
> From: Alan Kavanagh [mailto:[email-masked]] 
> Sent: Thursday, October 27, 2011 12:04 AM
> To: Kent Leung (kleung); Mark de Jong
> Cc: [email-masked]; ZhouZhipeng
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> So are we defining a limited set of use cases or should we ensure that use cases at the very least ensure that the realistic use cases both deployed today and ones planed are captured in the use cases document?
> 
> Alan
> 
> From: Kent Leung (kleung) [mailto:[email-masked]] 
> Sent: October-26-11 5:02 PM
> To: Mark de Jong; Alan Kavanagh
> Cc: [email-masked]; ZhouZhipeng
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> I also agree with Ben that content adaptation is an optimization that is out of scope.  We have enough to do in the WG already.
> 
> Kent
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark de Jong
> Sent: Wednesday, October 26, 2011 1:21 PM
> To: Alan Kavanagh
> Cc: [email-masked]; ZhouZhipeng
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> Hi Alan,
> 
> As Ben stated the overall discussion right now is about delivery, not on adaptation. It is hard enough to get consensus on the delivery aspect already not to mention your requirement from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first specs. I can imagine this could be a discussion later on but please let us keep the scope of this be clean and transparent. It is of benefit of everyone to get the first specs as fast as possible. Thanks.
> 
> Met vriendelijke groet,
> Kind regards,
> 
> Mark de Jong
> International Business Developer
> Jet-Stream BV
> 
> E-mail: [email-masked]
> Office: +31 (0)50 5261820
> Mobile: +31 (0)6 81108263
> Fax: +31 (0)50 5264214
> 
> - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK
> - Event: Meet us at Online Video Strategies, 19 October, London, UK
> - Event: Meet us at CDN World Summit, 25-28 October, London, UK
> - News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com
> - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure
> 
> - Blog: www.jet-stream.com/blog/
> - VideoExchange: www.vdo-x.net
> - Streamzilla: www.streamzillacdn.com
> - Corporate: www.jet-stream.com
> 
> On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote:
> 
> 
> Ben
> 
> Im assuming then based on your comments below are you suggesting we are going to have a number of versions of the CDN-I Metadata?
> 
> I sympathise with what you are pointing out below and do agree that there is some work to be done, but I still feel that content adaptation is to me a fundamental requirement to what collectively we should address in the CDN-I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one that I know Network Service Providers particularly require.
> 
> Alan
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: October-12-11 1:13 PM
> To: ZhouZhipeng
> Cc: [email-masked]
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> Zhipeng,
> 
> On 12 Oct 2011, at 10:22, ZhouZhipeng wrote:
> 
> Hello Ben,
> The UE may select the content format on the CP web. After that the user only desires to get his selected content.
> But how the content is transferred to the client is not worried by the user.
> The CP may create a special format as required by the user and ask the CDN to deliver to user.
> While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select.
> 
> Lots of things may be possible to do and CDN providers offer many additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and deployable within a short time frame (18-24 months).
> 
> Content transformation/adaptation is not an essential requirement in order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation).
> 
> In my opinion we have enough work to do already without trying to expand the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter.
> 
> In this case, it is nothing related to how the user select formats on CP website.
> So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion).
> 
> As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service.
> Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look.
> 
> I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and control plus content acquisition and content delivery.
> 
> I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process.
> 
> Besides, I like raise a case:
> Given currently BBC recruits CDN providers that may support 10 media formats.
> One candidate is your company, another is CDN-X. The users are located in France.
> So both your company and CDN-X should connect a France CDN provider(CDN-Y).
> If your company's solution is to send 10 streams of different format
> of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation.
> Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower.
> For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams.
> 
> Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price.
> If a CDN provider may not get the contract from CP, how it may say it is not a core functionality.
> 
> What you are describing is a possible optimization that a particular CDN may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter.
> 
> So to repeat my position for a final time: Content adaptation is not a core function required to enable content delivery between interconnected CDNs and therefore given the workload we already have to specify solutions that do address the core functionality required to interconnect CDNs I do not think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions within the timeframe we are being told by operators they needs solutions within.
> 
> Ben
> 
> So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market.
> 
> Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated.
> 
> Br,
> Zhipeng
> 
> 
> 
> 
> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2011 12:19 AM
> To: ZhouZhipeng
> Cc: [email-masked]; [email-masked]
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> Zhipeng,
> 
> On 11 Oct 2011, at 05:16, ZhouZhipeng wrote:
> 
> Ben and Philip,
> I like to respond your concern in this one email:
> 
> Ben,
> I feel what we are now discussing is what is the "core" function of CDN.
> As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system.
> While CDN is used to provide the content delivery service.
> What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service.
> If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN.
> 
> For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias.
> By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711.
> For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right.
> I like to know whether you may accept that my use case is similar to this case above.
> 
> I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request.
> 
> As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types".
> 
> Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery).
> 
> My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO.
> 
> Ben
> 
> A good question is "security" since I have done six years on the DRM
> and like to promote the DRM all around the world:) If the content is needed to be protected, generally you may know all the systems should be granted by the content owner.
> Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also.
> So, trust is not a problem for the media.
> 
> Philip,
> Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case.
> I like to clarify to U that it is important for you operator since it may save investment if the system may support different services.
> For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service.
> But the reality is all operators ask us to provide a system that may support different service systems.
> 
> Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple .
> At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it.
> Of course I like to respond your more concern and comments.
> Thanks.
> Zhipeng
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 10, 2011 11:22 PM
> To: [email-masked]; ZhouZhipeng
> Cc: [email-masked]
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> Ben, Zhipeng, all,
> 
> I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft.
> 
> The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this.
> 
> I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well?
> 
> Scott,
> Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope.
> - a dCDN might for some reason be unwilling to distribute HD?
> - a CSP might want to make sure the dCDN can use HLS encapsulation?
> But these sorts of examples seem to be static policy things (to do
> with the capabilities & preferences of the CDNs & CSP), rather than
> metadata associated with a particular piece of content. In the
> discussion so far, I think negotiation about static policy stuff is
> rather out of scope(?)
> 
> On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive.
> 
> Best wishes
> phil
> 
> 
> Philip Eardley
> Research and Technology Strategy
> 
> This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ Registered in
> England no: 1800000
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ben Niven-Jenkins
> Sent: 10 October 2011 12:04
> To: ZhouZhipeng
> Cc: [email-masked]
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> Colleagues,
> 
> IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is.
> 
> Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered.
> 
> The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content).
> 
> Ben
> 
> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:
> 
> Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct.
> If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy.
> 
> Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation.
> In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT).
> I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection.
> Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft.
> 
> If you have any more question or comments, pls share in this thread.
> Thanks.
> Zhipeng
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Scott Wainner [mailto:[email-masked]]
> Sent: Friday, September 30, 2011 8:02 AM
> To: [email-masked]
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> 
> Section 2.3 Nomadic Users
> This description falls under the category of Geographic Extension
> yet the third paragraph states the case where a different device is
> used in the same CDN coverage area.  The intent of this use case
> needs to be clarified.  Perhaps the use case is trying to address
> the scenario where a Nomadic User-A with an agreement allowing
> access to content from CSP-A via uCDN moves to a dCDN in a different
> region.  The dCDN is allowed to distribute the content of CSP-A to
> User-A; however, not other users in the region of the dCDN are
> allowed to retrieve the content unless they too have such an agreement.
> 
> Section 5.1.3 Content Encoding Restrictions Need to clarify if we're
> talking about the restrictions on the delivery of specific content
> or the restrictions on the ability of a CDN to deliver specific
> content.  I certainly understand the case where a CSP will restrict
> the distribution of content to a "managed path" if such content is
> HD while allowing the content distribution via an un-managed path if
> such content is SD (same could apply to encryption methods, delivery
> methods, etc.).  On the contrary, the dCDN may have its own
> restrictions of blocking the distribution of HD content while
> allowing the distribution of SD content.
> 
> o first bullet makes sense if the dCDN can perform a subset of
> encapsulations for a reference set of media (e.g. HLS, HSS, but not
> DASH) o second bullet makes sense where the dCDN doesn't want to
> offer high bit-rate variants of the media o third bullet make sense
> if the policy addresses QoE but I don't think subscriber
> rights/authorizations apply.
> 
> Section 10 Security Considerations
> 
> Aside from the security considerations WITHIN the uCDN and dCDN, I
> think we can describe this in four contexts:
> 
> a. The relationship between the CSP and the uCDN (the principle contract
> arrangement for distribution)
> b. The relationship between the uCDN and dCDN (the transitive trust
> relationship that extends the contract defined in (a) above) c. The
> relationship between the User and dCDN (the recognition of right to
> download predicated on (b) above) d. The relationship between the
> User and CSP (the contract authorizing the user access to the
> content)
> 
> The user is not interested in the a-b nor the b-c relationship. The
> user is only interested in the transparency and interoperability of
> the security relationship between d-b or d-c to the point that the
> authorization granted in d-a is viable when the delivery is
> initiated via either d-b or d-c.  As an example, the uCDN might use
> URL appended tokens for authentication while dCDN might use URL
> appended hashes.  The user doesn't want to know about the distinct
> methods, but transparency is only afforded if the methods are
> interoperable clearly defined when the delegation for content
> delivery is executed.  Clearly, the choice of authentication method is determined by the respective CDN's.
> 
> Scott
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
> 
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
> 
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Theodore Zahariadis" <[email-masked]>
Date: Fri, 4 Nov 2011 10:52:13 +0200

Dear Francois,

Thanks for the reply. We basically fully agree on the proposed approach.

The idea behind this draft was to provide a placeholder for CDNi use cases
beyond the immediate goals of the current WG charter, but are actively being
investigated by our ongoing research projects (some members of which are
closely involved in the current WG drafts). 

While we don't want to detract from the immediate  concerns of the WG, we
welcome/encourage all comments and contributions to this catalogue, which
can remain as a standard alone document.
 
We'll also check how some of the advanced use case ideas, may feed directly
into ietf-cdni-usecases and ietf-cdni-requirements, while others will remain
as future work, which may provide useful hints as to where some options 
for protocol design, etc. might be left open.

Personally I also believe that at least some issues (e.g. Caching-CDN
interconnection) could be important even in the metadata specification
draft.

Best Regards,
Theodore

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]] 
Sent: Thursday, November 03, 2011 7:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: Advanced Use Cases

(as a WG co-chair)

Also, from looking at the I-D, it seems that some of these advanced use
cases are indeed beyond the current scope of the working group:
	* e.g. "The first use case introduces a Caching-CDN interconnection
that put emphasis on the in-the network caching mechanism." 
	* e.g. Use case 2 for CDN-CDN interconnection at (very) large scale
i.e. "there do exist non-linearities which do not occur at small to medium
scale,
  but occur at large scale". "So this proposal aims at recommending that
this "cdn-cdn interconnections at large scale" use case be considered in
case of WG re-chartering (once the present goals will be reached).
	* e.g. Use Case 4: Dynamic expansion of CDN capacity and
geographical reach : "The newly created resources are provided by the
network provider but under the control of the CDN provider."
	* e.g. "Relationship between CDNI and Information-Centric
Networking"
	
Based on this, would it be an acceptable approach for you guys to:
	* keep progressing this document as a standalone document
investigating uses cases beyond current scope, and
	* only potentially feed into ietf-cdni-usecases (and possibly
ietf-cdni-requirements) the very specific subset of your document that
relates to the current scope of the WG?

Cheers

Francois

On 31 Oct 2011, at 17:38, Theodore Zahariadis wrote:

> Dear Alan,
> 
> I also fully agree with your point. As the timeframe is rather short I
think that both the Framework and the Metadata should be built around one
document.
> 
> However, the draft we have sent is the result of many discussions, PhC and
research done by a large number of companies and participants from 6
project.
> So, I believe it is worth a discussion. Unfortunately, I'll not be able to
participate at this IETF meeting, but our colleague Emile Stephan (Orange)
will and he may present the draft.
> a)      To try to merge the two documents towards a joined WG working
document, which could be also the base for the Framework and the Metadata
specification or
> b)      Keep the one that you are already working on and just
extend/update this one as forward looking one.
> I do tend to agree with your point, though i would like one Use Case
document as the baseline for which the Framework adn Metadata etc use to be
built around. I do see the merit in taking on work that should be fullfilled
within a given time limit and im all for that as long as we ensure all use
cases are captured and not ignored. Im not too picky on where it should be
done (current use case or another doc).
> I think that a good approach would be to proceed in cdni-use cases to
ensure realistic/short-term use cases and then proceed to the advanced use
cases that the Future Media Networks (FMN) cluster of projects have
submitted under the cdni-advanced-use-cases ID.
> So are we defining a limited set of use cases or should we ensure that use
cases at the very least ensure that the realistic use cases both deployed
today and ones planed are captured in the use cases document?
> I also agree with Ben that content adaptation is an optimization that is
out of scope.  We have enough to do in the WG already.
> As Ben stated the overall discussion right now is about delivery, not on
adaptation. It is hard enough to get consensus on the delivery aspect
already not to mention your requirement from content adaptation added to
that, so I agree with Ben we should stick with the delivery aspect for the
first specs. I can imagine this could be a discussion later on but please
let us keep the scope of this be clean and transparent. It is of benefit of
everyone to get the first specs as fast as possible. Thanks.
> Im assuming then based on your comments below are you suggesting we are
going to have a number of versions of the CDN-I Metadata?
> 
> I sympathise with what you are pointing out below and do agree that there
is some work to be done, but I still feel that content adaptation is to me a
fundamental requirement to what collectively we should address in the CDN-I
WG. I do agree with you that content adaptation is an optimization between
CDN's but it's a very important one that I know Network Service Providers
particularly require.
> The UE may select the content format on the CP web. After that the user
only desires to get his selected content.
> While CP may give a HD format content to uCDN and the dCDN may then
transform to the format as the user select.
> 
> Lots of things may be possible to do and CDN providers offer many
additional services on top of the "core" service of content delivery.
However, our objective (based on my interpretation of the CDNI charter) is
to focus on what is necessary to interconnect CDNs to deliver content from a
CSP to an End User that is targeted and deployable within a short time frame
(18-24 months).
> 
> Content transformation/adaptation is not an essential requirement in order
to achieve that aim (we can deliver content from CSPs to End Users via
multiple CDNs without needing or requiring any CDN supports content
adaptation).
> 
> In my opinion we have enough work to do already without trying to expand
the scope of our work to include additional requirements that do not help us
address our core objectives as laid out in the CDNI charter.
> So, it is the CP and user to decide the content format not the CDN(your
assert is not correct and seems you take that assert as your base for the
discussion).
> 
> As for "the core CDN functionality offered by CDNs today", I have ever
raised an email before that your company's webpage has claimed supporting
media transformation and multi-screen service.
> Perhaps, I like asking you list some features that you feel are the core
functionalities by existing main stream CDNs. Thus we may compare and take
deep look.
> 
> I think the core functionality maps pretty well to the CDNI interfaces,
namely: Request Routing, Metadata configuration, log production and control
plus content acquisition and content delivery.
> 
> I guess many people have the experience/knowledge of content related
service. The user and CP only care whether the CDN providers may satisfy
their requirement while not care the internal process. Just as GSM/PSTN
interconnection, the user only care successful interconnection while not
care how the voice is transformed in process.
> of one content to CDN-Y; While CDN-X's solution is to send 1 stream to
CDN-Y while CDN-Y may conduct some adaptation.
> For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in
solution-2, it should only receive 1 stream but need to take transformation
to output 10 streams.
> 
> Which solution is more competitive. it is Solution 1, right. Remember the
price from BBC is same to both your company and CDN-X or BBC would select
one CDN provider with the lower price.
> What you are describing is a possible optimization that a particular CDN
may wish to implement not a core functionality required to enable content
delivery between interconnected CDNs. I can think of many optimizations that
a CDN could implement to differentiate their service but the internal
workings of an individual CDN are out of scope of our charter.
> 
> So to repeat my position for a final time: Content adaptation is not a
core function required to enable content delivery between interconnected
CDNs and therefore given the workload we already have to specify solutions
that do address the core functionality required to interconnect CDNs I do
not think we should be trying to add more work into that workload as it will
only distract us from achieving our goal of producing deployable solutions
within the timeframe we are being told by operators they needs solutions
within.
> 
> Ben
> 
> So, if we all realize that currently the media type is rich, the CDN
providers should survive in the existing ecosystem and support the media
types as required by the market.
> 
> Back to the case of GSM/G.711, it just when concerning the
interconnection, the transformation should at once be solved. Otherwise the
interconnection may not be operated.
> As you say, CDN is used to deliver content. That is absolutely correct
that the delivery capability is the core requirement for CDN system.
> What means service. It should include "time" "location" and "media type",
etc. These features are all the core feature for a service.
> If we only concern "delivering one data block", I am not sure whether the
issues such as "logging" "geographic constraint" are the core of CDN.
> 
> For "without explicit knowledge of what that content actually is ", I am
not sure whether the wording is accurate since generally a CDN may claim it
support different medias.
> By this opportunity, I like to share a use case: a call from a GSM phone
to a PSTN telephone, the voice stream should be transformed from GSM voice
to G.711.
> For the user, he does not need to know what type of data has been
transferred, but the operator has done some work to interconnect two
systems, right.
> I don't think your use case is similar to the analogy of mobile networks
being interconnected to PSTN networks. In the case of content delivery the
negotiation is done between the User/Client and the Content Provider and the
CDN is just used to execute/perform the delivery that has been negotiated.
The CDN is not involved in the decision making of what representations the
Content Provider decides to offer to the User/Client or in what
representations the User/Client decides to request.
> 
> As for you said selecting media by the "portal", you may see the way "
uCDN delivers multiple media streams to dCDN" is not good than "uCDN
delivers one media stream to dCDN and dCDN takes some adaptation to support
multiple media types".
> 
> Now what you're talking about is an optimisation, not a core function
required to actually deliver the content (and report, bill, etc. for that
delivery).
> 
> My position is that we should focus on how to enable the interconnection
of the core CDN functionality offered by CDNs today (which is also my
interpretation of the scope of the CDNI working group as expressed in its
charter) because doing so is a significant piece of work in itself. Let's
not start trying to add in additional functionality beyond what the majority
of CDNs support today as that will just delay us getting usable
specifications into the market in a timely fashion IMO.
> and like to promote the DRM all around the world:) If the content is
needed to be protected, generally you may know all the systems should be
granted by the content owner.
> Here I also like to clarify that not only the media itself but the
information related to service itself (such as the geographic constraint)
should be protected also.
> Thank you that you feel Content Adaption is an issue for "Requirements"
but I do not know why it is not for Use case.
> I like to clarify to U that it is important for you operator since it may
save investment if the system may support different services.
> For us vendor, we are happy operator may install a system for the mobile
service and another system for the FBB service.
> At least the Use case and Requirement are informational to be referred in
future work. So I do really feel you may accept it.
> The key question is whether we want the CDNI interfaces to be able to cope
with a scenario where (say) HD/SD conversion is done in the dCDN & to signal
about this.
> 
> I think that coping with this scenario is a second order requirement, ie
we should not worry about it in the initial standards-track work. I don't
know, did we ever decide whether the Use cases doc is restricted to
"initial" scenarios, or whether it's all-encompassing, ie covering "future"
scenarios as well?
> On security considerations, an interesting question is whether trust is
transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN
trusts dCDN doesn't mean that the CSP automatically trusts the dCDN.
However, i suspect this can get arbitrarily complex - so one possibility is
to say that we will only handle cases where the trust is transitive.
> This email contains BT information, which may be privileged or
confidential. It's meant only for the individual(s) or entity named above.
If you're not the intended recipient, note that disclosing, copying,
distributing or using this information is prohibited. If you've received
this email in error, please let me know immediately on the email address
above. Thank you. We monitor our email system, and may record your emails.
> IMO Section 5.1.3 should be removed from the Use Cases draft. Content
Adaptation (i.e. taking in a content item in one format and transforming it
to another format or representation) is not a "core" function of a CDN which
typically delivers the content that is requested without explicit knowledge
of what that content actually is.
> 
> Let's not forget that in building an end to end content service the CDN is
only one component and is the component tasked with executing the delivery
of a specific representation (version/copy/format etc.) of the selected
content not the component tasked with deciding (or applying policy) on which
version/copy/representation of content should be delivered.
> 
> The decision as to which version/copy/representation to offer and allow to
be delivered to a given device/user is implemented outside of the CDN (e.g.
by the "portal" where the user first makes their content selection prior to
the CDN becoming involved in the delivery of the selected content).
> Following Scott's comments on section 5.1.3, I feel Scott's description on
the use case of HD and SD is not exactly correct.
> If one movie has two formats of HD and SD, then we have two content with
different identifier. In DRM scope, the basic unit is a content copy.
> 
> Here the first bullet "a subset of encodings deliverable to specific
devices," has listed the case of content adaptation.
> In last month, I have contacted the Authors of this document and taken
some email exchanges with Grant and Philip (BT).
> I have shown BT with some information that I know in this case and area to
explain the content flexibility is currently a basic requirement for CDN
service and related negotiation is needed in the CDN interconnection.
> Meanwhile, I should also invite you in this group raising your comments or
questions on this case since I hope my use case may be incorporated in the
use case draft.

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 4 Nov 2011 10:00:59 +0100

> Thanks for the reply. We basically fully agree on the proposed approach.

Great. So we have a plan. 
Tx
Francois