Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

From: Scott Wainner <[email-masked]>
Date: Tue, 01 Nov 2011 15:47:25 -0400

Perhaps the answer to this dilemma is very simple ...

In the CDNI interface, we simply offer a binary option of the following:

0) content may not be adapted
1) content may be adapted

I suspect that the majority of the CDNI relationships will set the flag 
to "0" indicating the asset is not allowed to be adapted.  The reason 
can be anything including contractual between the CP and uCDN, the 
content is encrypted, the uCDN preference, etc.

Now if the flag is set to "1", it is incumbent upon the dCDN to figure 
out how to modify the content without changing the URL references, etc.

Scott

On 10/27/11 7:22 AM, Woundy, Richard wrote:
> >In your companyâEUR^(TM)s website, I just find some information
>
> I have to step in as co-chair here.
>
> The goal of this WG is not to align vendor product roadmaps, or to 
> equalize all vendor offerings, or to specify the entire CDNI 
> ecosystem. The goal of this WG is to enable the interconnection and 
> interoperation of two or more CDNs, within the bounds of the CDNI wg 
> charter.
>
> It is OK to have a discussion about whether content adaptation needs 
> to be performed by the dCDN, since that decision impacts the uCDN-dCDN 
> interface. So let's find a productive way to discuss this on the 
> mailing list, and to close the discussion by IETF 82 (if not sooner).
>
> Can someone describe real-life examples where downstream CDN (or edge 
> cache-based) content adaptation is needed today in a production 
> environment, or shortly? Not merely a feature in a vendor's product 
> materials?
>
> Speaking as an individual, I can find a lot of examples where 
> downstream content adaptation is not needed, and any adaptation is 
> really part of the CP - uCDN interface (which is out of the scope of 
> our charter).
>
> -- Rich
>
>
> *From*: ZhouZhipeng [mailto:[email-masked]]
> *Sent*: Thursday, October 27, 2011 03:45 AM
> *To*: Mark de Jong <[email-masked]>; Alan Kavanagh 
> <[email-masked]>
> *Cc*: [email-masked] <[email-masked]>
> *Subject*: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Hello Mark,
>
> Nice to meet you on line.
>
> In your companyâEUR^(TM)s website, I just find some information that 
> addresses âEURoe Vodafone subscribers complained about video 
> performance.âEUR?
>
> See:
>
> http://www.jet-stream.nl/search/?search=transcoding
>
> Dear all in this group,
>
> In last few days, except the public email discussions I have contacted 
> with some people and discussed with my own colleagues of all details 
> on this issue.
>
> First, although the market requirement for it is very important, I 
> feel IâEUR^(TM)d better show up more information on the procedure 
> involved. I have explained many times that to support content 
> adaptation is rather simple while the wording is not enough.
>
> I am busy making some contributions on this and plan to upload to ETSI 
> meeting and IETF CDNI.
>
> By these work  I feel the people may catch a whole view on this issue.
>
> Second, for that functionality, in implementation, if some entity does 
> not choose to support it, it may be ok. Since it may be negotiated 
> between two CDNs.
>
> If dCDN does not support that, it may be the uCDN responsible to 
> complete the transcoding and deliver the content of multiple formats 
> and rates to dCDN.
>
> Third, although CDNI is a new architecture, while the content 
> operating has been existed for years. As I know the content from USA 
> to the downstream operator is transferred on one copy and the 
> downstream operator will handle the transcoding.
>
> Perhaps, the content adaptation is more on the mobile operating. But I 
> feel currently most operator will be a all service operator. And for 
> the CDN providers, it may be better to support all kinds of service.
>
> Besides, I like say that the technology on this topic has been for 
> many years and has been rather mature, even some items in ietf such as 
> rfc3507 icap. So from the technique point of view, it is a nature 
> action to be involved in CDN interconnection.
>
> Thanks.
>
> Zhipeng
>
> *From:*Mark de Jong [mailto:[email-masked]]
> *Sent:* Thursday, October 27, 2011 4:21 AM
> *To:* Alan Kavanagh
> *Cc:* Ben Niven-Jenkins; ZhouZhipeng; [email-masked]
> *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] <mailto:[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 <http://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/ <http://www.jet-stream.com/blog/>
>
> -*VideoExchange:***www.vdo-x.net <http://www.vdo-x.net>
>
> -*Streamzilla:***www.streamzillacdn.com <http://www.streamzillacdn.com>
>
> -*Corporate:*www.jet-stream.com <http://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]> 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: October-12-11 1:13 PM
> To: ZhouZhipeng
> Cc: [email-masked] <mailto:[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] <mailto:[email-masked]>;
>     [email-masked] <mailto:[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]>
>         [mailto:[email-masked]]
>
>         Sent: Monday, October 10, 2011 11:22 PM
>
>         To: [email-masked] <mailto:[email-masked]>;
>         ZhouZhipeng
>
>         Cc: [email-masked] <mailto:[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]>
>         [mailto:[email-masked]] On Behalf
>
>         Of Ben Niven-Jenkins
>
>         Sent: 10 October 2011 12:04
>
>         To: ZhouZhipeng
>
>         Cc: [email-masked] <mailto:[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] <mailto:[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] <mailto:[email-masked]>
>
>             https://www.ietf.org/mailman/listinfo/cdni
>
>         _______________________________________________
>
>         CDNi mailing list
>
>         [email-masked] <mailto:[email-masked]>
>
>         https://www.ietf.org/mailman/listinfo/cdni
>
>
> _______________________________________________
> CDNi mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cdni
> _______________________________________________
> CDNi mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: ZhouZhipeng <[email-masked]>
Date: Wed, 02 Nov 2011 07:29:51 +0000

Hi Scott,
This topic perhaps may not be so simple as 0 or 1, otherwise we would not have taken so much time discussing on it.
The original question is: if to support content adaptation, where , what solution(i.e. transformation, metadata, etc) and  how much cost would be needed.
If there is no appropriate scenario to implement the content adaptation, the use case and requirement would be not in the standard work.
So we have evaluated many issues and still are working to give a complete view.
From my side and some other experts, some internal works have been done on this. Perhaps different people hold either a positive  or a negative viewpoint for it.
The work (including offline discussions) is still going on and I would give my complete analysis and solution proposal on this topic.
How about to let’s do the final evaluation then.

> Now if the flag is set to "1", it is incumbent upon the dCDN to figure out how to modify the content without changing the URL references, etc.
We may have different ways. For example why to constrict that with the same URL for different content copies.
And, RFC2295 (Transparent Content Negotiation in HTTP) perhaps may be the information for reference too.

Welcome your more ideas on this topic.
Thanks.
Zhipeng

From: Scott Wainner [mailto:[email-masked]]
Sent: Wednesday, November 02, 2011 3:47 AM
To: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

I suspect that the majority of the CDNI relationships will set the flag to "0" indicating the asset is not allowed to be adapted.  The reason can be anything including contractual between the CP and uCDN, the content is encrypted, the uCDN preference, etc.

Now if the flag is set to "1", it is incumbent upon the dCDN to figure out how to modify the content without changing the URL references, etc.

Scott

On 10/27/11 7:22 AM, Woundy, Richard wrote:
>In your companyâ€™s website, I just find some information

The goal of this WG is not to align vendor product roadmaps, or to equalize all vendor offerings, or to specify the entire CDNI ecosystem. The goal of this WG is to enable the interconnection and interoperation of two or more CDNs, within the bounds of the CDNI wg charter.

It is OK to have a discussion about whether content adaptation needs to be performed by the dCDN, since that decision impacts the uCDN-dCDN interface. So let's find a productive way to discuss this on the mailing list, and to close the discussion by IETF 82 (if not sooner).

Can someone describe real-life examples where downstream CDN (or edge cache-based) content adaptation is needed today in a production environment, or shortly? Not merely a feature in a vendor's product materials?

Speaking as an individual, I can find a lot of examples where downstream content adaptation is not needed, and any adaptation is really part of the CP - uCDN interface (which is out of the scope of our charter).

-- Rich

From: ZhouZhipeng [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 03:45 AM
To: Mark de Jong <[email-masked]><mailto:[email-masked]>; Alan Kavanagh <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hello Mark,
Nice to meet you on line.
In your companyâ€™s website, I just find some information that addresses â€œ Vodafone subscribers complained about video performance.â€
See:
http://www.jet-stream.nl/search/?search=transcoding

Dear all in this group,
In last few days, except the public email discussions I have contacted with some people and discussed with my own colleagues of all details on this issue.
First, although the market requirement for it is very important, I feel Iâ€™d better show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the wording is not enough.
I am busy making some contributions on this and plan to upload to ETSI meeting and IETF CDNI.
By these work  I feel the people may catch a whole view on this issue.
Second, for that functionality, in implementation, if some entity does not choose to support it, it may be ok. Since it may be negotiated between two CDNs.
If dCDN does not support that, it may be the uCDN responsible to complete the transcoding and deliver the content of multiple formats and rates to dCDN.
Third, although CDNI is a new architecture, while the content operating has been existed for years. As I know the content from USA to the downstream operator is transferred on one copy and the downstream operator will handle the transcoding.

Perhaps, the content adaptation is more on the mobile operating. But I feel currently most operator will be a all service operator. And for the CDN providers, it may be better to support all kinds of service.
Besides, I like say that the technology on this topic has been for many years and has been rather mature, even some items in ietf such as rfc3507 icap. So from the technique point of view, it is a nature action to be involved in CDN interconnection.
Thanks.
Zhipeng

From: Mark de Jong [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 4:21 AM
To: Alan Kavanagh
Cc: Ben Niven-Jenkins; ZhouZhipeng; [email-masked]<mailto:[email-masked]>
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

E-mail: [email-masked]<mailto:[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<http://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/<http://www.jet-stream.com/blog/>
- VideoExchange: www.vdo-x.net<http://www.vdo-x.net>
- Streamzilla: www.streamzillacdn.com<http://www.streamzillacdn.com>
- Corporate: www.jet-stream.com<http://www.jet-stream.com>

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]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Ben and Philip,

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]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[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

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]> [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: 10 October 2011 12:04
To: ZhouZhipeng
Cc: [email-masked]<mailto:[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

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]<mailto:[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.

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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

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

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

---

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

Folks,

(as a WG co-chair)

It is great that the CDNI topic has attracted new faces (or "voices" I should say until we get together in Taipei) that we have not heard/seen around the IETF before. To ensure we operate as effectively as possible, I would like to encourage those that are not so familiar with the IETF to take the time to familiarize themselves with the IETF process, in particular by checking out the "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force" (https://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/).

In particular, it is good to keep in mind the following statement:
"Participation in the IETF or of its WGs is not fee-based or organizationally defined, but is based upon self-identification and active participation by individuals."
So that discussions in IETF is expected to be based on technical arguments made by individuals and not based on company affiliation, positions or strategies.

Cheers

Francois

On 31 Oct 2011, at 10:04, ZhouZhipeng wrote:

> Sorry, not KPN. It is Ray from TNO.
> Zhipeng
>  
>  
> From: ZhouZhipeng 
> Sent: Monday, October 31, 2011 4:49 PM
> To: 'Francois Le Faucheur'
> Cc: [email-masked]
> Dear Francois, and all,
> Thanks for all the group’s attention on this topic.
> I am also happy that my proposal has gotten so much valuable response/questions/ comments.
> That will be very helpful for all of us to catch a complete understanding and solution for this market demand.
> While I feel till now the topic itself has not been completely analyzed and I am busy doing the work. I will expose my contribution soon after I complete that work.
> Meanwhile I hope the group may allow some more time for people to consider it. Perhaps some more people will emerge in the group mail list.
> Currently, some people has claimed their preference.  I feel perhaps not a few people have supported this use case(the authors of draft-fmn-cdni-advanced-use-cases-00, Alan from Ericsson, ChinaMobile, Chinatelecom,  perhaps also KPN, and me).
>  
> I have explained that for CDN-A and CDN-B, they may negotiate whether to support the CDNI adaptation solution. Hence such optional arrangement will only bring benefit when both upstream and downstream agrees that at their appropriate situation.
>  
> So, I sincerely suggest two Chairs and the whole group may allow some more days for this topic.   I suggest after the Taipei meeting .
> By then we all will get a clearer understanding and decision.
>  
> Thanks.
> Zhipeng
>  
>  
>  
> From: Francois Le Faucheur [mailto:[email-masked]] 
> Sent: Friday, October 28, 2011 9:50 PM
> To: ZhouZhipeng
> Cc: [email-masked]
> Hi again Zhipeng,
> There is one other point I should have brought up in my previous message:
> The question is not so much whether there are benefits to allowing content adaptation for some environments, nor whether one particular individual could conceive an approach for content adaptation that suits him. The question here is rather whether it is justified for the Working Group to focus energy on that problem right now in order to develop a consensus-based approach that suits the community as a whole, while we don't even have the base solution in place.
>  
> You have made it clear that you feel the WG should indeed dedicate energy on that problem right away and explained your rationale. Thank you. Others have also expressed their opinions.
>  
> Cheers
>  
> Francois
>  
>  
> On 28 Oct 2011, at 11:25, ZhouZhipeng wrote:
>  
> 
> Dear all,
> In these days I am busy making a summary analysis on this topic. As Richard’s request, I like to show my information although perhaps not complete right now.
>  
> 1)     I have done some work to collect different company’s requirements and opinions on this functionality.
> One, I feel most of us have already been aware of the service of content adaptation, and I also sent an email yesterday that Vodaphone now is requiring the solution to enhance the performance of its mobile video service.
> Second, here is an article about CISCO : “Cisco urges mobile operators to add value to CDN services” http://www.totaltele.com/view.aspx?ID=468705
> Besides, I have checked many CDN company’s websites. Many claim to support transcoding while some may not.
>  
> 2)     For the wording “content adaptation”, it should be clarified here that it may be two kinds.
> One is only the transformation of encapsulation format. For example the H.264 stream is encapsulated in APPLE and Adobe format respectively.
> I know that Comcast has a project that needs to pick the H.264 media from the TS stream and then encapsulated them into different formats(APPLE,Adobe…) to different devices.
> For this kind of transformation, the computing cost is very very low and may be nearly neglected.
> The other is to transcoding.  For example to support different bitrates.  Since encoder is a high value facility, we should compare the capital cost of encoder and transport cost.
> Just take a simple model: content is delivered from Node A to Node B.
> There are two solutions:
> 1)     A have the transcoder and deliver multi-format content to B
> 2)     B have the transcoder; A only delivers one format content to B and B would transcode.
> From whole system point of view, either A or B would transcode while the bandwidth would be saved in solution B. Hence solution B is better.
> Now provided the bandwidth is paid by B and B should decide whether to install transcoder.
> (Richard has said to set transcoder in each edge server)
> If the cost of renting bandwidth (for a few months) is more expensive than the price of transcoder supporting the same bandwidth, it would be better to put the transcoder at the receiver Node B.
> In fact I have investigated this issue for much time. While in different area the price of bandwidth may be different.  And the transport burden between two distant places or over a bad nature environment would be much higher.
> Here the price in USA may be referred as: http://smallbusiness.verizon.com/products/internet/hsi/overview.aspx#plans.
> In Verizon, the package for 10-15mbps is $90 per month (I feel the bandwidth quality for business would be guaranteed). I query that the bandwidth price in China may be 50% higher.
> I do not know how much the price will be for the bandwidth from Amsterdam to Paris (cross country in the same continent).  But I feel the price from NewYork to Paris would absolutely be very high.  As for the Encoder, it also varies. Perhaps the price in China will be higher than in USA. And in fact the price of bandwidth and encoder depends mostly on the concrete business items. For example the price to Huawei may be lower than the public price.
> By my current evaluation in China it is better using the transcoder than renting multiple times broadband.
> Some people have told me that for the operator himself probably the bandwidth cost would be very low in the internal capital counting. But for the independent CDN, it may another thing.
> So, my suggestion is to let different ways co-exist. I have announced that to let two sides negotiate whether to assign dCDN for the content adaptation.
>  
> In fact, from CP to CDN,  there are the real businesses that either let CP to provide multi-format content or let the CDN to receive one format and complete the transformation, depending on the concrete business.
> By the same logic, form uCDN to dCDN, it may be either the uCDN to provide multi-format content or the dCDN to receive one format content and then complete the transformation.
> Currently there is not the real CDN-CDN connection, hence we are basing our knowledge on the related solution to make our solutions.
>  
> 3)     As for the procedure of content adaptation, I just draft a diagram as below:
>  
> You may see the solution is rather clear and the metadata needed would be clear also.
>  
> Dear,
> By my analysis above, I kindly invite your ideas whether it may be an applicable and simple part in the CDNI item, provided that the solution is open to the types of content adaptation and may be optionally implemented in the real solutions/business. I feel for those operators that need such functionality it would be very good while it does not impact others that do not implement it.
> Thanks.
> Zhipeng
>  
>  
> From: Woundy, Richard [mailto:[email-masked]] 
> Sent: Thursday, October 27, 2011 7:23 PM
> To: ZhouZhipeng; [email-masked]'; [email-masked]'
> Cc: [email-masked]'; Woundy, Richard
> >In your company’s website, I just find some information
> 
> To: Mark de Jong <[email-masked]>; Alan Kavanagh <[email-masked]> 
> Cc: [email-masked] <[email-masked]> 
> In your company’s website, I just find some information that addresses “ Vodafone subscribers complained about video performance.”
> See:
> First, although the market requirement for it is very important, I feel I’d better show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the wording is not enough.
> Cc: Ben Niven-Jenkins; ZhouZhipeng; [email-masked]
> E-mail: [email-masked]
> - News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com
> - Blog: www.jet-stream.com/blog/
> - VideoExchange: www.vdo-x.net
> - Streamzilla: www.streamzillacdn.com
> - Corporate: www.jet-stream.com
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Cc: [email-masked]
> Cc: [email-masked]; [email-masked]
> From: [email-masked] [mailto:[email-masked]]
> To: [email-masked]; ZhouZhipeng
> Cc: [email-masked]
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ben Niven-Jenkins
> Cc: [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 Nov 2011 19:36:21 +0100

All,
As mentioned earlier:
Please think of using specific Subject lines for the various threads and don't hesitate to branch off with a different "Subject" when an initial thread morphs into a different topic. This helps the discussion.

Scott and all,
This option was also brought up during the last IETF. It seems a reasonable trade-off as it would represent very little work for the WG (i.e. one extra binary metadata information to convey along the rest of the metadata) and allows dCDN to do local content adaptation when given free-reins by the uCDN (presumably in line with the CSP policies) and allows uCDN to prevent content adaptation when incompatible with CSP policy.
When polling the WG in Taipei, we could include that option in the poll (in addition to the option of not dealing with content adaptation at all, and the option of trying to fully enable content adaptation).

Francois

>> delivery is executed.  Clearly, the choice of authentication method is determined by the respective CDN's.

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 3 Nov 2011 15:42:24 -0400

Hi Francois

I dont believe its a lot of work, we are talking about a couple of additional Metadata objects which i feel is very trivial to have added, right?

Alan

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur
Sent: October-28-11 9:46 AM
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi again Zhipeng,

Cheers

Francois

Dear all,
In these days I am busy making a summary analysis on this topic. As Richard's request, I like to show my information although perhaps not complete right now.
1)     I have done some work to collect different company's requirements and opinions on this functionality.
One, I feel most of us have already been aware of the service of content adaptation, and I also sent an email yesterday that Vodaphone now is requiring the solution to enhance the performance of its mobile video service.
Second, here is an article about CISCO : "Cisco urges mobile operators to add value to CDN services" http://www.totaltele.com/view.aspx?ID=468705
Besides, I have checked many CDN company's websites. Many claim to support transcoding while some may not.
2)     For the wording "content adaptation", it should be clarified here that it may be two kinds.
One is only the transformation of encapsulation format. For example the H.264 stream is encapsulated in APPLE and Adobe format respectively.
I know that Comcast has a project that needs to pick the H.264 media from the TS stream and then encapsulated them into different formats(APPLE,Adobe...) to different devices.
For this kind of transformation, the computing cost is very very low and may be nearly neglected.
The other is to transcoding.  For example to support different bitrates.  Since encoder is a high value facility, we should compare the capital cost of encoder and transport cost.
Just take a simple model: content is delivered from Node A to Node B.
There are two solutions:
1)     A have the transcoder and deliver multi-format content to B
2)     B have the transcoder; A only delivers one format content to B and B would transcode.
To: ZhouZhipeng; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Cc: [email-masked]<mailto:[email-masked]>'; Woundy, Richard
>In your company's website, I just find some information

-- Rich

From: ZhouZhipeng [mailto:[email-masked]]
Sent: Thursday, October 27, 2011 03:45 AM
To: Mark de Jong <[email-masked]<mailto:[email-masked]>>; Alan Kavanagh <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hello Mark,
In your company's website, I just find some information that addresses " Vodafone subscribers complained about video performance."
First, although the market requirement for it is very important, I feel I'd better show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the wording is not enough.

Mark de Jong

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

Hello Ben,

Ben

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Wednesday, October 12, 2011 12:19 AM
To: ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
Zhipeng,
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, October 10, 2011 11:22 PM
To: [email-masked]<mailto:[email-masked]>; ZhouZhipeng
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
Ben, Zhipeng, all,

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 Nov 2011 21:07:54 +0100

Alan,

(as an individual)

> I dont believe its a lot of work, we are talking about a couple of additional Metadata objects which i feel is very trivial to have added, right?

I do believe fully covering content adaptation in CDNI would actually be a lot of work. Partly because it is a space of fast innovation and proprietary approaches. Partly because I would bet that each of us would actually come up with a different set of additional metadata objects and it woudl take a long time to converge on an agreeable set.

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

---

From: ZhouZhipeng <[email-masked]>
Date: Fri, 04 Nov 2011 08:11:47 +0000

Sure Francois,
I am a little sorry for that because I have contacted several people within a company so not convenient to list multiple names.
I will be careful for that in the future.
Zhipeng

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]] 
Sent: Friday, November 04, 2011 1:57 AM
To: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Folks,

(as a WG co-chair)

Cheers

Francois

On 31 Oct 2011, at 10:04, ZhouZhipeng wrote:

> Thanks for all the group's attention on this topic.