Subject: Re: [CDNi] "CDN Interconnect" BOF in Prague - Request for Mailing List creation

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 15 Dec 2010 17:42:35 +0000

David,

On 15 Dec 2010, at 17:38, Ben Niven-Jenkins wrote:

> 
> 
> On 13/12/2010 10:17, "Francois Le Faucheur" <[email-masked]> wrote:
> 
>> Hello David,
>> Coming back to your earlier comments regarding a potential CDNI scope:
>> 
>> On 2 Dec 2010, at 20:49, David Harrington wrote:
>> 
>> And let me make an observation:
>> This looks like a rather wide scope. It looks like a number of protocols
>> for different purposes. You might do better to narrow the scope. We had
>> this discussion in decade, and the IESG is having similar discussions
>> regarding clouds, data centers, and home networking.
>> If you want a WG-creation BOF to be successful, keep the scope narrow.
>> 

Can I ask what leads you to the observation that the scope maybe too wide, for example is it:
- a concern we maybe proposing to work on areas that are better suited to be solved by other groups (including others standards bodies as well as other IETF WGs)
- a concern we may be proposing biting off more than we can chew - I.e. The normal concern that trying to do too much at once spreads the available people/attention span/etc too thinly
- some other concern

The answer may help us better focus the scope to address your concerns rather than trying to second guess the underlying reason for the comment.

Thanks
Ben

---

From: <[email-masked]>
Date: Fri, 17 Dec 2010 17:52:45 +0100

Hi Ben,

The scope seems too wide. I suggest splitting it in 2 parts as following:

- Focus firstly on the standardization of the 'minimum' exchanges of information which are currently missing to enable interconnection of 2 CDNs.  

- Then work on enhanced features.

The first part of the work may consist in specifying the Core deliverables below:

	*  Request-Transfer API

	This API allows the Request-Transfer Function of an upstream CDN to ensure that a user-agent request can be (re)directed to a downstream CDN.

	*  Core mD: Content Distribution Metadata with inter-CDN scope 
	
	  - 'basic' set of metadata for acquisition & distribution of contents;
	
	*  Schema of the Core mD;
	
	* Selection of an IETF protocol to signal Core mD encoded as per the schema;

Regards
Emile

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Ben Niven-Jenkins
> Envoyé : mercredi 15 décembre 2010 18:43
> À : Francois Le Faucher; David Harrington
> Cc : [email-masked]
> Objet : Re: [CDNi] "CDN Interconnect" BOF in Prague - Request for
> MailingList creation
> 
> David,
> 
> - a concern we maybe proposing to work on areas that are better suited to
> be solved by other groups (including others standards bodies as well as
> other IETF WGs)
> - a concern we may be proposing biting off more than we can chew - I.e.
> The normal concern that trying to do too much at once spreads the
> available people/attention span/etc too thinly
> - some other concern
> 
> The answer may help us better focus the scope to address your concerns
> rather than trying to second guess the underlying reason for the comment.
> 
> Thanks
> Ben
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 20 Dec 2010 11:47:17 +0000

Emile,

Thank you for your comments, please see inline below:

> - Then work on enhanced features.

I completely agree that we need to prioritise the order in which we tackle the problem space, however (and this is something we may need to make more explicit in the problem statement) I think the definition of 'minimum' Vs 'enhanced' may be slightly different for different people.

For me, I see the problem space splitting into 3 broad categories:

1) Those parts that would be classed as the 'minimum' needed to actually deliver any content using interconnected CDNs, e.g. Request Routing API & Metadata API.

2) Those parts that would be classed as the 'minimum' needed to 'operationalise' CDN Interconnects, e.g. Logging API & some aspects of Control API (e.g. content deletion)

3) 'Enhanced features', e.g. automatic bootstrapping of interfaces etc.

Without (1) we have no useable solution. Without (2) operators cannot deploy and operate the solution at scale (or alternatively they are forced to implement bi-lateral proprietary interfaces to solve the problem space for themselves).

I can see that we need to balance the work we take on with the amount of people we have working on it and therefore we could choose to concentrate on problem space (1) and start work on (2) once we have reached a certain maturity with solutions to problem space (1).

However although we may not develop solutions to problem space (2) immediately, I do not think we can completely ignore it, especially during requirements gathering, so we don't unnecessarily cause ourselves pain later because of our early design decision (as we would like all the interfaces to be as closely aligned as possible).

Is that similar to what you were thinking?

> * Selection of an IETF protocol to signal Core mD encoded as per the schema;

This aligns pretty well with my view on what could be considered as problem space (1) above :-)

Regards
Ben

---

From: <[email-masked]>
Date: Mon, 20 Dec 2010 17:21:36 +0100

Hi Ben and Francois,
 
I like your decompositions of the problem statements in 3 categories. Having this decomposition will ease the classification of the requirements and of the CDNi metadata in 3 categories.
 
I agree with the benefits of collecting the requirements for (1) and (2) at the same time. So my concern is that the discussions on (2) could delay the start of the work on (1). This must handle carefully because despite the Problem space (1) is very clear and narrow, the writing of the specifications will require a lot of works. 
 
Recall of my view: 
 
3 categories:
 
1) Those parts that would be classed as the 'minimum' needed to actually deliver any content using interconnected CDNs, e.g. Request Routing API & Metadata API. The first part of the WG work may consist in specifying the Core deliverables below:
 
  *  Request-Transfer API
 
  This API allows the Request-Transfer Function of an upstream CDN to ensure
  that a user-agent request can be (re)directed to a downstream CDN.

 
  *  Schema of the Core mD;
 
  * Selection of an IETF protocol to signal Core mD encoded as per 
    the schema;

2) Those parts that would be classed as the 'minimum' needed to 'operationalise' CDN Interconnects, e.g. Logging API & some aspects of Control API (e.g. content deletion); 

Regards
Emile
 
> De : Ben Niven-Jenkins [mailto:[email-masked]]
> Envoyé : lundi 20 décembre 2010 12:47
> À : STEPHAN Emile RD-CORE-LAN
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : Re: [CDNi] "CDN Interconnect" BOF in Prague - scope
> 
> Emile,
> 
> On 17 Dec 2010, at 16:52, <[email-masked]>
> <[email-masked]> wrote:
> 
> > Hi Ben,
> >
> > - Focus firstly on the standardization of the 'minimum' exchanges of
> information which are currently missing to enable interconnection of 2
> CDNs.
> >
> I completely agree that we need to prioritise the order in which we tackle
> the problem space, however (and this is something we may need to make more
> explicit in the problem statement) I think the definition of 'minimum' Vs
> 'enhanced' may be slightly different for different people.
> 
> 1) Those parts that would be classed as the 'minimum' needed to actually
> deliver any content using interconnected CDNs, e.g. Request Routing API &
> Metadata API.
> 
> 2) Those parts that would be classed as the 'minimum' needed to
> 'operationalise' CDN Interconnects, e.g. Logging API & some aspects of
> Control API (e.g. content deletion)
> 
> Without (1) we have no useable solution. Without (2) operators cannot
> deploy and operate the solution at scale (or alternatively they are forced
> to implement bi-lateral proprietary interfaces to solve the problem space
> for themselves).
> 
> I can see that we need to balance the work we take on with the amount of
> people we have working on it and therefore we could choose to concentrate
> on problem space (1) and start work on (2) once we have reached a certain
> maturity with solutions to problem space (1).
> 
> However although we may not develop solutions to problem space (2)
> immediately, I do not think we can completely ignore it, especially during
> requirements gathering, so we don't unnecessarily cause ourselves pain
> later because of our early design decision (as we would like all the
> interfaces to be as closely aligned as possible).
> 
> > This API allows the Request-Transfer Function of an upstream CDN to
> ensure that a user-agent request can be (re)directed to a downstream CDN.
> >

---

From: <[email-masked]>
Date: Wed, 22 Dec 2010 00:26:44 +0100

Hi
 
Aside from the previous discussions I think that the gap analysis discussion may be included in a section which starts with a description of the SDOs and collaborative projects.
 
I suggest the following description of TISPAN and OIPF:
 
ETSI TISPAN: 

   TISPAN has published two sets of IPTV specifications, one of which is based
   on IMS.  In addition, TISPAN is about to complete the specifications of a 
   CDN architecture supporting delivery of various content services such as
   time-shifted TV and VoD to TISPAN devices (UEs) or regular PCs.  The use
   cases allow for hierarchically and geographically distributed CDN scenarios,
   along with multi-CDN cooperation.  As a result, the architecture contains
   reference points to support interconnection of other TISPAN CDNs.  
   The protocols phase for the CDN architecture has been started end of 2010.
 
Open IPTV Forum (OIPF):
 
OIPF specifications are freely available at http://www.oipf.tv/specifications.html
 
   The Open IPTV Forum has fully specified [OIPF-Overview] an end-to-end solution to allow
   Any OIPF terminal to access enriched and personalised IPTV services
   either in a managed or a non-managed network. Services like CoD, nPVR and Personal Channel... are hosted in a CDN.
   To that end, the Open IPTV Forum specification is made of 5 parts:
 
- Media Formats including HTTP Adaptive Streaming
- Content Metadata
- Protocols
- Terminal (Declarative or Procedural Application Environment)
- Authentication, Content Protection and Service Protection
 
I can provide a review of this section if you wish.
 
Regards
Emile

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 20 décembre 2010 17:22
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : Re: [CDNi] "CDN Interconnect" BOF in Prague - scope
 
Hi Ben and Francois,

 
Recall of my view: 
 
3 categories:

  *  Request-Transfer API

 
 
  *  Schema of the Core mD;

 
 
Regards
Emile
 
> problem space (1) above :-)
 
________________________________

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 23 Dec 2010 10:42:48 +0000

Emile,

> I like your decompositions of the problem statements in 3 categories. Having this decomposition will ease the classification of the requirements and of the CDNi metadata in 3 categories.

OK I will work some text based on your e-mail below into the next revision of the problem statement to try and add some extra clarity.
 
> I agree with the benefits of collecting the requirements for (1) and (2) at the same time. So my concern is that the discussions on (2) could delay the start of the work on (1). This must handle ca…

This is indeed a risk, but I think the solution is to be pragmatic. We do not necessarily need exhaustive requirements for problem space (2) before specifying a solution for problem space (1) but we should be reasonably confident we are aware of the at least the key requirements (and the more requirements we know the better we can take problem space (2) into consideration).

In other words, at a minimum we need enough requirements to be confident we are not going down a dead end when solving problem space (1) so that we do not have to try and reverse later.

Regards
Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 23 Dec 2010 10:47:13 +0000

Emile,

I do not quite understand what you are suggesting.

The text you have below is similar to the text we already have in the problem statement draft, are you proposing we replace (or merge) the existing text with what you have written below? We can certainly do that.

Or, are you suggesting we include additional material/background text, in which case any review or proposal you could provide would be most welcome (I do not participate in either ETSI or OIPF).

Thanks
Ben

---

From: <[email-masked]>
Date: Thu, 23 Dec 2010 19:47:00 +0100

Hi Ben

See below,

> Envoyé : jeudi 23 décembre 2010 11:47
> Cc : [email-masked]; [email-masked]
> Objet : Re: "CDN Interconnect" BOF in Prague - SDOs descriptions
> 
> Emile,
> 

The "Gap analysis in standardization" presents each SDO and at the same time starts to discuss the works of each SDO with regards of CDNi aspects. 

I think that it is preferable to start by a 'flat' presentation of the  bodies involved in CDNs and then to discuss each CDNi aspects in a dedicated section.  
I inserted a proposal at the end of the mail.

> 
> The text you have below is similar to the text we already have in the
> problem statement draft, are you proposing we replace (or merge) the
> existing text with what you have written below? We can certainly do that.

The text in the PS does not reflect the works of OIPF and TISPAN. 

Regarding TISPAN, the CDN specification is not an extension of the IPTV specifications. IPTV must be rather seen as a particular TISPAN-specified CDN user. Common activities with ETSI MCD will likely result in common specifications for CDN interconnection...

Regarding OIPF the description made in the PS does not mention that the end-to-network aspects include interaction with a CDN and dissemination of content distribution metadata... 

The descriptions we provide reflect the current works in these bodies.

> 
> Or, are you suggesting we include additional material/background text, in
> which case any review or proposal you could provide would be most welcome
> (I do not participate in either ETSI or OIPF).

------------------------------------------------------------------ 

Draft of Proposal: for the section 3

3. State of the art on standardization

This section presents the state of the art of standardization related to CDN and Content services such as IPTV and CoD. Then it discusses the gaps in the standardisation of CDN interconnection for dataplane, CDN, Content Distribution Metadata, IPTV and CoD.
<TODO: add request transfert >

3.1 relevant Standardization Activities

3GPP:

  3GPP has specified a Progressive Download and Dynamic Adaptive Streaming over HTTP [3GP-DASH] based on a Media Presentation Description (MPD) and Media Segmentation Format.

   It may be a candidate for content acquisition between CDNs in a CDN Interconnect environment

ATIS IIF:

   ATIS [ATIS] is the Alliance for Telecommunications Industry
   Solutions. IIF is the IPTV Interoperability Forum within ATIS that develops
   requirements, standards, and specifications for IPTV.

   The IIF is developing the "IPTV Content on Demand (CoD) Service"
   specification.  This includes use of a CDN (referred to in ATIS IIF
   CoD as the "Content Distribution and Delivery Functions") for support
   of a Content on Demand (CoD) Service as part of a broader IPTV
   service.  However, this only covers the case of a managed IPTV
   service (in particular where the CDN is administered by the IPTV
   service provider) and does not cover the use, or interconnection, of
   multiple CDNs.

CableLabs:

   "Founded in 1988 by cable operating companies, Cable Television
   Laboratories, Inc. (CableLabs) is a non-profit research and
   development consortium that is dedicated to pursuing new cable
   telecommunications technologies and to helping its cable operator
   members integrate those technical advancements into their business
   objectives."  [CableLabs]

   Cable Labs has defined specifications for CoD Content Metadata as
   part of its VOD Metadata project. 

ETSI:

   ETSI is the European Telecommunications Standards Institute.  ETSI
   produces standards for Information and Communications Technologies
   (ICT), including fixed, mobile, radio, converged, broadcast and
   internet technologies.

ETSI MCD:

   MCD (Media Content Distribution) is the ETSI technical committee "in
   charge of guiding and coordinating standardization work aiming at the
   successful overall development of multimedia systems (television and
   communication) responding to the present and future market requests
   on media content distribution".

   MCD created a specific work item on interconnection of heterogeneous
   CDNs ("CDN Interconnection, use cases and requirements") in March
   2010.  However, no protocol level work has yet started in MCD for CDN
   Interconnect.

ETSI TISPAN: 

Eurescom P1955

This 2010 project involving European Network operators, studied the interests and feasibility of interconnecting CDNs by firstly elaborating main service models around CDN interconnection, analysing an adequate CDN interconnection technical architecture and framework, and finally by providing recommendations for telcos to implement CDN interconnection. Eurescom project has ended in July 2010.

IETF CDI WG:

IETF CDI WG was formed in 2000 and closed in 2003.  

It published 3 Informational RFCs:

   o  RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)".
   o  RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing
      Mechanisms".
   o  RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios".

Following is an extract of its charter [CDI-Charter] showing that it 
touched on the same problem space:
   o  The goal of this working group is to define protocols to allow the
      interoperation of separately-administered content networks.
   o  A content network is an architecture of network elements, arranged
      for efficient delivery of digital content.  Such content includes,
      but is not limited to, web pages and images delivered via HTTP,
      and streaming or continuous media which are controlled by RTSP.
   o  The working group will first define requirements for three modes
      of content internetworking: interoperation of Request-Transfer
      systems, interoperation of distribution systems, and
      interoperation of accounting systems.  These requirements are
      intended to lead to a follow-on effort to define protocols for
      interoperation of these systems.
   o  In its initial form, the working group is not chartered to deliver
      those protocols [...]

IETF Decade WG:

It specifies cache control interoperability.
<TODO: complete with some description of the interfaces and a sht on the cd policy>

IRTF P2P Research Group:

   Some information on CDN interconnection motivations and technical
   issues were presented in the P2P RG at IETF 77.  The presentation can
   be found in [P2PRG-CDNI].

ITU-T:
  
SG13 is developing standards related to the support of IPTV services (i.e.. multimedia services such as television/VoD/audio/text/graphics/data delivered over IP-based networks managed).

ITU-T Recommendation Y.1910 provides the description of the IPTV functional architecture. This architecture includes functions and interfaces for the distribution and delivery of contents. This architecture is closed to ATIS IIF architecture.

Based upon ITU-T Rec. Y.1910, Rec. IUT-T Y.2019 describes in more details the content delivery functional architecture. This architecture allows CDN Interconnection: some interfaces (such as D3, D4) at the control level allow relationship between different CDNs, in the same domain or in different domains. 
Generic procedures are described, but the choice of the protocols is open.

Open IPTV Forum (OIPF):

   The Open IPTV Forum has fully specified [OIPF-Overview] an end-to-end solution to allow
   Any OIPF terminal to access enriched and personalised IPTV services
   either in a managed or a non-managed network. Services like nPVR and Personal Channel are hosted in a CDN.
   To that end, the Open IPTV Forum specification is made of 5 parts:

OCEAN:

OCEAN (http://www.ict-ocean.eu/) is an EU funded research project that started in February 2010 for 3 years.  Some of its objectives are relevant to CDNI. It aims among others at designing a new architectural framework for audiovisual content delivery over Internet, defining public interfaces between its major building blocks in order to foster multi-vendor solutions and interconnection between Content Networks (the term "Content Networks" corresponds here to the definition introduced in [IETF RFC3466], it encompasses CDNs)
OCEAN has not yet published any open specifications, nor common best practices, defining how to achieve such CDN interconnection."

TV-Anytime Forum:

The Version 1 of its specifications was published as TS 102 822-1 'Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime")'. It includes the specification of metadata in XML schemas which define technical parameters for the distribution of CoD and Live contents. The specification is referenced by DVB and OIPF. The TV-Anytime URI (CRID) is specified in RFC4078. 

The specifications are available at http://www.tv-anytime.org/. The TV-anytime Forum was closed in 2005. 

3.2 Gap Analysis in standardization

Todo

Regards
Emile

---

From: <[email-masked]>
Date: Fri, 24 Dec 2010 17:17:24 +0100

Hi Ben,

See inline

> Envoyé : jeudi 23 décembre 2010 11:43
> On 20 Dec 2010, at 16:21, <[email-masked]>
> > I like your decompositions of the problem statements in 3 categories.
> Having this decomposition will ease the classification of the requirements
> and of the CDNi metadata in 3 categories.
> 
> OK I will work some text based on your e-mail below into the next revision
> of the problem statement to try and add some extra clarity.
> 
> > I agree with the benefits of collecting the requirements for (1) and (2)
> at the same time. So my concern is that the discussions on (2) could delay
> the start of the work on (1). This must handle carefully because despite
> the Problem space (1) is very clear and narrow, the writing of the
> specifications will require a lot of works.
> 
> This is indeed a risk, but I think the solution is to be pragmatic.
> We do not necessarily need exhaustive requirements for problem space (2) before
> specifying a solution for problem space (1) but we should be reasonably
> confident we are aware of the at least the key requirements (and the more
> requirements we know the better we can take problem space (2) into
> consideration).

Of course we will collect all the requirements and store them as req for (1) or (2). The point is that late reqs related to (2) should not delay the work on the documents of (1). I think that the requirements of the problem space (1) must be worked out in a distinct document.

> 
> In other words, at a minimum we need enough requirements to be confident
> we are not going down a dead end when solving problem space (1) so that we
> do not have to try and reverse later.
> 
> Regards
> Ben
> 
> >
> > Recall of my view:
> >
> > 3 categories:
> >
> Metadata API. The first part of the WG work may consist in specifying the
> Core deliverables below:
> >
> >   *  Request-Transfer API
> >
> ensure
> Control API (e.g. content deletion);
> >

Regards
Emile