Subject: [CDNi] Comments on CDNI Requirements

From: <[email-masked]>
Date: Thu, 3 Feb 2011 14:58:10 +0000

Here are some comments on the requirements doc. http://tools.ietf.org/html/draft-lefaucheur-cdni-requirements-00

It looks good. Although it is quite detailed at this stage - for example the draft Charter will be much less detailed (presumably) - it is a good idea to start more detailed thinking already.

It isn't exactly clear what MUST, SHOULD and MAY mean in a requirements doc. We assume something like:
MUST - the protocol will have to do this
SHOULD - the WG will very likely do this. Further discussion is needed, either about whether it definitely is needed &/or about whether it's too tricky for the protocol to achieve during the phase covered by the initial charter.
MAY - it is optional whether the WG does this. Further discussion is needed. But given that there are already a lot of MUSTs & SHOULDs proposed within the initial scope, the default assumption is probably that the WG won't do this, unless it happens to be naturally included within something else.

R2
MUST not => MUST NOT

   R4  The CDNI solution MUST support delivery to the user agent based

       on HTTP [ RFC 3040<http://tools.ietf.org/html/rfc3040> [RFC2616<http://tools.ietf.org/html/rfc2616>]].

   R5  The CDNI solution MUST support acquisition across CDNs based on

       HTTP [ RFC 3040<http://tools.ietf.org/html/rfc3040> [RFC2616<http://tools.ietf.org/html/rfc2616>]].

   R6  The CDNI solution MAY support delivery to the user agent based on

       other protocols than HTTP.

   R7  The CDNI solution MAY support acquisition across CDNs based on

       other protocols than HTTP.

R4 - R7 all seem out of scope, since they're about content acquisition

   R8  The CDNI solution SHOULD support cascaded CDN redirection (CDN1

       redirects to CDN2 that redirects to CDN3) to an arbitrary number

       of levels.

   R9  The CDNI solution SHOULD support an arbitrary topology of

       interconnected CDNs (i.e. the CDN topology cannot be restricted

       to a tree, a loop-free topology, etc.).

R8 would fit better in the Request Routing section.

Should cascading be in initial scope?
(separate discussion on ML)

Suggest merge R9 into R8 & clarify. An arbitrary topology of CDNs seems to be a MUST requirement - so you can have an arbitrary topology in the case where route requests are not cascaded. The question is whether route requests can be cascaded down that topology

   R12  The CDNI Control API MUST allow the Downstream CDN to

        communicate to the Upstream CDN coarse information about the

        Downstream CDN ability and/or willingness to handle requests

        from the Upstream CDN.
It might be good to give an example or two. Guess this would be very coarse info, such as "Downstream CDN is too busy to handle requests at the moment"

   R13  The CDNI Control API SHOULD allow the Downstream CDN to

        communicate to the Upstream CDN aggregate information on the

        Downstream CDN capabilities, resources and affinities (i.e.

        Preferences or cost).  This information can be taken into

        account by the Upstream CDN Request Routing system in its CDN

        Selection decisions.  This information could, for example,

        include:
don't think this is just about the Request Routing system. The information is also useful for the Content Distribution system, eg the Upstream CDN knowing about what content types are supported by the downstream CDN helps it decide what content it will pre-position in this CDN. So add a mention of this in the requirement. Also, it seems more logical to keep the requirement here (within CDNI Control API) than move it to the Request Routing API.

R15 & R22
His => its

   R16  The CDNI Control API MUST allow the Upstream CDN to request the

        Downstream CDN (and potential cascaded Downstream CDNs - if

        cascaded CDNs are supported by the solution) to interrupt

        delivery of an object (or object set) and trigger specific cache

        actions or behaviors in the Downstream CDN surrogates (e.g.

        Object removal from cache, revalidation).  [Editor's note: this

        functionality is currently described in

        draft-jenkins-cdni-problem-statement-01<http://tools.ietf.org/html/draft-jenkins-cdni-problem-statement-01> under the Metadata API

        but probably fits better under the Control API].
BT (Grant) currently investigating whether it is sufficient to remove ability to access the content, or whether some CSP want the actual bits to be removed.

R20, 21, 22
Rather than repeating the entire text from R13-R15, think it would be better to say something like:
R13 upgrades from a SHOULD to a MUST
This would help the reader understand the deltas.

R23

virtual Downstream CDN => virtual Downstream CDNs

note, we have an open issue on the Use Cases draft to add some discussion about virtualisation and about different sorts of Wholesaler model. discuss separately.

   R28  The CDNI Request-Routing architecture and API MUST support

        efficient request-routing for small objects.  This may, for

        example, call for a mode of operation (e.g.  DNS-based request

        routing) where freshness and accuracy of CDN/Surrogate selection

        can be traded-off against reduced request-routing load (e.g.

        Via lighter-weight queries and caching of request-routing

        decisions).

   R29  The CDNI Request-Routing architecture and API MUST support

        efficient request-routing for large objects.  This may, for

        example, call for a mode of operation (e.g.  HTTP-based request

        routing) where freshness and accuracy of CDN/Surrogate selection

        justifies a per-request decision and a per-request CDNI Request-

        Routing API call.

We don't really understand why these requirements have been split like this - suggest rearrange as:

R28 - MUST support http-based and DNS-based request routing

R29 - MUST support both small & large objects and caching vs not-cached

Not sure if R29 needs to be said explicitly?

R28 may be worth discussing, as this might appear directly in the proposed charter. Do people believe

-    The proposed WG needs to support both http-based and DNS-based request routing

-    The proposed WG does NOT do any others
We think both these points are ok.

R30 & R31

... The CDNI Request-Routing

        architecture MUST support recursive request routing.

... The CDNI

        Request-Routing architecture MUST support iterative request

        routing.

There is a lot of "definition" text (defining Recursive & Iterative) that could be removed with a good definition in another draft. There is a "starter for 10" proposed definition in the Use cases draft. http://tools.ietf.org/html/draft-bertrand-cdni-use-cases . then we could have

Rx: The CDNI Request-Routing architecture MUST support recursive request routing and iterative request routing.

The key difference seems to be that in the Iterative case the request routing reply comes back to the UA, which then sends out another request to another CDN which replies to the UA with the surrogate's address. Whereas in the Recursive case the UA sends the request to CDN-A, & CDN-A replies with the surrogate's address (in the meantime CDN-A sends a request to CDN-B which replies to CDN-A with the surrogate's address). Note that the text in R30 seems to describe the iterative case, & R31 the recursive one.

   R32  The CDNI Request-Routing API SHOULD support request loop

        detection and prevention (e.g.  Prevent request looping in a

        situation where CDN1 redirects to CDN2 that redirects to CDN3

        that would redirect to CDN1).

Perhaps this could refer to R8 (if WG or protocol does R8, then it MUST do R32; if it doesn't, then R32 is irrelevant)

   R33  The CDNI Request-Routing loop prevention mechanism SHOULD allow

        routing of the request (as opposed to the request loop being

        simply interrupted without routing the request).

Francois comment:

<< The objective of the requirement is to say that we want more than that: we want to make sure that the loop is detected and the loop is effectively prevented so that the user will get the content somehow.>>

Agree. Also, there are some other choices - instead of the user getting the content, it may be a failure msg

Francois comment:

<< Yes. I think R37 is more specific than R38, so I propose we remove R38.>>

Agree. It may be worth adding to R37, as examples of the error code, the examples in R38, "by which a Downstream CDN can notify the Upstream CDN when it is unable or unwilling to serve a request"

R42 to R46

Agree that these need some work.

The approach suggested (during the Ben /Francois discussion) of a Trigger seems good (for the pre-positioning or "push" case)

Not sure about the right mix of SHOULD & MUST

R46 - only applies to the dynamic acquisition model.

It would be worth having a definition of dynamic acquisition & pre-positioning (and adding to problem statement). There is some ambiguity whether the terms apply only to content acquisition, or also to metadata. As you could push the CDNI Metadata and then pull the content later.

So looking at Francois/Ben's revised proposal:

<<Rx: The CDNI Control API SHOULD support triggering and control for a pre-positioning model whereby the Upstream CDN requests the Downstream CDN to acquire content and/or associated distribution metadata (and possibly position those into Downstream CDN surrogates) at an appropriate time (now or a specified future time), before the content is actually requested by end users. Note that the actual exchange of metadata and the actual content acquisition are outside the scope of the Control API: those are supported, respectively, via the CDNI Metadata API and the Content Acquisition API. [Editor's Note: how much influence the Upstream CDN ought to have on pre-positioning of the content on surrogates inside the Downstream CDN is TBD].

split in two: Rx1 about triggering for content and Rx2 about triggering for CNDI Metadata

<<Rx: The CDNI Metadata API MUST allow the Upstream CDN to provide the Downstream CDN with content distribution metadata of inter-CDN scope.

Ry:   The CDNI Metadata API MUST support exchange of CDNI metadata for both the dynamic acqusition model (whereby the Downstream CDN surrogates acquire content when it is actually requested by end users) and the pre-positioning model (whereby the Upstream CDN requests the Downstream CDN to acquire content and/or associated distribution metadata before the content is actually requested by endusers). [Editor's Note: how much influence the Upstream CDN ought to have on pre-positioning of the content on surrogates inside the Downstream CDN is TBD].

the Metadata API only needs to support dynamic acquisition, ie a request-response; pre-positioning is achieved by the CDN Control API trigger triggering the Metadata API. So suggest both of these are replaced by:

Rx: The CDNI Metadata API MUST support a model where the Downstream CDN requests content distribution metadata and the Upstream CDN replies with the CDNI Metadata. The request may be triggered by the Upstream CDN through the CDNI Control API (See Rx).

This also covers, i guess, R45 ("all the relevant Metadata is initially communicated to the Downstream CDN").

Open for discussion about R44 ("no, or a subset of, the Metadata is initially communicated to the Downstream CDN along with information about how/where to acquire the rest of the CDNI Metadata")

R47

Francois proposed re-writing as:

<< Rx:      Whether in the pre-positioning model or a dynamic acquisition model, the CDNI Metadata API MUST provide the necessary information to allow the Downstream CDN to acquire the content from an upstream source (e.g. Acquisition protocol and Uniform Resource Identifier in Upstream CDN- or rules to construct this URI).

Ry:The CDNI metadata MUST allow signaling of one or more upstream sources, where each upstream source can be in the Upstream CDN, in another CDN, the CSP origin server or any arbitrary source designated by the Upstream CDN. Note that some upstream sources (e.g. the content origin server) may or may not be willing to serve the content to the Downstream CDN, if this policy is known to the upstream CDN then it may omit those sources when exchanging CDNI metadata.

"

(it says "may omit" and mot "MAY omit" because the document defines requirement on the protocol itself, not so much how an implementation must/should/may use the protocol knobs).

Don't think this quite works. Just to check what it's saying:

Rx: mandatory to USE the api to signal address etc of upstream source from which the downstream CDN can get content

Ry: CAPABILITY of api to signal address etc of upstream source(s) from which the downstream CDN may be able to get content

Rx - it seems unrealistic to try to force a guarantee that the source is willing to serve the content to this downstream CDN, as this is about business practices. Delete Rx.

Ry: <<The CDNI metadata MUST allow signalling>> - better to say << The CDNI metadata MUST signal>>. Not sure if this is the best place to mention the stuff in the last sentence, but the point is reasonable.

   R48  The CDNI Metadata API MUST allow the Upstream CDN to add and
        modify CDNI Metadata into the Downstream CDN.
=> The CDNI Metadata API MUST allow the Upstream CDN to request the addition and modification of CDNI Metadata into the Downstream CDN.
Similarly, R49 "Request the removal of"
One CDN asks the other CDN to add/modify/remove CDNI Metadata, but it can't guarantee what the other CDN actually does

   R52  The CDNI Metadata API MUST provide indication by the Downstream
        CDN to the Upstream CDN of whether the CDNI metadata (and
        corresponding future request redirections) is accepted or
        rejected.  When rejected, the CDNI Metadata API MUST allow the
        Downstream CDN to provide information about the cause of the
        rejection.
Is this Requirement realistic? Once a CDN has been told some CDNI Metadata, then it's that CDN's information. In other words, it could just lie about whether it is accepted or rejected. The best you can do is an ACK that the information was received.
An alternative (which we don't think is a good idea) would be to keep all the CDNI Metadata in sync, signed tokens etc.
So:-
   R52  The CDNI Metadata API MUST provide an acknowledgement by the Downstream
        CDN to the Upstream CDN of the CDNI Metadata request, which potentially includes an error code (for example if the request is rejected).

   R53  The Metadata that can be distributed by the CDNI Metadata API
        MUST allow signaling of distribution control policies.  For
        example, this could potentially include:
=> The CDNI Metadata API MUST...
Same comment for R54, R57
Possibly you could add "(of the content)" at the end of the first sentence (ie policies about distribution of the content & not distribution of the CDNI Metadata) - but the examples may make this clear enough.

R56
Delete. The changes to R42, 43 have made it redundant

   R58  The CDNI Metadata API MUST prevent looping of CDNI Metadata
        distribution across CDNs in the presence of cascaded CDNs.
Think cascading is being handled as a generic requirement.

   R59  The CDNI Metadata API SHOULD allow signalling of the Virtual CDN
        identifier to be used in the Downstream CDN for distribution and
        delivery of the corresponding content (or content set).
Francois & Ben proposal is good.

   R60  The CDNI logging architecture and API MUST ensure reliable, non-
        repudiable logging of deliveries performed by a Downstream CDN
       on behalf of an Upstream CDN.
What does "non-repudiable" mean in this context?
[1] the downstream CDN cannot deny that it sent a report (at time x, with info y)
[2] the upstream CDN cannot deny that it received a report (at time x, with info y)
[3] the CDNs cannot deny the correctness of the info y
"non-repudiable" definitely means [1], possibly means [2] (interested to hear views), and doesn't mean [3]. [We think.]

   R61  The CDNI Logging API MUST provide logging of deliveries to User
        Agents performed by the Downstream CDN as a result of request
        redirection by the Upstream CDN.
This might be interpreted as a list of UAs which have had the content - which is too detailed for a MUST. Guess we want a count of how many times content has been delivered to UA(s).

   R62  The CDNI Logging API MUST provide logging of distribution
        performed by the Upstream CDN as a result of acquisition request
        by the Downstream CDN.
'acquisition request' - also applies in the dynamic pre-positioning case.

It might be possible to merge R60-63:
   Rx  The CDNI Logging API MUST provide logging of how many times the Downstream CDN has delivered a piece of content to User Agents as a result of request redirection by the Upstream CDN, or has distributed a piece of content to a Downstream CDN. Delivery of the logging message MUST be reliable and non-repudiable.

Rx - within initial scope:
The CDNI Logging API MUST provide control over what is in the logging records, for example: when logging records are sent (eg every 10 minutes, every time 100 content objects have been sent to UAs), what records are of interest (eg these particular objects or object sets) and where to send the records to (different reports might go to different end points, eg report everything once/day to billing end point, report limited info every 10minutes to monitoring end point).
Perhaps some of this could be beyond initial scope, but seems like there should be some control over what's in the logging records.

   R68  The CDNI Logging API MUST allow a CDN to query another CDN for
        relevant logging records.

Clarify that this is historical query ("please re-send me last week's logging record as i have lost it")

Missing from the logging section is that the logging record needs to include (aggregated) info where content has been delivered to a UA by a CDN further down a cascade of CDNs. This is quite challenging and one reason that it seems hard to support cascaded CDNs in the initial WG scope (especially if one allows any flexibility over what is reported, format of reports, security methods, real-time reports, etc)

   R70  The CDNI solution MUST provide sufficient protection against
        Denial of Service attacks.  In particular, this includes
        protection against spoofed delivery requests sent by user agents
        directly to a Downstream CDN attempting to appear as if they had
        been redirected by a given Upstream CDN when they have not.
"In particular..." seems to imply that it is never valid for a User Agent to request directly to a downstream CDN. But if the downstream CDN is ok to deliver the content then there is no problem. Suggest delete "In particular..."

   R72  The CDNI solution MUST be able to ensure that the Downstream CDN
        cannot spoof a transaction log attempting to appear as if it
        corresponds to a request redirected by a given Upstream CDN when
        that request has not been redirected by this Upstream CDN.
Delete. A simpler mechanism would be for the 2 CDNs to compare logs: the downstream CDN's delivery log vs the upstream CDN's route-request log. If there are deltas, then have the argument. Meeting R72 would imply lots of tokens etc that seems over-the-top.

Best wishes,

Trevor & Phil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 7 Feb 2011 10:56:06 +0000

Philip,

Some comments inline.

On 3 Feb 2011, at 14:58, <[email-masked]> <[email-masked]> wrote:
> It isn’t exactly clear what MUST, SHOULD and MAY mean in a requirements doc. We assume something like:
> MUST – the protocol will have to do this
> SHOULD – the WG will very likely do this. Further discussion is needed, either about whether it definitely is needed &/or about whether it’s too tricky for the protocol to achieve during the phase covered by the initial charter.
> MAY – it is optional whether the WG does this. Further discussion is needed. But given that there are already a lot of MUSTs & SHOULDs proposed within the initial scope, the default assumption is probably that the WG won’t do this, unless it happens to be naturally included within something else.

When I have been involved in documenting requirements in the routing area (e.g. RFC5654) the approach I have taken is that the requirements are for describing the behaviour of the protocol mechanisms and procedures and are not requirements on the WG as such. Work in the WG is driven by the what WG participants are prepared to undertake. Implementations may not implement all requirements. 

Therefore IMO the requirements translate roughly to:
MUST - protocol solution specifications must include support for this as it is a key requirement for the solution to work/be deployable/be acceptable to users of the solution.
SHOULD - A strong recommendation to include in protocol solution specifications that should only be omitted with good justification e.g. solution is only addressing a subset of use cases.
MAY - optional in protocol solutions but some participants felt it was important to have it articulated explicitly rather than assuming readers will infer it implicitly.
 
>        on HTTP [ RFC 3040 [RFC2616]].
>  
>        HTTP [ RFC 3040 [RFC2616]].
>  
> R4 – R7 all seem out of scope, since they’re about content acquisition
>  

IMO specifying how to actually deliver/acquire using HTTP is out of scope, but it is useful to include these as general requirements as there will be HTTP specific metadata that needs to be supported. I read these as meaning "you better support HTTP delivery and define the associated metadata etc. later on we'll likely want other protocols too so don't focus your solution too narrowly but don't get obsessed with how to encode RTMP/RTSP/etc related metadata in the initial solution"

> R8 would fit better in the Request Routing section.

topology is not just related to request routing. E.g. metadata discovery resulting from a surrogate receiving a request from a UA for content it has not delivered before, support for reporting logs/events where the inter-CDN topology may not be a tree etc.

> don’t think this is just about the Request Routing system. The information is also useful for the Content Distribution system, eg the Upstream CDN knowing about what content types are supported by the downstream CDN helps it decide what content it will pre-position in this CDN. So add a mention of this in the requirement. Also, it seems more logical to keep the requirement here (within CDNI Control API) than move it to the Request Routing API.

I know it's not directly related to your comment, but personally I think we shouldn't get too hung up on pre-positioning of content. We do need to support it and therefore ensure we do not build initial solutions that preclude it but pre-positioning is something I'd put in the category of "customers always ask for it in RFPs and then rarely use it" as its applicability is generally limited because once you start supporting multiple content catalogues from multiple CSPs it becomes very difficult to drive optimum efficiency from the CDN with pre-positioning because the arrival rate of requests for specific content and the spread of requests for different content is so dynamic. 

I think we need to be conscious that there is a difference between:
1) A CSP wanting to "pre-position" content into the CDN storage platform because the CSP does not want to operate their own origin server infrastructure
2) A CSP wants the control to "pre-position" content to specific CDN regions or surrogates, etc.

(1) is a definite requirement on CDNs today and doesn't place any additional requirements on a CDNI solution IMO whereas (2) does. My comments above relate to (2).

> We don’t really understand why these requirements have been split like this –

I didn't author these requirements but they reflect the way CDNs are typically deployed and DNS Vs HTTP-based request routing is done today. E.g. small objects (think website acceleration) is typically done via DNS based redirection whereas large object (think large file download) is often done using HTTP redirection.

> suggest rearrange as:
> R28 – MUST support http-based and DNS-based request routing
> R29 – MUST support both small & large objects and caching vs not-cached 

I think we do need to explicitly mention both small & large objects as the requirements they place on the CDN differ. I'd posit that if you were to take a CDN product from a vendor that had only considered large object delivery in its design and tried to use it for website caching of small objects its performance would be pretty dire.

> -    The proposed WG needs to support both http-based and DNS-based request routing

Yes. I could possibly accept a staging of supporting one first and the other later if it's felt the initial amount of work is too much. IMO though the amount of difference between the two solutions at the CDNI solution level is not that great.

> -    The proposed WG does NOT do any others

Never say never but as a starting point I think DNS & HTTP are sufficient to cover all the stated requirements.

> There is a lot of “definition” text (defining Recursive & Iterative) that could be removed with a good definition in another draft. There is a “starter for 10” proposed definition in the Use cases draft. http://tools.ietf.org/html/draft-bertrand-cdni-use-cases . then we could have 

Good point. I think a clear definition of recursive Vs iterative will help us avoid a lot of confusion in the long run as new people try to understand the differences between some of the possible deployment models. I'm fairly easy about which document such a definition goes in.

> The key difference seems to be that in the Iterative case the request routing reply comes back to the UA, which then sends out another request to another CDN which replies to the UA with the surrogate’s address. Whereas in the Recursive case the UA sends the request to CDN-A, & CDN-A replies with the surrogate’s address (in the meantime CDN-A sends a request to CDN-B which replies to CDN-A with the surrogate’s address). Note that the text in R30 seems to describe the iterative case, & R31 the recursive one.

I like this as a clear description of the differences.

> It would be worth having a definition of dynamic acquisition & pre-positioning (and adding to problem statement). There is some ambiguity whether the terms apply only to content acquisition, or als…

I will try and come up with some proposed text this week (based on some of the text that was in your e-mail) which I will share on the list and if we can form a consensus around it we can include it in the next revision of the problem statement.

Regards
Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Feb 2011 08:47:36 +0000

Philip, Colleagues,

A couple of weeks ago, I promised to try to come up with some definitions for dynamic & pre-positioned acquisition of content. I apologise for my belated follow-up.

I propose we add the following definitions to the CDNI Problem Statement draft. I have tried to keep the definitions solution neutral and therefore avoided mention of "pulling" Vs "pushing" content between CDNs.

Comments, improvements, etc are welcomed as always.

Dynamic content acquisition: Dynamic content acquisition is where a CDN only acquires content from the content source in response to an End User requesting that content from the CDN. In the context of CDN Interconnect, dynamic acquisition means that a downstream CDN does not acquire any content from content sources (including upstream CDNs) until a content request for that content has been delegated to the downstream CDN by an Upstream CDN.

Pre-Positioned content acquisition: Pre-positioning is where a CDN acquires content from the content source prior to any End User requesting that content from the CDN. Additionally, in some cases, additional metadata may be provided to instruct the CDN how to treat the content (for example time windows describing when the content may be made available to end users, etc.). In the context of CDN interconnect the Upstream CDN instructs the Downstream CDN to acquire the content along with any associated pre-positioning metadata from content sources (including upstream CDNs) in advance of any End User requesting it.

Thanks
Ben

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 22 Feb 2011 10:53:31 +0100

Ben and all,

> Pre-Positioned content acquisition: Pre-positioning is where a CDN acquires content from the content source prior to any End User requesting that content from the CDN. Additionally, in some cases,…

In line with Phil's initial comment, I'd suggest we try separate handling of content and handling of metadata. How about something like:

"

Pre-Positioned content acquisition: Content Pre-positioning is where a CDN acquires content from the content source prior to any End User requesting that content from the CDN. In the context of CDN interconnect the Upstream CDN instructs the Downstream CDN to acquire the content from content sources (including upstream CDNs) in advance of any End User requesting it.

Dynamic CDNI metadata acquisition: In the context of CDN Interconnect, dynamic CDNI metadata acquisition means that a downstream CDN does not acquire CDNI metadata from the upstream CDN until a content request for that content has been delegated to the downstream CDN by an Upstream CDN.

Pre-positioned CDNI Metadata acquisition: In the context of CDN Interconnect, Metadata Pre-positioning is where the Upstream CDN instructs the Downstream CDN to acquire distribution metadata prior to any End User requesting that content from the Downstream CDN. 
"

Cheers

Francois

PS: If we agree on something like the above, we could also include text discussing possible combinations.

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 22 Feb 2011 14:31:44 +0000

Hi Ben and Francois,

Thanks for working on the definitions. I like them.

Yiu

From: Francois Le Faucheur <[email-masked]<mailto:[email-masked]>>
Date: Tue, 22 Feb 2011 10:53:31 +0100
To: Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] Dynamic Vs Pre-positioned acquisition of content

Ben and all,

Philip, Colleagues,

"

Cheers

Francois

Thanks
Ben

On 7 Feb 2011, at 10:56, Ben Niven-Jenkins wrote:
On 3 Feb 2011, at 14:58, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:
It would be worth having a definition of dynamic acquisition & pre-positioning (and adding to problem statement). There is some ambiguity whether the terms apply only to content acquisition, or also to metadata. As you could push the CDNI Metadata and then pull the content later.

_______________________________________________
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: Guy Meador <[email-masked]>
Date: Mon, 28 Feb 2011 14:25:23 -0500

Francois, Colleagues,

I've included some proposed edits to the language for your consideration. Please see below.

Kind Regards,
Guy

On Feb 22, 2011, at 4:53 AM, Francois Le Faucheur wrote:

> Dynamic content acquisition: Dynamic content acquisition is where a CDN only acquires a content item from the content source in response to an End User requesting that content item from the CDN. In the context of CDN Interconnect, dynamic acquisition means that a downstream CDN does not acquire any the content item from content sources (including upstream CDNs) until a content request for that content item has been delegated to the downstream CDN by an Upstream CDN.
> 
> Pre-Positioned content acquisition: Content Pre-positioning is where a CDN acquires a content item from the content source prior to or independent of any End User requesting that content from the CDN. In the context of CDN interconnect the Upstream CDN instructs the Downstream CDN to acquire the content from content sources (including upstream CDNs) in advance of or independent of any End User requesting it.
> 
> Dynamic CDNI metadata acquisition: In the context of CDN Interconnect, dynamic CDNI metadata acquisition means that a downstream CDN does not acquire CDNI metadata for a content item from the upstream CDN until a content request for that content has been delegated to the downstream CDN by an Upstream CDN.
> 
> Pre-positioned CDNI Metadata acquisition: In the context of CDN Interconnect, Metadata Pre-positioning is where the Upstream CDN instructs the Downstream CDN to acquire distribution metadata for a content item prior to or independent of any End User requesting that content from the Downstream CDN. 
> "
> 
> Cheers
> 
> Francois
>