Subject: [CDNi] Problem Statement: Terminology

From: <[email-masked]>
Date: Tue, 11 Jan 2011 14:40:40 +0100

Hi Ben,
 
I went through the terminology section. I think that it make sense to split the Request Routing in 2 functions. The first function (Request Transfer) handles the content request; the second (Request Routing) determines the appropriate source of content.
 
   Request Transfer: 
   The function within a CDN responsible for receiving a content request from a User-agent, for querying the Request routing function and for directing this query toward the selected source of content.
 
    Request Routing: 
    The function within a CDN responsible for determining the appropriate Surrogate or the appropriate CDN.

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Ben Niven-Jenkins
> Envoyé : lundi 20 décembre 2010 11:59
> À : Francois Le Faucheur
> Cc : [email-masked]; Lee, Yiu
> Objet : Re: [CDNi] Few comments on Problem Statement
> 
> Francois,
> 
> On 17 Dec 2010, at 08:20, Francois Le Faucheur wrote:
> 
> > Hi Yiu,
> >
> > On 16 Dec 2010, at 20:05, Lee, Yiu wrote:
> >>
> >> [YL] I am somewhat more clear. Thanks for the explanation. If Content
> >> Distribution Metadata is used by the CDNi, why not simply called it
> CDNi
> >> Metadata?
> >
> > As per recent discussion with Richard, we observed that Content
> Distribution Metadata comprises metadata of intra-CDN scope (ie only
> relevant within a CDN) and metadata of inter-CDN scope (ie relevant across
> CDNs).
> >
> > So, to be more accurate, we could use the term "CDNi Metadata" to
> designate the Content Distribution Metadata of inter-CDN scope (which is
> quite of a mouthful).
> >
> > So the definition would look like this:
> >
> > "
> > Metadata: data about data.
> >
> > Content Metadata: metadata about content. Content Metadata comprises:
> >   (i) metadata that is relevant to the distribution of the content
> (and therefore relevant to a CDN involved in the delivery of that content).
> We refer to those as "Content Distribution Metadata".
> >   (ii) metadata that is associated with the actual content (and not
> directly relevant to the distribution of that content) or content
> representation. For example, such metadata may include Genre, Cast, Rating
> as well as resolution and aspect ratio.
> >
> > Content Distribution Metadata: the subset of Content Metadata that is
> relevant to the distribution of the content.
> > This is the metadata required by a CDN in order to enable and control
> content distribution and delivery by the CDN. In a CDN Interconnection
> environment, some of the Content Distribution Metadata may have an intra-
> CDN scope (and therefore need not be communicated between CDNs), while
> some of the Content Distribution Metadata have an inter-CDN scope (and
> therefore need to be communicated between CDNs). For example, Content
> Distribution Metadata with inter-CDN scope may include geo-blocking
> information (i.e. information defining geographical areas where the
> content is to be made available or blocked), availability windows (i.e.
> information defining time windows during which the content is to be made
> available or blocked) and access control mechanisms to be enforced (e.g.
> URI signature validation).
> >
> > CDNi Metadata: Content Distribution Metadata with inter-CDN scope
> > "
> >
> > How does that sound?
> >
> 
> Looks good to me :-)
> 
> Ben
> 
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: <[email-masked]>
Date: Tue, 11 Jan 2011 16:43:29 +0000

Emile

Is this distinction purely to make the terminology easier, or do you see the need for two separate functions in an implementation? The latter would imply a change in Figure 1 in the problem-statement i-d, ie a protocol between your two functions

Thanks
Best wishes
phil

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 11 January 2011 13:41
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [CDNi] Problem Statement: Terminology

Hi Ben,

   Request Transfer:

    Request Routing:

---

From: <[email-masked]>
Date: Tue, 11 Jan 2011 18:18:01 +0100

Hi Phil,
 
This is to clarify the "Request Routing System" term.

Regards
Emile

________________________________

De : [email-masked] [mailto:[email-masked]] 
Envoyé : mardi 11 janvier 2011 17:43
À : STEPHAN Emile RD-CORE-LAN; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: Problem Statement: Terminology
 
Emile

Thanks
Best wishes
phil 

Hi Ben,

   Request Transfer: 
 
    Request Routing:

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Tue, 11 Jan 2011 16:25:17 -0500

Hi,
I think it is fine to refine the definition of the functions. I would like to suggest  tough some modification to the proposed definitions and see what you and Ben think:

Request transfer: The function within a CDN responsible for receiving a content request from a user-agent, querying the request routing function for candidate surrogates, and for selecting and redirecting the user to the appropriate surrogate or CDN.

Request routing (I am not sure the best name): The function within a CDN responsible for determining the candidate list of surrogates for the request-transfer function to deliver content to a user-agent.

Thanks,
Nabil

On 1/11/11 8:40 AM, "[email-masked]" <[email-masked]> wrote:

Hi Ben,

   Request Transfer:

    Request Routing:

> > CDNi Metadata: Content Distribution Metadata with inter-CDN scope

---------------------------------------------
Nabil Bitar, PhD
Principal Member of Technical Staff
Packet Network Technology
Verizon Corporate Network and Technology

60 Sylvan Road
Waltham, MA 02451
Office Phone: (781) 466-2161

---

From: <[email-masked]>
Date: Wed, 12 Jan 2011 10:16:54 +0000

I'm still trying to see what difference Emile and yourself are trying to bring out.

The overall request routing is from the first client contact until the identification of the surrogate. This includes the sub-functions of identifying the correct CDN and identifying the surrogate within the CDN. However, at this stage I'm not sure how distinct these two sub-functions might be. For example, a single function could select either a CDN or local surrogate, or might even be able to select a remote surrogate directly.

Or are we trying to say that there is a requirement to handle the very first client contact differently? E.g. authentication, location determination. I'm hesitant about this as well since the communication pattern might be recursive through the initial CDN or may be iterative (in which case the surrogate selection also has to perform these same client facing functions).

Trevor.

Trevor Burbridge
Network-Based Services Infrastructure | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

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
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bitar, Nabil N
Sent: 11 January 2011 21:25
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [CDNi] Problem Statement: Terminology

Hi,

Thanks,
Nabil

   Request Transfer:

    Request Routing:

60 Sylvan Road
Waltham, MA 02451

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 12 Jan 2011 11:04:57 +0000

Emile, Nabil,

Thanks for the suggestion. We can certainly try to better clarify the term Request Routing System. However, I am not sure decomposing it into two terms is the best way to achieve that as we would introduce a new term that we don't subsequently use and for CDNI, only inter-CDN Request Routing (i.e. between Request Routing Systems in different CDNs) should be in scope and the internals of the Request Routing System in each CDN should remain out of scope.

If we look at the definition of Request Routing System in the -00 Problem statement we have:

   Request Routing System: The function within a CDN responsible for
   steering or directing a content request received directly from an end
   user to a suitable Surrogate.

I suggest we incorporate some of the clarifying detail of your suggestions into the definition of Request Routing System but keep it as a single term encompassing the entire Request Routing System.

My proposal would be:

   Request Routing System: The function within a CDN responsible for
   for receiving a content request from a user agent, obtaining a set
   of candidate surrogates, and for selecting and redirecting the user
   to the appropriate surrogate or CDN. To enable CDN Interconnect, the
   Request Routing System must also be capable of handling user agent
   content requests passed to it by another CDN.

Would that achieve the clarification you suggest?

Thanks
Ben

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 12 Jan 2011 14:33:54 +0100

Ben, Emile and all,

Like Ben I don't the need to break down the Request-Routing System into two entity.

But I suspect that what Emile was getting at (beyond terminology), is the following point that is relevant for CDNi:

Request-Routing Systems in two neighbor CDNs may need to interact for two different purposes:
	(A) exchange of information about a Downstream CDN that allows an Upstream CDN to make "more informed" Request-Routing decisions (eg Downstream CDN may indicate that it has on-net cache coverage of such IP-address range footprint, e.g. Downstream CDN may indicate that it is currently "overloaded" in some geography)
	(B) actual redirection of a given request (ie once Upstream CDN has selected a given Downstream CDN, it communicates with that Downstream CDN to facilitate the actual redirection of a given user request.)

I agree it is important to keep in mind this distinction for the definition of CDNi interactions.
I believe the current Problem Statement already reflects that distinction:
		- it discusses the (A) interactions as part of the "CDNi Control API":
"
      *  CDNI Control API: This API allows the "CDNI Control" system in
         interconnected CDNs to communicate.  This API may support the
         following:
	<clip>
         +  allows the downstream CDN to communicate information about
            its delivery capabilities, resources and policies
	<clip>
"
		- it discusses the (B) interactions as part of the "CDNi Request-Routing API":
"
      *  Request-Routing API: This API allows the Request-Routing system
         in interconnected CDNs to communicate to ensure that an end-
         user request can be (re)directed from an upstream CDN to a
         surrogate in the downstream CDN, in particular where selection
         responsibilities may be split across CDNs (for example the
         upstream CDN may be responsible for selecting the downstream
         CDN while the downstream CDN may be responsible for selecting
         the actual surrogate within that CDN).
"

So I think we are good with respect to the CDNi model.

With respect to terminology, one could argue that the "CDNi Request-Routing API" would be slightly more accurately described as the "CDNi Request-Transfer API" (or "CDNi Request-Redirection API"), since it is to be used for the (B) interactions. I don't feel strongly about this as long as we are clear it is to be used for (B) interactions.

A few suggestions below on the changes proposed by Ben:

On 12 Jan 2011, at 12:04, Ben Niven-Jenkins wrote:

>   to the appropriate surrogate or CDN.

"obtaining a set of candidate surrogates" may incorrectly suggest that an Upstream CDN needs to know about surrogates in the Downstream CDN.
How about:
"
Request Routing System: The function within a CDN responsible for
  for receiving a content request from a user agent, obtaining and maintaining necessary information about a set
  of candidate surrogates or candidate CDNs, and for selecting and redirecting the user
  to the appropriate surrogate or CDN."

Cheers

Francois

> To enable CDN Interconnect, the

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: "Bitar, Nabil N" <[email-masked]>
Date: Wed, 12 Jan 2011 08:44:14 -0500

Hi Ben,
I am fine with not decomposing and below. I was suggesting the re-wording if we are to decompose.
Thanks,
Nabil

On 1/12/11 6:04 AM, "Ben Niven-Jenkins" <[email-masked]> wrote:

Emile, Nabil,

My proposal would be:

Thanks
Ben

60 Sylvan Road
Waltham, MA 02451

---

From: <[email-masked]>
Date: Wed, 12 Jan 2011 14:01:16 +0000

One thing I'd also like to challenge -

So far a lot of the discussion has centred around identifying an authoritative CDN which then pushes the request (and content) down. This model obviously fits well with DNS approaches to request routing where the DNS will identify the authoritative CDN. It may also end up being the preferred solution.

However, when talking about problems/use cases/requirements this seems a little premature. For example we should at least entertain pull models where the client initially comes into their choice of local CDN. In this case the CDNs would need to be able to share control information about content availability. Content may already be available locally either because an authoritative CDN has pushed it their or because the local CDN has pulled it. The local CDN could hand over to a CDN with the content or might stream it through the local CDN and cache for the next user.

Are all these sorts of latter options in scope? If they are then we should make sure the terminology is suitably generic.

Trevor.

Trevor Burbridge

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francois Le Faucheur
> Sent: 12 January 2011 13:34
> To: Ben Niven-Jenkins
> Cc: [email-masked]
> But I suspect that what Emile was getting at (beyond terminology), is
> the following point that is relevant for CDNi:
> 
> 	(A) exchange of information about a Downstream CDN that allows an
> Upstream CDN to make "more informed" Request-Routing decisions (eg
> Downstream CDN may indicate that it has on-net cache coverage of such
> IP-address range footprint, e.g. Downstream CDN may indicate that it is
> currently "overloaded" in some geography)
> 	(B) actual redirection of a given request (ie once Upstream CDN
> has selected a given Downstream CDN, it communicates with that
> Downstream CDN to facilitate the actual redirection of a given user
> request.)
> 
> With respect to terminology, one could argue that the "CDNi Request-
> Routing API" would be slightly more accurately described as the "CDNi
> Request-Transfer API" (or "CDNi Request-Redirection API"), since it is
> to be used for the (B) interactions. I don't feel strongly about this
> as long as we are clear it is to be used for (B) interactions.
> 
> > Thanks for the suggestion. We can certainly try to better clarify the
> term Request Routing System. However, I am not sure decomposing it into
> two terms is the best way to achieve that as we would introduce a new
> term that we don't subsequently use and for CDNI, only inter-CDN
> Request Routing (i.e. between Request Routing Systems in different
> CDNs) should be in scope and the internals of the Request Routing
> System in each CDN should remain out of scope.
> >
> > I suggest we incorporate some of the clarifying detail of your
> suggestions into the definition of Request Routing System but keep it
> as a single term encompassing the entire Request Routing System.
> >
> > My proposal would be:
> >
> "obtaining a set of candidate surrogates" may incorrectly suggest that
> an Upstream CDN needs to know about surrogates in the Downstream CDN.
> How about:
> "
>   for receiving a content request from a user agent, obtaining and
> maintaining necessary information about a set
> >> I think it is fine to refine the definition of the functions. I
> would like to suggest  tough some modification to the proposed
> definitions and see what you and Ben think:
> >>
> >> Request transfer: The function within a CDN responsible for
> receiving a content request from a user-agent, querying the request
> routing function for candidate surrogates, and for selecting and
> redirecting the user to the appropriate surrogate or CDN.
> >>
> >> Request routing (I am not sure the best name): The function within a
> CDN responsible for determining the candidate list of surrogates for
> the request-transfer function to deliver content to a user-agent.
> >>
> >> Thanks,
> >> Nabil
> >>
> >>
> >> On 1/11/11 8:40 AM, "[email-masked]"
> <[email-masked]> wrote:
> >>
> >> Hi Ben,
> >>
> >> I went through the terminology section. I think that it make sense
> to split the Request Routing in 2 functions. The first function
> (Request Transfer) handles the content request; the second (Request
> Routing) determines the appropriate source of content.
> >>
> >>   Request Transfer:
> >>   The function within a CDN responsible for receiving a content
> request from a User-agent, for querying the Request routing function
> and for directing this query toward the selected source of content.
> >>
> >>    Request Routing:
> >>    The function within a CDN responsible for determining the
> appropriate Surrogate or the appropriate CDN.
> >>
> >>
> >>> De : [email-masked] [mailto:[email-masked]] De la
> part
> >>> de Ben Niven-Jenkins Envoyé : lundi 20 décembre 2010 11:59 À :
> >>> Francois Le Faucheur Cc : [email-masked]; Lee, Yiu Objet : Re:
> [CDNi]
> >>> Few comments on Problem Statement
> >>>
> >>> Francois,
> >>>
> >>>>> [YL] I am somewhat more clear. Thanks for the explanation. If
> >>>>> Content Distribution Metadata is used by the CDNi, why not simply
> >>>>> called it
> >>> CDNi
> >>>>> Metadata?
> >>>>
> >>> relevant within a CDN) and metadata of inter-CDN scope (ie relevant
> >>> across CDNs).
> >>>>
> >>> designate the Content Distribution Metadata of inter-CDN scope
> >>> (which is quite of a mouthful).
> >>>>
> >>> representation. For example, such metadata may include Genre, Cast,
> >>> Rating as well as resolution and aspect ratio.
> >>>>
> >>> content distribution and delivery by the CDN. In a CDN
> >>> Interconnection environment, some of the Content Distribution
> >>> Metadata may have an intra- CDN scope (and therefore need not be
> >>> communicated between CDNs), while some of the Content Distribution
> >>> Metadata have an inter-CDN scope (and therefore need to be
> >>> communicated between CDNs). For example, Content Distribution
> >>> Metadata with inter-CDN scope may include geo-blocking information
> >>> (i.e. information defining geographical areas where the content is
> to be made available or blocked), availability windows (i.e.
> >>> information defining time windows during which the content is to be
> >>> made available or blocked) and access control mechanisms to be
> enforced (e.g.

---

From: <[email-masked]>
Date: Wed, 12 Jan 2011 14:29:16 +0000

> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: 12 January 2011 14:22
> To: Burbridge,T,Trevor,DES8 R
> Trevor,
> On 12 Jan 2011, at 14:01, <[email-masked]>
> <[email-masked]> wrote:
> 
> > So far a lot of the discussion has centred around identifying an
> authoritative CDN which then pushes the request (and content) down.
> This model obviously fits well with DNS approaches to request routing
> where the DNS will identify the authoritative CDN. It may also end up
> being the preferred solution.
> >
> > However, when talking about problems/use cases/requirements this
> seems a little premature. For example we should at least entertain pull
> models where the client initially comes into their choice of local CDN.
> 
> I am struggling a little to see how this would work. I am not sure how
> the client/User Agent can choose a CDN, as such.
> 
> Something (e.g. the CSP's Portal) will provide the User Agent with a
> URI to the content it requires. The User Agent follows that URI and
> requests the content. However the User Agent has no control over how
> that URI is resolves.

That's what I mean - are we starting with the assumption of a URI? Not unreasonable, but we're already eliminating other ways of identifying content. Even if we have a URI, the user agent might not use DNS but route the request through CDN routing capability (as for Content Centric Networking). In this case it doesn't have to get as far as the authoritative CDN but can stop wherever it first finds the content. For example and IPTV client may initially direct requests to its 'home' CDN.

Or we can rule these out of scope...

> Or are you talking about a case where because of DNS caching a
> subsequent User Agent ends up connecting to the same surrogate without
> any further interaction between the User Agent's DNS resolver and the
> Request Routing system in a CDN?

I wasn't, but this is another alternative!

> Thanks
> Ben
> 
> 
> > In this case the CDNs would need to be able to share control
> information about content availability. Content may already be
> available locally either because an authoritative CDN has pushed it
> their or because the local CDN has pulled it. The local CDN could hand
> over to a CDN with the content or might stream it through the local CDN
> and cache for the next user.
> >
> > Are all these sorts of latter options in scope? If they are then we
> should make sure the terminology is suitably generic.

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 12 Jan 2011 16:30:18 +0100

Hello Trevor,

On 12 Jan 2011, at 15:01, <[email-masked]> wrote:

> So far a lot of the discussion has centred around identifying an authoritative CDN

Right. 
I guess our starting point is the typical mode of operation between a CSP and one CDN. And we focus on extending this downstream, ie so the CDN can redirect to another CDN. 

> which then pushes the request (and content) down. This model obviously fits well with DNS approaches to request routing where the DNS will identify the authoritative CDN.

Yes, it fits well with use of DNS to get the request to the "authoritative CDN". Kind of like it often works today. Although other approaches could be thought of (eg application level selection of top CDN via dynamic URI). 
But note that the technique used to direct the user to the Authoritative CDN (eg DNS) is independent of the technique used to redirect requests across CDNs (eg DNS, HTTP),

> It may also end up being the preferred solution.
> 
> However, when talking about problems/use cases/requirements this seems a little premature.

In the usecase I-D, I am expecting authors to describe the use cases for which they have real/likely plans to deploy. This will ensure we focus on the right problem to solve.
My perception is that there is a set of clear real-life use cases (indeed typically assuming a sort of top-down delegation model allowing operators to interconnect existing CDNs) that need a solution. Beyond that, there is a trade-off in trying to define a more generic/flexible solution and defining a bite that a WG can swallow. 

Cheers

Francois

> For example we should at least entertain pull models where the client initially comes into their choice of local CDN. In this case the CDNs would need to be able to share control information about content availability. Content may already be available locally either because an authoritative CDN has pushed it their or because the local CDN has pulled it. The local CDN could hand over to a CDN with the content or might stream it through the local CDN and cache for the next user.
> 

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

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

 Think before you print.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 12 Jan 2011 16:00:36 +0000

On 12 Jan 2011, at 14:29, <[email-masked]> <[email-masked]> wrote:
> That's what I mean - are we starting with the assumption of a URI?

The Internet uses URIs to reference content so I think it's a valid assumption to start from, and it's the way User Agent's reference content in the deployed CDNs I am aware of.

> Not unreasonable, but we're already eliminating other ways of identifying content.

> Even if we have a URI, the user agent might not use DNS but route the request through CDN routing capability (as for Content Centric Networking).

The concern I have with assuming something other than a URI is that I am not sure there is practical experience of operating these new models of content networking at scale and so we run the risk of moving away from engineering into research. Part of my motivation for solving CDNI is that we have customers with existing CDNs asking to be able to interconnect with the existing CDNs of other operators.

> In this case it doesn't have to get as far as the authoritative CDN but can stop wherever it first finds the content. For example and IPTV client may initially direct requests to its 'home' CDN.
> 

I'd be interested in the views of others, but my personal view is we try to steer clear of unproven content models and focus on solving the problem of a lack of CDN interconnect standards that can be used to interconnect existing CDNs.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 12 Jan 2011 16:01:51 +0000

FYI, I thought I had included the cdni@ietf list in my original response to Trevor, but it appears that I hadn't.

Ben

Begin forwarded message:

> From: Ben Niven-Jenkins <[email-masked]>
> Date: 12 January 2011 14:21:38 GMT
> To: <[email-masked]> <[email-masked]>
> On 12 Jan 2011, at 14:01, <[email-masked]> <[email-masked]> wrote:
> 
>> However, when talking about problems/use cases/requirements this seems a little premature. For example we should at least entertain pull models where the client initially comes into their choice of local CDN.
> 
> I am struggling a little to see how this would work. I am not sure how the client/User Agent can choose a CDN, as such.
> 
> Something (e.g. the CSP's Portal) will provide the User Agent with a URI to the content it requires. The User Agent follows that URI and requests the content. However the User Agent has no control over how that URI is resolves.
> 
> Or are you talking about a case where because of DNS caching a subsequent User Agent ends up connecting to the same surrogate without any further interaction between the User Agent's DNS resolver and the Request Routing system in a CDN?
> 
> Thanks
> Ben
> 
> 
>> In this case the CDNs would need to be able to share control information about content availability. Content may already be available locally either because an authoritative CDN has pushed it their or because the local CDN has pulled it. The local CDN could hand over to a CDN with the content or might stream it through the local CDN and cache for the next user.
>>

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 12 Jan 2011 17:33:45 +0100

> I'd be interested in the views of others, but my personal view is we try to steer clear of unproven content models and focus on solving the problem of a lack of CDN interconnect standards that can…

I share that view.

Francois

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

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

 Think before you print.

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 09:22:42 +0000

Let me try an example then –

One generic business model is where the authoritative CDN controls both the content dissemination and the request routing. It pushes the content to other CDNs where it wants (subject to them accepting, and then follows this by referring them some of the client requests. Exactly the model we want for offload I’d suggest, and probably also extending geographic and network/device (e.g. mobile) reach.

However, this has several implications. The authoritative CDN is in control. It chooses who can hold and serve the content for which it is the authoritative source. On one hand we might say this is fine – after all it is the one who won the content business. On the other hand it doesn’t match with a standard wholesale model where supply is (not selectively) offered to downstream parties.

Hence I think it’s worth thinking about use cases where the motivation is really about extending content (rather than extending reach). For example, I have an IPTV service and want to include some of your authoritative CDN content on my local CDN to serve my IPTV customers. We can talk about allowing the local CDN to pull content. However, if the request routing is still pushed down from the authoritative CDN I still won’t be able to serve content locally unless the authoritative CDN agrees – even for my own clients.

We can see two technical ways of allowing request routing pull (from the client)

-          Simply implement request routing push (from the authoritative CDN) in the CDN federation. Allow the pull of the content itself. The fact that any CDN federation request routing starts at the authoritative CDN doesn’t stop the client requesting content from its preferred CDN first. Thus the ‘pull’ becomes out of scope in federation discussions. The downside of this approach is that the local CDN cannot choose who to offload requests to – only the authoritative CDN can do that.

-          Allow a ‘pull’ request routing as part of the CDN federation. Things get much more complicated because we need knowledge of content availability to be able to route requests between CDNs.

Trevor.

Trevor Burbridge

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
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: 12 January 2011 16:34
To: Ben Niven-Jenkins
Cc: Francois Le Faucheur; Burbridge,T,Trevor,DES8 R; [email-masked]
Subject: Re: [CDNi] Problem Statement: Terminology

I share that view.

Francois

Ben

Thanks
Ben

_______________________________________________
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: Francois Le Faucheur <[email-masked]>
Date: Thu, 13 Jan 2011 11:00:26 +0100

Hello Trevor,

> One generic business model is where the authoritative CDN controls both the content dissemination and the request routing. It pushes the content to other CDNs where it wants (subject to them accept…

Right. And effectively what we've been focusing on.

>  
> However, this has several implications. The authoritative CDN is in control. It chooses who can hold and serve the content for which it is the authoritative source. On one hand we might say this is fine – after all it is the one who won the content business.

Right. 
And of course the CSP can optionally spreads his content-eggs over multiple CDN-baskets (eg CSP load-balances his content requests over multiple "prime CDNs") so there are multiple CDNs sharing the top-of-CDN-tree control/responsibilities.

> On the other hand it doesn’t match with a standard wholesale model where supply is (not selectively) offered to downstream parties.
>  
> Hence I think it’s worth thinking about use cases where the motivation is really about extending content (rather than extending reach). For example, I have an IPTV service and want to include some of your authoritative CDN content on my local CDN to serve my IPTV customers.

I see this as a very interesting, but different, problem. I don't see this much as a "delivery" problem, but more as a "content exchange" problem. 
In your example, as a CDN operator, I don't own that content, I have no idea if it is OK for you to resell that content or not, I don't know how to help you make this content visible to your customers through your EPG. Those seem to be the important questions here. Once all this is figured out and the Content Owner has authorized you to get and resell the content, then you can certainly "acquire" the piece of content from my CDN.

I believe the problem you describe is very close to what the ATIS IIF (IPTV Interoperability Forum) is starting to tackle through their "Internet Source Content" work item (which builds on the "Content on Demand (CoD)" solution they just completed). Have you investigated whether this can help you address the scenario you have in mind ?

Cheers

Francois

> We can talk about allowing the local CDN to pull content. However, if the request routing is still pushed down from the authoritative CDN I still won’t be able to serve content locally unless the authoritative CDN agrees – even for my own clients.
>  

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

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

 Think before you print.

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 13:04:21 +0100

Hi Francois,

In fact I think that "Request Routing System" makes use of 2 interfaces:

  - the handling of the interaction with the user agent;
  - the selection of the entity which will serve the content...;

Currently the second interface is part of the control API. So I propose that we create a distinct interface and separate it from the control API.

What about the following names?
  - Request-Transfer: Handling of the interaction with the user agent...;
  - Request-Routing: Part of the control API which selects of the entity which will serve the content...;	 

Regards
Emile

> De : Francois Le Faucheur [mailto:[email-masked]]
> Envoyé : mercredi 12 janvier 2011 14:34
> À : Ben Niven-Jenkins
> Cc : Francois Le Faucheur; Bitar, Nabil N; STEPHAN Emile RD-CORE-LAN;
> [email-masked]
> Objet : Re: [CDNi] Problem Statement: Terminology
> 
> Ben, Emile and all,
> 
> But I suspect that what Emile was getting at (beyond terminology), is the
> following point that is relevant for CDNi:
> 
> Downstream CDN may indicate that it has on-net cache coverage of such IP-
> address range footprint, e.g. Downstream CDN may indicate that it is
> 	(B) actual redirection of a given request (ie once Upstream CDN has
> selected a given Downstream CDN, it communicates with that Downstream CDN
> to facilitate the actual redirection of a given user request.)
> 
> Request-Transfer API" (or "CDNi Request-Redirection API"), since it is to
> be used for the (B) interactions. I don't feel strongly about this as long
> as we are clear it is to be used for (B) interactions.
> 
> two terms is the best way to achieve that as we would introduce a new term
> that we don't subsequently use and for CDNI, only inter-CDN Request
> Routing (i.e. between Request Routing Systems in different CDNs) should be
> in scope and the internals of the Request Routing System in each CDN
> should remain out of scope.
> >
> suggestions into the definition of Request Routing System but keep it as a
> single term encompassing the entire Request Routing System.
> >
> > My proposal would be:
> >
> "obtaining a set of candidate surrogates" may incorrectly suggest that an
> Upstream CDN needs to know about surrogates in the Downstream CDN.
> How about:
> "
> >> I think it is fine to refine the definition of the functions. I would
> like to suggest  tough some modification to the proposed definitions and
> see what you and Ben think:
> >>
> >> Request transfer: The function within a CDN responsible for receiving a
> content request from a user-agent, querying the request routing function
> for candidate surrogates, and for selecting and redirecting the user to
> the appropriate surrogate or CDN.
> >>
> CDN responsible for determining the candidate list of surrogates for the
> request-transfer function to deliver content to a user-agent.
> >>
> >> Thanks,
> >> Nabil
> >>
> >>
> >> I went through the terminology section. I think that it make sense to
> split the Request Routing in 2 functions. The first function (Request
> Transfer) handles the content request; the second (Request Routing)
> determines the appropriate source of content.
> >>
> >>   Request Transfer:
> >>   The function within a CDN responsible for receiving a content request
> from a User-agent, for querying the Request routing function and for
> directing this query toward the selected source of content.
> >>
> >>    Request Routing:
> Content
> across
> made

---

From: Songhaibin <[email-masked]>
Date: Wed, 26 Jan 2011 04:02:29 +0000

What does the user agent concept include? Does it include the proxies and DNS servers? Because from the CDN's viewpoint, the request may come from them.

BR,
Haibin

> [email-masked]
> Sent: Monday, January 24, 2011 8:04 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [CDNi] Problem Statement: Request routing system
> 
> Hi Francois,
> 
> Currently the second interface is part of the control API. So I propose that we
> create a distinct interface and separate it from the control API.
>

---

From: <[email-masked]>
Date: Wed, 26 Jan 2011 09:26:42 +0000

> Songhaibin
> Sent: 26 January 2011 04:02
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> What does the user agent concept include? Does it include the proxies
> and DNS servers? Because from the CDN's viewpoint, the request may come
> from them.

I think at the moment we've define the UA to exclude these independent host and network functions, although we do acknowledge they take part in the interaction (and are indistinguishable to the CDN). I think this is probably the right approach since such additional entities exist beyond the scope of CDNi.

> >   - Request-Routing: Part of the control API which selects of the
> entity which
> > will serve the content...;
> >
> > Regards
> > Emile
> >
> > > Like Ben I don't the need to break down the Request-Routing System
> into
> > > two entity.
> > >
> > > Request-Routing Systems in two neighbor CDNs may need to interact
> for two
> > > different purposes:
> has
> > > selected a given Downstream CDN, it communicates with that
> Downstream
> > CDN
> would
> receiving a
> request
> > > de
> (which
> > > is
> > > >>> (and therefore relevant to a CDN involved in the delivery of
> that
> > > content).
> Interconnection
> > > >>> environment, some of the Content Distribution Metadata may have
> an
> > > intra-
> > > >>> CDN scope (and therefore need not be communicated between
> CDNs),
> > while
> > > >>> some of the Content Distribution Metadata have an inter-CDN
> scope
> > (and
> > > >>> available or blocked) and access control mechanisms to be
> enforced
> > > (e.g.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 26 Jan 2011 17:27:47 +0000

Emilie,

> Currently the second interface is part of the control API. So I propose that we create a distinct interface and separate it from the control API.

I don't think that is quite right (but the problem statement may not be clear). In my opinion the second part (selection of the entity to serve the content) is something that is internal to each CDN and not exposed via CDNI at all. The Request Routing API can be used to ask questions of other CDNs (e.g. Can/Will you deliver this content for me?), the control API enables communication of high level details that could also be configured (e.g. "I do not support Delivery protocol X so there is no point calling my Request Routing API for User Agent requests for Delivery Protocol X ")

Ben

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 26 Jan 2011 19:30:20 +0100

Emile, Ben,

> I don't think that is quite right (but the problem statement may not be clear). In my opinion the second part (selection of the entity to serve the content) is something that is internal to each CD…

I agree this is how the problem statement currently describes things:
	* Downstream CDN can use the CDNI Control API to notify Upstream CDN about coarse/static info
	* Upstream CDN can use CDNI Request-Routing API to query Downstream CDN about how dCDN wants to handle requests.

What is a little tricky is that the boundary between the two can get very blurry. 

For example, the Downstream CDN may start advertising slightly finer grain and/or slightly more dynamic info that will help Upstream CDN make routing decision (eg "footprints" that it is willing to serve, or that its cascaded downstream CDNs may be willing to serve) - think tweaked dynamic routing protocol perhaps. Should this be considered as part of the Control API, the Request-Routing API, another API? 
As another example, the Upstream CDN may query the Downstream CDN about not just how to deal with a single query, but a set of queries (eg all queries to a Prefix) - think some extended version of ALTO perhaps. Should this be considered as part of the Control API, the Request-Routing API, another API? 
It is worth noting that, at the end of the day, these two example are virtually the same (ie some info is exchanged allowing uCDN to make its routing decisions) even if one seems more like a stretch of the function currently under Control API and the other one seems more like a stretch of the function currently under the Request-Routing API.

I would be tempted to go for something like this:
	* keep under the Control API only the stuff that is real coarse & static:
		o e.g. "I do not support Delivery protocol X so there is no point calling my Request Routing API for User Agent requests for Delivery Protocol X "
	* move anything else under the Request-Routing API:
		o e.g. uCDN-->dCDN: Can/Will you deliver this content for me?
		o e.g. uCDN-->dCDN: Can/Will you deliver this content to this sort of destinations for me? 
		o e.g. uCDN-->dCDN: where would you like me to redirect this sort of content to this sort of destinations?
		o e.g. dCDN-->uCDN: Here are the Prefixes that I am willing/able to do delivery for

I don't want to suggest that a CDNI solution needs all of the variations above. But I expect a CDNI solution (in the short term or in the long term) will need some form of exchange of dynamic info helping the uCDN make its dCDN selection decisions and redirections. I think this is what Emile has in mind too. And it'd be useful to agree where we place it in the model, whatever it looks like. I'm suggesting this should go under the CDNI Request-Routing API. 

Makes sense?

Thanks

Francois

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

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

 Think before you print.

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 09:51:55 +0100

Hi Francois,
 
It makes sense for me. Otherwise routing information will be collected in background through the control API and on the fly through the routing API.
 
I attempted to represent that on the drawing below. 

                                CDN1                                    CDN2
                                 |                                       |
                                 |   Background routing information      |
                                 |<--------------------------------------|
                                 |                                       |
                       Storage of the routing info                       |
                                 |                                       |
         request arrival         |                                       |
       ------------------------->|                                       |
                                 |                                       |
                     Query of Local routing info                         |
                                 |                                       |

Case 1: routing of the request solved     
          
                                 |                                       |
           response              |                                       |
       <------------------------ |                                       |
                                 |                                       |

Case 2: routing of the request require more investigation  
 
                                 |                                       |
                                 |   on the fly routing info query       |
                                 | ----------------------------------->  |
                                 |              response                 |
                                 | <----------------------------------   |
                                 |                                       |
                     Preparation of the response                         |
            response             |                                       |
       <-----------------------  |                                       |
                                 |                                       |
                                 |                                       |

Regards
Emile

De : Francois Le Faucheur [mailto:[email-masked]] 
Envoyé : mercredi 26 janvier 2011 19:30
À : Niven-Jenkins Ben; STEPHAN Emile RD-CORE-LAN
Cc : Le Faucheur Francois; [email-masked]
Objet : Re: [CDNi] Problem Statement: Request routing system
 
Emile, Ben,

Emilie,

Hi Francois,

	 

 

 
 
Makes sense?
 
Thanks
 
Francois

	Ben

		 
		Regards
		Emile
		 
			-----Message d'origine-----
			De : Francois Le Faucheur [mailto:[email-masked]]
			Envoyé : mercredi 12 janvier 2011 14:34
			À : Ben Niven-Jenkins
			Cc : Francois Le Faucheur; Bitar, Nabil N; STEPHAN Emile RD-CORE-LAN;
			[email-masked]
			Objet : Re: [CDNi] Problem Statement: Terminology
			 
			Ben, Emile and all,
			 
			Like Ben I don't the need to break down the Request-Routing System into
			two entity.

			Request-Routing Systems in two neighbor CDNs may need to interact for two
			different purposes:
			 
			I agree it is important to keep in mind this distinction for the
			definition of CDNi interactions.
			I believe the current Problem Statement already reflects that distinction:
			                     - it discusses the (A) interactions as part of the "CDNi
			Control API":
			"
			    *  CDNI Control API: This API allows the "CDNI Control" system in
			       interconnected CDNs to communicate.  This API may support the
			       following:
			         <clip>
			       +  allows the downstream CDN to communicate information about
			          its delivery capabilities, resources and policies
			         <clip>
			"
			                     - it discusses the (B) interactions as part of the "CDNi
			Request-Routing API":
			"
			    *  Request-Routing API: This API allows the Request-Routing system
			       in interconnected CDNs to communicate to ensure that an end-
			       user request can be (re)directed from an upstream CDN to a
			       surrogate in the downstream CDN, in particular where selection
			       responsibilities may be split across CDNs (for example the
			       upstream CDN may be responsible for selecting the downstream
			       CDN while the downstream CDN may be responsible for selecting
			       the actual surrogate within that CDN).
			"

			 

				Emile, Nabil,

				If we look at the definition of Request Routing System in the -00
			Problem statement we have:

				 
				My proposal would be:

			of candidate surrogates or candidate CDNs, and for selecting and
			redirecting the user

			Cheers
			 
			Francois

				 
				Thanks
				Ben

					Hi,

					 
					Thanks,
					Nabil

					Hi Ben,

					Request Transfer:
					 
					 Request Routing:

					-----Message d'origine-----
					De : [email-masked] [mailto:[email-masked]] De la part
			de
					Ben Niven-Jenkins
					Envoyé : lundi 20 décembre 2010 11:59
					À : Francois Le Faucheur
					Cc : [email-masked]; Lee, Yiu
					Objet : Re: [CDNi] Few comments on Problem Statement
					 
					Francois,

					Hi Yiu,

					 
					 
					So, to be more accurate, we could use the term "CDNi Metadata" to
					designate the Content Distribution Metadata of inter-CDN scope (which
			is
					quite of a mouthful).

					"
					 
					(and therefore relevant to a CDN involved in the delivery of that
			Rating
					 
					environment, some of the Content Distribution Metadata may have an
					available or blocked) and access control mechanisms to be enforced

					How does that sound?

					Looks good to me :-)
					 
					Ben

					 
					60 Sylvan Road
					Waltham, MA 02451

 

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: Thu, 27 Jan 2011 10:34:06 +0000

Francois,

> What is a little tricky is that the boundary between the two can get very blurry. 

Two thoughts:
1) Looking at the rate of change of the information may help on a case by case basis. The Control API (IMO) is really a tool to automate some tasks that could be done manually because the information exchanged has a slow rate of change.

2) The Request Routing API is really for Request Routers to communicate with one another but the Control API is applicable to other components in the CDN as well. So if the information being exchanged is only applicable to Request Routers we should place it under the Request Routing API IMO.

> I don't want to suggest that a CDNI solution needs all of the variations above. But I expect a CDNI solution (in the short term or in the long term) will need some form of exchange of dynamic info…

Works for me.

Ben