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

From: Alan Kavanagh <[email-masked]>
Date: Thu, 8 Dec 2011 15:02:27 -0500

Hi Scott

Apologies for now following up sooner on this, too much traveling lately etc.

I agree with you that these two binary options are simple and sufficient and more importantly "allow us to extend" CDNI for future work, so im supportive of your suggestion and hope its included in the appropriate documents such as the Metadata and Control and not just the use cases drafts.

The reason most CDNs will set the "content adaptation permitted" flag ==0 is for quality control on content being distributed where by the Authorised CDN has as you say a contractual agreement with the CSP and that authorised CDN is responsible for transcoding and checking it etc, that by and large covers a large set of scenarios and mostly the predominant cases today. I do see some CDN's that for different types of content will allow content to be adopted but by and large that is not the common case of today but its an option we should include and i think have those binary options covers the basic cases.

Alan

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Wainner
Sent: November-01-11 3:47 PM
To: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

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â€™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]><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
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: zhangyunfei <[email-masked]>
Date: Fri, 9 Dec 2011 10:04:16 +0800

+1. It's reasonable to have a simple option open for content adaptation issue between uCDN and dCDN. But we needn't jump into designing the detailed content adaptation para transfer mechanism right now, as agreed in last IETF.

BR
Yunfei

zhangyunfei

From: Alan Kavanagh
Date: 2011-12-09 04:02
To: Scott Wainner; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
Hi Scott

Alan

Scott

-- 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,
Cc: Ben Niven-Jenkins; ZhouZhipeng; [email-masked]

Mark de Jong

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

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,

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]; [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
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,
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Cc: [email-masked]
-----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
[email-masked]
[email-masked]

[email-masked]
[email-masked]

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 9 Dec 2011 15:33:20 +0100

All,

Please see the notes on Content Adaptation from the minutes of the Taipei meeting at http://www.ietf.org/proceedings/82/minutes/cdni.txt.

"
Hum test.
Option 1 - Strong hum
Option 2 - weak Hum + 2 hums from jabber.
option 3 - silence
The tentative agreement is to go for Option 1. This will be validated on the list.
"

If we add Alan and Yunfei's input it takes us to:
"
Hum test.
Option 1 - Strong hum
Option 2 - weak Hum + 2 hums from jabber + 2 on the list
Option 3 - silence
"

Unless we hear significant additional input on the list in the coming days, we will consider the decision for Option 1 final.

Cheers

Francois & Rich

---

From: Alan Kavanagh <[email-masked]>
Date: Fri, 9 Dec 2011 09:40:07 -0500

Hi Francois

Sure i remember the Humming for Option-1 to support A&B approaches only. I was under the impression that we just want "detail on transcoding" to be supported but are we now stating we don't want to include an option to support this in CDNI current works, i guess you are stating yes.

In such case, im assuming then we will be doing V2 of CDNI and Vx's of CDNI as needed, where V2 will include support for Option 3, right?

Im not trying to conflict what was agreed in Taipei im supportive of that outcome, im just trying to understand if their is plans for the future as opposed to running with the basics?

Alan

________________________________
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: December-09-11 9:33 AM
To: zhangyunfei
Cc: Francois Le Faucheur; Alan Kavanagh; Scott Wainner; [email-masked]
Subject: Content Adpatation

All,

"
Hum test.
Option 1 - Strong hum

Cheers

Francois & Rich

BR
Yunfei

From: Alan Kavanagh<mailto:[email-masked]>
Date: 2011-12-09 04:02
To: Scott Wainner<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
Hi Scott

Alan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Scott Wainner

Scott

-- Rich

Hello Mark,

Mark de Jong

Ben

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: ZhouZhipeng <[email-masked]>
Date: Tue, 13 Dec 2011 08:00:50 +0000

Francois, Good morning,
May I ask a question: how many supporters are needed if to support CA in CDNI.
Perhaps that is more clear than the ‘HAM’.
Do we insist only one option even it is only 1 more than another option shall be good enough.
In fact, the three options are all to support this functionality while the difference is whether to support in v1 or v2.
For your reference.

Thanks.
Zhipeng

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Friday, December 09, 2011 10:33 PM
To: zhangyunfei
Cc: [email-masked]
Subject: [CDNi] Content Adpatation

All,

"
Hum test.
Option 1 - Strong hum

Francois & Rich

BR
Yunfei

Alan

Scott

-- Rich

Hello Mark,

Mark de Jong

Ben

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: Tue, 13 Dec 2011 11:53:18 +0100

Hello Zhipeng,

Yes, we need to select one approach for the working group to follow (ie one option).
At this stage, the chairs feel that there is "rough consensus" on option 1.
You are right that this only conditions what is worked on in v1, and the additional functionality can be incorporated in v2.

Cheers

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: Francois Le Faucheur <[email-masked]>
Date: Tue, 13 Dec 2011 12:07:59 +0100

Hi Alan, 

> In such case, im assuming then we will be doing V2 of CDNI and Vx's of CDNI as needed, where V2 will include support for Option 3, right?

Yes. All we are saying at this stage is that the initial work will not cover approach C for content adaptation.
When the initial work is done, the Working Group will be in a position to define what it want to do next. This could be to work on a V2 that includes approach C for Content Adaptation. I am saying "could" because the final decision will be taken at the time of course.   
> Im not trying to conflict what was agreed in Taipei im supportive of that outcome, im just trying to understand if their is plans for the future as opposed to running with the basics?

Start with the basics. Once we've done that, enhance as needed.

Thanks

Francois

---

From: Stef van der Ziel <[email-masked]>
Date: Tue, 13 Dec 2011 13:36:35 +0100

Dear list members,

Before I dive into the details I have included a short introduction at the bottom of this email for those who don't know us.

The voice of content publishers
I think that in general the requirements that are being described in IETF are very good. In general (not just IETF) I do have the feeling that the voice of the content industry is a bit missing. I have gotten very specific feedback from the content industry about interconnected CDNs which I share below. I think the wish for content publishers to control and operate their own CDNs over multiple federated CDNs is a bit underestimated in general. I hope that will inspire us all to think of additional requirements and prevents us from working on a paper vendor / technical driven standard that will not be adopted by those who will ultimately pay for these services. The content industry is worried that telcos and CDN vendors and CDN operators will only look at traffic optimization and will affect their business case and contracts in a negative way by using technologies such as smarter caching, transcoding, packet altering and packet prioritization. Therefore standards must not allow any party to transcode, transprotocol, edit, degrade or touch their content in any way without full control and full transparency by the content publisher throughout the entire chain of interconnected CDNs and IP networks.

No uncontrolled content adaptation
FYI content owners and content publishers can have very strict contracts that specify how content may be encoded, at which sizes, bit rates, with which codecs and encoding parameters. A content publisher may outsource the encoding to the uCDN but a dCDN may never degrade or adapt or even transprotocol the content without any permission by the formal content publisher. So I agree with the discussions on this list about dCDN adaptation: not a good idea.

HTTP adaptive focus?
Content publishers have issues with HTTP adaptive streaming. They want to move up to a true broadcast experience over the Internet. True broadcasting like DVB-S, DVB-C and IPTV does not dynamically adapt and degrade. We see that there is a strong push from vendors towards HTTP but at the same time many content publishers hesitate. In our view HTTP adaptive bit rate streaming is in a first stage and needs more evolving. There are some serious gaps in the various HTTP based streaming technologies such as loss of true session information, loss of QoS control and reporting, logging and log processing by itself is a pain and distribution is generally done via caching which is a best effort distribution technology, not a premium one with controlled and guaranteed distribution. Add the thundering herd problem that can overwhelm HTTP caches and origins servers, add the issues with mobile network signaling caused by the aggressiveness of HTTP adaptive streaming and add the fact that HTTP is not replacing but is just adding yet another flavor of streaming technologies and the only conclusion can be that a standard must not be biased towards this technology: RTSP and RTMP are as important as HTTP. So my suggestion is that the standard makes no difference in delivery protocols (GEN-6 and GEN-7 and GEN-14 as well).

Transparency and control: exposure
Content publishers in general feel that todays CDNs are too closed. It's like a black box where you get your content in and it gets out. Hopefully at good performance. The CDNs topology and servers and services are hidden. They want more transparency. They don't need a telco to fully expose their topology but they want to know whether a region is really covered by delivery capacity and which services (such as RTSP, icecasting, HTTP, RTMP) are actually available in that region. That's premium. And this affects CDN interconnection as well. If a content publisher signs up with CDNA, then they want to know which parts of their target geography is covered natively by CDNA, and which parts are covered via federation and through which other CDN partners. Remember this is not about telephony where the caller doesn't care if their call is routed via CarrierA or CarrierB, this is about premium content and the content publishers have the right to know (and control) which parties in the delivery chain are managing, storing, distributing and serving out their precious content. We need a serious debate about exposing resources, services, performance and capacity via CDN interconnection standards and how content publishers can control via which CDN partners their content must and may not be distributed (for whatever reason they have, like better performance, or legal matters where their content may not be stored in a specific country). GEN-10 and GEN-11: Looping prevention is an important requirement that by itself justifies more transparency and exposure about topology and inter-CDN topology to prevent looping.

Capabilities / Bootstrap API
I see that some proposals bury interoperability features into a number of interfaces. We propose that CDNs offer a single unified bootstrapping API instead of abusing a request routing function for this for instance. This API can then also share more about the CDN in general, like vendor ID, operator ID, version, supported delivery services, supported delivery protocols, covered regions, active state (per protocol/service), supported ingest/relaying services, control APIs, feedback APIs, log locations, etc.
If these features are going to be buried into various interoperability interfaces then my concern is that this will introduce a future lock where interoperability will be limited by its own design. 

Request Routing
What I am missing is the challenge that some CDNs will use DNS based geo load balancing while others will use application based geo request routing services and that URLs of these CDNs will have different formatting. An Akamai URL is not the same as a Jet-Stream URL. FYI a Jet-Stream CDN URL is a base URL plus over a dozen of parameters that enable the content owner to control the CDNs response in many ways. The CDNi standard should provide for being able to interoperate with another CDN regardless the request routing technology (DNS, HTTP redirect, metafile generation, etc). And the CDNi standard should also provide for being able to interpret another CDNs URL construction and then translate it into its own URL buildup for further processing and vice versa. Active redirect request routers are relatively easy to extend with such features, but DNS systems are quite passive so they may not be able to do this. 

Request routing security
Another topic that needs more debate is the security between request routers. If PortalA points to CDNA which points to CDNB which points to CDNC which points to CDNC's delivery node, then the entire chain needs to be secured. The CDNi standard should provide for a realistic but secure way to prevent anti-deep-linking and session control. Some specific challenges: security tokens can be unique per request so request routing sessions may never be cached; some CDNs use strong anti-caching technologies (faking caches that the same content has different names) and this feature may not be broken by CDN interconnectivity; some CDNs use URL hashing which makes it hard for interconnected CDNs to interpret the actual content being requested.

Request routing function 
I have seen some proposals where the request routers are also used to share metadata between CDNs such as availability, performance, features and capacity. I strongly recommend to use request routing and request routing interconnectivity only for request routing itself. Request routers are not services that should instruct other CDNs if they do or do not accept requests. A Request router function must not be abused for a capabilities exchange API. There are other standards and technologies for sharing status information between CDNs such as SOAP or REST control APIs.

GEN-9: I propose that the CDNI solution can also support inter-CDN redirection (User agent requests from CDN1 which connects to CDN2 for a request response, and CDN1 gives back the response from CDN2 to the user agent) to an arbitrary number of levels beyond the first level. This is necessary because:
- Some clients have restrictions in whether they support redirect functions
- Some clients have resrictions in the number of redirects that are supported
- Cascaded redirection eats up time while inter-CDN request routing is much faster

What I am missing is the capability of a CDN to present a HTTP adaptive (live or VOD) stream as if it is a logical asset. This is important for request routing but also for many other core features of a CDN.

What I am missing is a generic capabilities exchange feature: what request routing functions does a uCDN support (DNS, HTTP redirect, which metafile formats?) and how are URLs constructed both for the request router as for the actual media nodes, and which security features are required or optional, and does the CDN support cascading redirects or does it support inter-CDN redirects?

Metadata
I have heard some ideas where contextual metadata about content (such as description, authors, subjects and keywords) should be part of a CDN interconnection standard. I disagree. A CDN doesn't need to know about this metadata and can treat it as if it is just content.

I have heard some ideas where technical metadata about content (such as bit rate, screen sizes, length, codecs, format) should be exchanged between CDNs via XML files. I object to that idea, because there are better standards for exchanging this data such as SOAP or REST. Sending metadata via objects to be processed by the CDN is not a good idea.

I have heard some ideas where instructional metadata about content (such as delete, TTL, pre-distribute, geo-block, lock) should be exchanged between CDNs via XML files. I object to that idea, because there are better standards for exchanging commands such as SOAP or REST. Sending metadata commands via objects to be processed by the CDN is not a good idea.

I have heard some ideas where CDN metadata about content (such as popularity, distribution status, hashes) should be exchanged between CDNs via XML files. I object to that idea, because there are better standards for exchanging commands such as SOAP or REST. Sending CDN metadata via objects to be processed by the CDN is not a good idea.

What I am missing is a generic capabilities exchange feature: what types of metadata does a dCDN needs to be able to process, which APIs are available and are there WSDL files describing these so a uCDN can integrate. How can a uCDN instruct a dCDN to pre-push content to specific delivery nodes in specific regions? And how can this be managed for live streams? 

Content exchange
CDNs can have many ways to exchange content. I think ingestion is not the right term. We prefer to talk in terms like PUSH, PULL and RELAY. Push means that a uCDN pre-ingests content into a dCDN. For instance via FTP or WebDav. Pull is usually caching based and is initiated by an end users request. Relaying is for live streams, where a uCDN has to instruct a dCDN to setup a relay publishing point to relay their RTMP, RTSP, Icecast, MMS (or whichever other protocol) live streams. Some CDNs use very basic reverse proxying modes to relay live streams, other CDNs do this dynamically on a per stream basis. 

What I am missing is a generic capabilities exchange features: which types of ingest protocols are supported? FTP? FTP with TLS/SSL? WebDav? Aspera? Does the CDN offer static or dynamic ingest points? Does a dCDN support HTTP origin pull and how can this automatically be setup? Which live streaming relay functions and protocols are supported and how can a uCDN instruct a dCDN to relay their live streams?

Logging
I would like to propose to make a clear difference between realtime/near-realtime data and historical data.
Realtime/near realtime data is data like #concurrent viewers and #concurrent bandwidth. Which ideally would be shared via an API.
Historical data is about access logs. One challenge here is that end users could consume content for over 4, 8, 12, even 24 hours. As long as the session is not stopped, logs are not saved. The effect is that a dCDN must be able to report 'late coming' log entries to a uCDN which must be able to process them as well throughout the entire chain.

I also propose that CDNs should be allowed to specify more than one format for logging since CDNs will use multiple services such as Wowza, FMS, WMS, IIS, Apache, DSS, etc which each have their own logging styles, and some are configurable.

For transportation of realtime data APIs are better. For transportation of log files, HTTP or FTP are better.

Some CDNs may be able to share additional logs, such as request routing logs. What I am missing is a generic capabilities exchange feature that shares which logs types are available via which protocols and interfaces.

Sorry to bother you all with this quite long email, I hope you value my input.  Feel free to comment! If I have comments on topics that are already covered, then excuse me for overseeing these. If I can find the time I will dive deeper into the IETF draft to share additional comments.

Kind regards, Stef van der Ziel

-- 
Owner Jet-Stream | StreamZilla
GMT+1 Office: +31 50 5261820 | Mobile: +31 6 23406348
email: [email-masked] | skype: stefvanderziel | twitter: @jetstreambv
www.jet-stream.com | www.streamzillacdn.com

About Jet-Stream and CDN interconnectivity
I founded Jet-Stream in 2002. We licensed our CDN technology to over 30 telecom and broadcasting customers. Our own StreamZilla CDN offers premium video CDN services to over 600 contracts (primarily professional content publishers) in Europe. 

In 2002 I initiated a Dutch CDN interconnection project which was adopted by the telcos and broadcasters and the Amsterdam Internet Exchange and we have been an advocate of CDN federation for a long time, supporting pilots and sharing experience and knowledge. We are member of ETSI and since recently we are following the IETF efforts as well. 

In contrary to probably most of the members who are telco or vendor driven, we have a background in media production and we have a lot of content customers. Our CDN control plane software lets us use a standard account on one CDN as if it were a logical edge server on another CDN. That approach enables full CDN interoperation and federation.

On our CDN strategies blog we post a lot about CDN federation, for instance: http://www.jet-stream.com/blog/2011/10/cdn-interoperability-reality-check/

---

From: ZhouZhipeng <[email-masked]>
Date: Wed, 14 Dec 2011 11:28:55 +0000

Morning Francois,
May I further ask whether the group had ever announced vote options and  the rule of the vote in the maillist before the Taipei meeting .
It is not usual to provide three options for vote, always should be two perhaps.
For your reference.
Zhipeng

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Tuesday, December 13, 2011 6:53 PM
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] Content Adpatation

Hello Zhipeng,

Cheers

Francois

Francois, Good morning,

Thanks.
Zhipeng

All,

"
Hum test.
Option 1 - Strong hum

Francois & Rich

BR
Yunfei

Alan

Scott

-- Rich

Hello Mark,

Mark de Jong

Ben

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

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]<mailto:[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<http://www.cisco.com>

 Think before you print.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 14 Dec 2011 12:00:43 +0000

Zhipeng,

> May I further ask whether the group had ever announced vote options and  the rule of the vote in the maillist before the Taipei meeting .

This is not how IETF works - decisions are based on rough consensus not explicit voting. Rough consensus is judged by the WG chairs.

See RFC2418 for WG Guidelines and Procedures. For example section 3.3 of that document states:

   Working groups make decisions through a "rough consensus" process.
   IETF consensus does not require that all participants agree although
   this is, of course, preferred.  In general, the dominant view of the
   working group shall prevail.  (However, it must be noted that
   "dominance" is not to be determined on the basis of volume or
   persistence, but rather a more general sense of agreement.) Consensus
   can be determined by a show of hands, humming, or any other means on
   which the WG agrees (by rough consensus, of course).  Note that 51%
   of the working group does not qualify as "rough consensus" and 99% is
   better than rough.  It is up to the Chair to determine if rough
   consensus has been reached.

You might also find The Tao of IETF useful reading:
http://www.ietf.org/tao.html

Ben

---

From: Vinayak Hegde <[email-masked]>
Date: Wed, 14 Dec 2011 18:39:35 +0530

> http://www.ietf.org/tao.html

Futhermore there can be explicit voting by show of hands (instead of
"humming") but that was not needed as there was fairly strong
consensus about the content adaptation part.

-- Vinayak

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 14 Dec 2011 13:26:41 +0000

> consensus about the content adaptation part.

This isn't the right mailing-list for this sort of discussion so I won't say any more on the topic beyond noting that I've never participated in a WG that used a show of hands where the show of hands was an explicit vote rather than a mechanism to judge relative levels of interest/support/etc.

Certainly in my WG (L3VPN) although we ask for a show of hands rather than a verbal hum it is not an explicit vote where for example 21 hands for something and 20 hands against is considered rough consensus in favour of it.

Ben

---

From: Bruce Davie <[email-masked]>
Date: Wed, 14 Dec 2011 09:52:39 -0500

Zhipeng, 
like all IETF working groups, the CDNI WG does not conduct formal votes. To quote from RFC 4677:

   Another aspect of Working Groups that confounds many people is the
   fact that there is no formal voting.  The general rule on disputed
   topics is that the Working Group has to come to "rough consensus",
   meaning that a very large majority of those who care must agree.  The
   exact method of determining rough consensus varies from Working Group
   to Working Group.  Sometimes consensus is determined by "humming" --
   if you agree with a proposal, you hum when prompted by the chair; if
   you disagree, you keep your silence.  Newcomers find it quite
   peculiar, but it works.  It is up to the chair to decide when the
   Working Group has reached rough consensus.

I believe that is what was done at the Taipei meeting, but Francois may wish to elaborate further.

Yes, it is unusual if you are comparing the IETF to some other organization. Some people consider this a feature.

Bruce

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 14 Dec 2011 10:54:37 -0500

Lets drop the discussion on CA period, and as Francois says revisit this when we recharter the WG.

Alan

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Davie
Sent: December-14-11 9:53 AM
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] Content Adpatation

Zhipeng,

Bruce

Morning Francois,

Francois, Good morning,

Scott

-- Rich

Hello Mark,

Mark de Jong

Ben

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

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 15 Dec 2011 06:54:41 +0000

Hello Bruce, Ben and Vinayak,
Absolutely sometime vote may be raised in all SDOs, but before the vote whether the options should be clarified to make sure the meaning of the options have been clear and appropriate and let all the people to know how to do after the vote before the meeting.
Besides, if most people in the room have not hum, may we think most people are opposing to all the three options.
Absolutely this vote is not fully prepared, as quick as possible:

For your reference.
Zhipeng

From: Bruce Davie [mailto:[email-masked]]
Sent: Wednesday, December 14, 2011 10:53 PM
To: ZhouZhipeng
Cc: Francois Le Faucheur; [email-masked]
Subject: Re: [CDNi] Content Adpatation

Zhipeng,

Bruce

Morning Francois,

Hello Zhipeng,

Cheers

Francois

Francois, Good morning,

Thanks.
Zhipeng

All,

"
Hum test.
Option 1 - Strong hum

Francois & Rich

BR
Yunfei

Alan

Scott

-- Rich

Hello Mark,

Mark de Jong

Ben

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

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

---

From: Vinayak Hegde <[email-masked]>
Date: Thu, 15 Dec 2011 12:49:25 +0530

Hi Zhipeng,

Couple of clarifications:

1. Humming as a method for consensus has already been well documented
in the Tao of the IETF and elsewhere. Ben has referenced the sections
in an earlier thread.

2. The options were clarified very clearly by Francois before the
consensus was judged. The opinions from Jabber were also taken into
consideration. I was present in the room when this was done. So there
is no question of ambiguity. There was consensus that CA should be
taken up later once all the basic stuff is nailed down in specs.

3. Lastly I think you were not present in the room when the options
were presented. Even if what you say were true, I am not seeing anyone
on the list having any objections to CA being taken up later on the
list. I think you are just not happy with the consensus.

-- Vinayak

On Thu, Dec 15, 2011 at 12:24 PM, ZhouZhipeng <[email-masked]> wrote:
> Absolutely sometime vote may be raised in all SDOs, but before the vote
> whether the options should be clarified to make sure the meaning of the
> options have been clear and appropriate and let all the people to know how
> to do after the vote before the meeting.
>
> May I further ask whether the group had ever announced vote options and  the
> rule of the vote in the maillist before the Taipei meeting .
>
> You are right that this only conditions what is worked on in v1, and the
> additional functionality can be incorporated in v2.
>
>
>
> Cheers
>
>
>
> Francois
>
>
>
>
>
> In fact, the three options are all to support this functionality while the
> difference is whether to support in v1 or v2.
>
> For your reference.
>
>
>
> Thanks.
>
> Zhipeng
>
>
>
> Please see the notes on Content Adaptation from the minutes of the Taipei
> meeting at http://www.ietf.org/proceedings/82/minutes/cdni.txt.
>
>
>
> "
>
> Hum test.
>
> Option 1 - Strong hum
>
> Unless we hear significant additional input on the list in the coming days,
> we will consider the decision for Option 1 final.
>
> Cheers
>
>
>
> Francois & Rich
>
>
>
>
>
> +1. It's reasonable to have a simple option open for content adaptation
> issue between uCDN and dCDN. But we needn't jump into designing the detailed
> content adaptation para transfer mechanism right now, as agreed in last
> IETF.
>
>
>
> BR
>
> Yunfei
>
>
>
> I agree with you that these two binary options are simple and sufficient and
> more importantly "allow us to extend" CDNI for future work, so im supportive
> of your suggestion and hope its included in the appropriate documents such
> as the Metadata and Control and not just the use cases drafts.
>
>
>
> The reason most CDNs will set the "content adaptation permitted" flag ==0 is
> for quality control on content being distributed where by the Authorised CDN
> has as you say a contractual agreement with the CSP and that authorised CDN
> is responsible for transcoding and checking it etc, that by and large covers
> a large set of scenarios and mostly the predominant cases today. I do see
> some CDN's that for different types of content will allow content to be
> adopted but by and large that is not the common case of today but its an
> option we should include and i think have those binary options covers the
> basic cases.
>
>
>
> Alan
>
>
>
> Of Scott Wainner
> 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
>
> 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
>
>
>
> In your companyâ€™s website, I just find some information that addresses
> â€œ Vodafone subscribers complained about video performance.â€
>
> See:
>
> 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.
>
> 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
>
> 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
> 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
>
> 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.
>
> 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.
>
> Br,
>
> Zhipeng
>
> 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.
>
> Ben
>
> 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?
>
> Scott,
>
> 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.
>
> 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.
>
> 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.
>

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 15 Dec 2011 07:29:40 +0000

Vinayak,
Although I was not in the room, but I am quite clear of the process:)
I know some people had raised some simple questions in the room whether the A, B, C been matched to option 1, 2,3.
I doubt whether people have carefully read the vote options.
For instance I have not seen any "could" while Francois think it is saying "could".
How may you think the process:

>>Even if what you say were true, 
 Thanks.
>>I am not seeing anyone on the list having any objections to CA being taken up later on the list.
Why not:)
>> I think you are just not happy with the consensus.
No, I more care the process on this thing.

Good morning.
Zhipeng

-----Original Message-----
From: Vinayak Hegde [mailto:[email-masked]] 
Sent: Thursday, December 15, 2011 3:19 PM
To: ZhouZhipeng
Cc: Bruce Davie; [email-masked]
Subject: Re: [CDNi] Content Adpatation

Hi Zhipeng,

-- Vinayak

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 15 Dec 2011 09:16:34 +0100

Hello Zhipeng,

(As a co-chair)
I believe the IETF process has been followed correctly and a clear decision about Content Adaptation has been made.
I would now ask you to stop re-opening that discussion on the list, so the Working Group can focus its energy to progress what is in scope.
If you want to formally object to this decision, then you can follow the IETF escalation and appeal process.

Francois

---

From: ZhouZhipeng <[email-masked]>
Date: Thu, 15 Dec 2011 09:08:09 +0000

Morning, all, 
I have thought about a while and feel I'd better give back an email.
We are in the same river (the same industry) and we may be friends while on work we may have different opinions.
Some thing may be either correct or wrong. While some things are not on the same way.
In the industry, there may be different solutions existing at the same time.
You may like flash while other video technologies may be used by other people. It is just whether you use it or not rather than whether good or not.
I thank all that have responded in the maillists about CA. That helps me deeper thinking about the topic also.
Zhipeng

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]] 
Sent: Thursday, December 15, 2011 4:17 PM
To: ZhouZhipeng
Cc: [email-masked]
Subject: Re: [CDNi] Content Adpatation

Hello Zhipeng,

(As a co-chair)

Francois