Subject: [CDNi] New (-01) version of CDNI Problem Statement draft

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 17 Jan 2011 22:50:22 +0000

Colleagues,

We have posted a new version of the CDNI Problem Statement, which can be found here:
http://www.ietf.org/id/draft-jenkins-cdni-problem-statement-01.txt

A diff from the -00 version can be found here:
http://goo.gl/YtJxk  [tools.ietf.org/rfcdiff]

A summary of the changes:
- Incorporated feedback from the mailing list and offline comments.
- Added a section on "Design Approach for Realizing the CDNI APIs" to provide a bit more detail on what a solution may look like and components that could be reused.
- Added a section on "Prioritizing the CDNI Work" which suggest a spilt of the problem space into 3 different spaces that could be addressed sequentially in order to manage the workload of a WG.
- Expanded the "Gap Analysis of relevant Standardization and Research".

Looking forward to your feedback.

Ben

On 17/01/2011 22:35, "IETF I-D Submission Tool" <[email-masked]> wrote:

A new version of I-D, draft-jenkins-cdni-problem-statement-01.txt has been successfully submitted by Ben Niven-Jenkins and posted to the IETF repository.

Filename:     draft-jenkins-cdni-problem-statement
Revision:     01
Title:         Content Distribution Network Interconnection (CDNI) Problem Statement
Creation_date:     2011-01-17
WG ID:         Independent Submission
Number_of_pages: 33

Abstract:
Content Delivery Networks (CDNs) provide numerous benefits: reduced
delivery cost for cacheable content, improved quality of experience
for End Users and increased robustness of delivery.  For these
reasons they are frequently used for large-scale content delivery.
As a result, existing CDN providers are scaling up their
infrastructure and many Network Service Providers (NSPs) are
deploying their own CDNs.  It is generally desirable that a given
content item can be delivered to an end user regardless of that end
user's location or attachment network.  This creates a requirement
for interconnecting standalone CDNs so they can interoperate as an
open content delivery infrastructure for the end-to-end delivery of
content from Content Service Providers (CSPs) to end users.  However,
no standards or open specifications currently exist to facilitate
such CDN interconnection.

The goal of this document is to outline the problem area for the IETF
with a view towards creating a working group.  This working group
would work on interoperable and scalable solutions for CDN
interconnection.

The IETF Secretariat.

---

From: Mark Carlson <[email-masked]>
Date: Mon, 17 Jan 2011 16:10:57 -0700

Ben,

Thanks for adding the CDMI standard.

I can act as a Liaison to the SNIA group if this group
would like to pursue:

/    The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can
    be associated with data that is stored by a cloud storage provider.
    While the metadata currently defined do not match the need of a CDN
    Interconnect solution, it is worth considering CDMI as one of the
    existing pieces of work that may potentially be leveraged for the
    CDNI Metadata API (e.g by extending the CDMI metadata to address more
    specific CDNI needs)./

further. We are starting to scope the next version of CDMI and are
looking at extensions to the existing standardized metadata.

-- mark
(co-chair of the SNIA Cloud Storage TWG)

On 1/17/11 3:50 PM, Ben Niven-Jenkins wrote:
> On 17/01/2011 22:35, "IETF I-D Submission Tool"<[email-masked]>  wrote:
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Songhaibin <[email-masked]>
Date: Wed, 26 Jan 2011 05:49:46 +0000

Hi Ben,

Thanks for the new draft. I find the draft has listed all the work to enable CDNs to interconnect. But technically, I still have the following comments.

(1) Which APIs can be reused between a CSP and a CDN?

(2) For the real-time data, I do not think having many levels of downstream CDN can guarantee the delay. There should be a mechanism to limit the levels.

By the way, IMO, there are other ways to utilize the NSP CDNs to do a scalable content distribution. That is, make these CDNs as simple storage infrastructure with common APIs, and let a virtual CDN provider to rent the storage service from multiple NSPs to provide the distribution service.

BR,
Haibin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben
> Niven-Jenkins
> Sent: Tuesday, January 18, 2011 6:50 AM
> To: [email-masked]
> Subject: [CDNi] New (-01) version of CDNI Problem Statement draft
> 
> Colleagues,
> 
> - Added a section on "Design Approach for Realizing the CDNI APIs" to provide
> a bit more detail on what a solution may look like and components that could be
> reused.
> - Added a section on "Prioritizing the CDNI Work" which suggest a spilt of the
> problem space into 3 different spaces that could be addressed sequentially in
> order to manage the workload of a WG.
> A new version of I-D, draft-jenkins-cdni-problem-statement-01.txt has been
> successfully submitted by Ben Niven-Jenkins and posted to the IETF repository.
>

---

From: <[email-masked]>
Date: Wed, 26 Jan 2011 08:54:50 +0000

Hi Haibin, see below -

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Songhaibin
> Sent: 26 January 2011 05:50
> To: Ben Niven-Jenkins; [email-masked]
> Subject: Re: [CDNi] New (-01) version of CDNI Problem Statement draft
> 
> Hi Ben,
> 
> Thanks for the new draft. I find the draft has listed all the work to
> enable CDNs to interconnect. But technically, I still have the
> following comments.
> 
> (2) For the real-time data, I do not think having many levels of
> downstream CDN can guarantee the delay. There should be a mechanism to
> limit the levels.

It would be simple enough for the Authoritative CDN or even the User Agent to place a "maximum hop count" on the content Request. However, I don't know how well this would match to metrics such as delay as each CDN Request Routing may be unpredictable and vary between CDNs.

> By the way, IMO, there are other ways to utilize the NSP CDNs to do a
> scalable content distribution. That is, make these CDNs as simple
> storage infrastructure with common APIs, and let a virtual CDN provider
> to rent the storage service from multiple NSPs to provide the
> distribution service.

The general model of a virtual provider or broker using the storage and delivery resources of other CDNs will be covered in the CDNi Use Cases document, which hopefully BT and France Telecom-Orange will be releasing another version shortly. 

> > We have posted a new version of the CDNI Problem Statement, which can
> be
> > found here:
> > On 17/01/2011 22:35, "IETF I-D Submission Tool"
> <[email-masked]>
> > wrote:
> >
> > Title:         Content Distribution Network Interconnection (CDNI)
> Problem
> > Statement

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 26 Jan 2011 11:02:09 +0100

Haibin, Trevor,

On 26 Jan 2011, at 09:54, <[email-masked]> <[email-masked]> wrote:

>> enable CDNs to interconnect.

Good.

>> But technically, I still have the
>> following comments.
>> 

This is currently considered out of scope for the CDNI work.
This is addressed in other forums (eg ATIS, CableLabs Asset Management Interface)

> It would be simple enough for the Authoritative CDN or even the User Agent to place a "maximum hop count" on the content Request. However, I don't know how well this would match to metrics such as…

I also expect we'd want an optional mechanism that can limit the depth of redirection.

>> storage infrastructure with common APIs,

I am not sure this is fundamentally different to what is discussed here. ie define APIs so a CDN can be "enrolled" by another CDN (or a virtual CDN provider, or a Content Provider that elects to support the corresponding APIs if it wishes to do so).

>> and let a virtual CDN provider

Yes. The use-case I-D would be a good place to bring that up.

Cheers

Francois

>>> would work on interoperable and scalable solutions for CDN

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: Songhaibin <[email-masked]>
Date: Wed, 26 Jan 2011 10:48:58 +0000

Hi Trevor and Francois,

Thanks for the reply. See in line.

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Wednesday, January 26, 2011 6:02 PM
To: [email-masked]> <[email-masked]; Songhaibin
Cc: Le Faucheur Francois; Niven-Jenkins Ben; [email-masked]
Subject: Re: [CDNi] New (-01) version of CDNI Problem Statement draft

Haibin, Trevor,

On 26 Jan 2011, at 09:54, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Haibin, see below -

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Songhaibin
Sent: 26 January 2011 05:50
To: Ben Niven-Jenkins; [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] New (-01) version of CDNI Problem Statement draft

Hi Ben,

Good.

[Haibin] OK. It’s not a big issue.

[Haibin] Right. That will impact the start up delay. It might be not easy to limit the delay to a fine-grained level as you said. “As simple as possible” could be the principle for the choice. Otherwise, the interconnected CDNs may need to find the “best path” and measure the RTT between them.

[Haibin] Sorry for my bad English. I think I need a little clarification here. In my previous example, I mean the NSP CDNs which now act as simple storage are agnostic of the application service, just like the in-network storage in DECADE. This storage provides the delivery service. Applications are responsible for the assembling and resolving the meaning of the data. The virtual CDN provider is a broker who provides interfaces to serve CSPs for content distribution. I hope the explanation is clear this time:)

BR,
Haibin

Cheers

Francois

BR,
Haibin

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
Of Ben
Niven-Jenkins
Sent: Tuesday, January 18, 2011 6:50 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [CDNi] New (-01) version of CDNI Problem Statement draft

Colleagues,

A diff from the -00 version can be found here:
http://goo.gl/YtJxk  [tools.ietf.org/rfcdiff<http://tools.ietf.org/rfcdiff>]

A summary of the changes:
- Incorporated feedback from the mailing list and offline comments.
- Added a section on "Design Approach for Realizing the CDNI APIs" to
provide
a bit more detail on what a solution may look like and components
that could be
reused.
- Added a section on "Prioritizing the CDNI Work" which suggest a
spilt of the
problem space into 3 different spaces that could be addressed
sequentially in
order to manage the workload of a WG.
- Expanded the "Gap Analysis of relevant Standardization and
Research".

Ben

On 17/01/2011 22:35, "IETF I-D Submission Tool"
<[email-masked]<mailto:[email-masked]>>
wrote:

A new version of I-D, draft-jenkins-cdni-problem-statement-01.txt has
been
successfully submitted by Ben Niven-Jenkins and posted to the IETF
repository.

Abstract:

The IETF Secretariat.
_______________________________________________
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

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, 26 Jan 2011 17:04:04 +0000

Haibin,

> [Haibin] Right. That will impact the start up delay. It might be not easy to limit the delay to a fine-grained level as you said. “As simple as possible” could be the principle for the choice. Othe…

I agree we will need some (possibly optional) mechanism to enable control over "CDN hop count". I think we have to recognise that anything more complex than "hop count" is likely to be unworkable in the general case. For example RTT time may be attractive from a CSP/Service point of view but implementing it (especially if responses are cacheable and so the RTT when the response was delivered could different to the RTT when the response is processed/used).

That doesn't prevent CDN operators from using RTT (or other metrics) it just means that I don't think it's something that can be easily solved at the protocol level when it is more easily solved through SLA agreements & local policy configuration in the Request Router.

> [Haibin] Sorry for my bad English. I think I need a little clarification here. In my previous example, I mean the NSP CDNs which now act as simple storage are agnostic of the application service, just like the in-network storage in DECADE. This storage provides the delivery service. Applications are responsible for the assembling and resolving the meaning of the data. The virtual CDN provider is a broker who provides interfaces to serve CSPs for content distribution. I hope the explanation is clear this timeJ

That's certainly possible but it's a different problem to the one CDNI is trying to solve. One could have new applications that can make use of distributed in-network storage, but it doesn't help with the current set of applications & services, some of which like web site delivery are going to still be around for a long time. It also pushes the "hard work" onto the application developer (often the CSP) and one of the drivers for CSP's to use CDNs is that the CDN removes the need for the CSP to have to worry about how to engineer efficient, (global) high scale distribution into their applications as that's the job of the CDN.

Ben