Subject: [CDNi] Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 5 Nov 2013 16:12:27 +0000

Jan, Kevin,

Did you consider the following?
Can we discuss it in Vancouver?

Tx

On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

Scott, Jan, and all,

On 15 Oct 2013, at 11:30, Scott Leibrand <[email-masked]<mailto:[email-masked]>> wrote:

This feature (partial object caching) is absolutely a requirement before we could think about offloading on-demand video traffic to a dCDN.  If the dCDN downloads the entire file, that completely ruins the uCDN's efforts to do partial caching, and the resulting increase in cache use makes things worse than not using a dCDN at all.

Then perhaps it would make sense to include something like "Partial Object Caching" in the set of capabilities that can be advertised in the CDNI Footprint and Capabilities Advertisement interface (FCI). This would allow the uCDN to select a dCDN that supports partial object caching when required (or possibly elect to serve itself).

Jan,
Would you mind including this as a candidate in your list so we rememebr to make a concious decision about it?

Thanks

Francois

-Scott

On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ben,

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: maandag 14 oktober 2013 5:10
> To: Brandenburg, R. (Ray) van
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: Re: [CDNi] CDNI and byte-range requests
>
> Ray,
>
> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote:
>
> > Hi all,
> >
> > As I'm not sure whether this should be part of the Redirection Interface
> document or the Framework document, let me just post this as a general
> question to the list:
> >
> > To my knowledge, the current CDNI documents do not explicitly address
> the case of HTTP Byte-range requests. Although in most cases byte-range
> requests will function just as any other requests, I think there are some cases
> where byte-range requests warrant further attention. An example is the
> Redirection interface. If a uCDN asks a dCDN to deliver a particular user
> request (containing a byte range), and the dCDN answers positively, can the
> uCDN assume that the dCDN accepts any future requests for the same file
> with a different byte range? And if that is the case, is this default behavior or
> do we need an explicit flag in the inter-CDN redirection request to indicate
> the uCDN/dCDN's preference?
> >
> > To be clear: I don't think we need any new functionality to handle byte-
> range requests, but a few sentences in either the Framework or the RI
> document might clear up any future uncertainty.
>
> I don't see how this is any different to a sequence of non byte-range
> requests.
>
> It will likely depend on the behaviour of the client (and possibly whether the
> server closes the connection after each request if that drives a different
> client behaviour) as to where the client ends up going (uCDN or dCDN) when
> it makes a subsequent request.
>
> Trying to say anything here may take us down the rat hole of trying to
> describe client behaviour which we don't control.
>

Let me give a practical example: Let's say the uCDN is hosting a 2gb TS file. At some point it receives an incoming request for a particular byte range within that file, let's say the first 10mb. For some reason the uCDN decides that it wants to redirect the request to a dCDN. The dCDN receives the request. At that point it has to decide what to do: does it download the full 2gb file from the uCDN, or does it download just the first 10mb? Of course it's fully up to internal logic in the dCDN to decide what it should do here, however it does have an impact on the uCDN as well (potentially unnecessary traffic reducing the effectiveness of the inter-CDN redirect). My question is, do we need to say anything about this case to help both the dCDN and uCDN in making this decision?

Ray

> Ben
>
> >
> > Best regards,
> >
> > Ray
> > This e-mail and its contents are subject to the DISCLAIMER at
> http://www.tno.nl/emaildisclaimer
> >
> > _______________________________________________
> > CDNi mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/cdni

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

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

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 5 Nov 2013 11:15:53 -0500

i did not consider it, but i am happy to discuss it.

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: Tuesday, November 05, 2013 11:12 AM
To: Jan Seedorf; Kevin J Ma
Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray); Francois Le Faucheur (flefauch); Larry Peterson; [email-masked]; Daryl Malas
Subject: Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics

Jan, Kevin,

Tx

Scott, Jan, and all,

Jan,

Thanks

Francois

-Scott

Ray

---

From: Jan Seedorf <[email-masked]>
Date: Tue, 5 Nov 2013 17:42:13 +0000

Same here, we have not considered this, but sure let's discuss it during Thursday's lunch meeting

 - Jan

> From: Kevin J Ma [mailto:[email-masked]]
> Sent: Tuesday, November 05, 2013 5:16 PM
> To: Francois Le Faucheur (flefauch); Jan Seedorf
> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray);
> Larry Peterson; [email-masked]; Daryl Malas
> Subject: RE: Discussing a "Partial Caching" Capability (for byte-range
> requests) in FCI semantics
> 
> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray);
> Francois Le Faucheur (flefauch); Larry Peterson; [email-masked]; Daryl Malas
> On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch)
> <[email-masked]> wrote:
> 
> 
> 
> 
> 
> Scott, Jan, and all,
> 
> 
> 
> On 15 Oct 2013, at 11:30, Scott Leibrand <[email-masked]> wrote:
> 
> 
> 
> 
> 
> This feature (partial object caching) is absolutely a requirement before we
> could think about offloading on-demand video traffic to a dCDN.  If the dCDN
> downloads the entire file, that completely ruins the uCDN's efforts to do
> partial caching, and the resulting increase in cache use makes things worse
> than not using a dCDN at all.
> 
> 
> 
> Then perhaps it would make sense to include something like "Partial Object
> Caching" in the set of capabilities that can be advertised in the CDNI Footprint
> and Capabilities Advertisement interface (FCI). This would allow the uCDN to
> select a dCDN that supports partial object caching when required (or possibly
> elect to serve itself).
> 
> 
> 
> Jan,
> 
> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van
> <[email-masked]> wrote:
> 
> Hi Ben,
> 
> 
> > From: Ben Niven-Jenkins [mailto:[email-masked]]
> > Cc: [email-masked]
> Let me give a practical example: Let's say the uCDN is hosting a 2gb TS file. At
> some point it receives an incoming request for a particular byte range within
> that file, let's say the first 10mb. For some reason the uCDN decides that it
> wants to redirect the request to a dCDN. The dCDN receives the request. At
> that point it has to decide what to do: does it download the full 2gb file from
> the uCDN, or does it download just the first 10mb? Of course it's fully up to
> internal logic in the dCDN to decide what it should do here, however it does
> have an impact on the uCDN as well (potentially unnecessary traffic reducing
> the effectiveness of the inter-CDN redirect). My question is, do we need to
> say anything about this case to help both the dCDN and uCDN in making this
> decision?
> 
> Ray
> 
> 
> > Ben
> >
> > >
> > > Best regards,
> > >
> > > Ray
> > > [email-masked]
> [email-masked]
> [email-masked]

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 5 Nov 2013 23:54:26 -0500

I have a couple clarifying questions about the partial caching:

1. Is there text somewhere that states that dCDNs MUST only cache what
   the client requested?

   Just because the dCDN is capable of partial caching, doesnt mean that
   it won't go ahead and ask for the whole file?

2. If we assume the dCDN only does partial acquisition requests, when
   it receives a partial delivery request, then my question is, are
   we concerned that dCDN is incapable of doing range requests?  If
   so, should that not show up in the acquisition protocol capability?

   It's unclear to me what information the partial caching capability
   is actually conveying?

3. If what we really want is a way for the uCDN to tell the dCDN whether
   or not to use partial caching for a given piece of content, then I
   would think what we need is a new metadata object, not a new capability?

thanx.

--  Kevin J. Ma

> From: Jan Seedorf [mailto:[email-masked]]
> Sent: Tuesday, November 05, 2013 12:42 PM
> To: Kevin J Ma; Francois Le Faucheur (flefauch)
> > Subject: Discussing a "Partial Caching" Capability (for byte-range
> requests) in
> > FCI semantics
> >
> >
> >
> > Jan, Kevin,
> >
> >
> >
> > Would you mind including this as a candidate in your list so we rememebr
> to
> > make a concious decision about it?
> >
> >
> >
> > Thanks
> >
> >
> >
> > Francois
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -Scott
> >
> >
> >
> > > requests will function just as any other requests, I think there are
> some
> > cases
> > > request (containing a byte range), and the dCDN answers positively,
> can
> > the
> > > with a different byte range? And if that is the case, is this default
> behavior
> > or
> > > It will likely depend on the behaviour of the client (and possibly
> whether
> > the

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 5 Nov 2013 22:59:49 -0800

> On Nov 5, 2013, at 8:54 PM, Kevin J Ma <[email-masked]> wrote:
> 

A uCDN (with a CSP customer with a very large video library) who is doing partial caching themselves needs their dCDNs to do something similar, and only request content that users actually request (modulo some read ahead or whatever). Otherwise, the dCDN's requests blow up the active library on the uCDN's caches, causing them to have to double storage capacity to cache portions of the content no one is watching. 

If a dCDN doesn't support the capability to only ask for what they need, the uCDN may be better off serving the content themselves. 

>   It's unclear to me what information the partial caching capability

I'm not following. Range requests are how partial objects are transferred. If the dCDN doesn't support range requests, we have bigger problems. 

>   would think what we need is a new metadata object, not a new capability?

I'm not familiar enough with the spec to know what we need there. But the central requirement is for the uCDN to be able to tell dCDNs to do partial caching for a given CSP's content, and for the uCDN to be able to avoid using any dCDNs that don't support partial caching.

-Scott

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 6 Nov 2013 10:42:52 -0500

Hi Scott,

  My point was that:

  wrt to 2), the dCDN can advertise its acquisition protocol capabilities.
  If it says it supports HTTP, it is assumed that it supports all of HTTP
  including range requests, so I see no reason to add an additional
  "Partial Caching" capability flag which essentially says: "yes I really
  do support range requests".  If theres a dCDN that doesnt support range
  requests, then it should advertise some type of HTTP-lite for its
  acquisition protocol.  That was a well debated use case for acquisition
  protocols, as I recall?

  wrt to 1) and 3), the uCDN telling the dCDN how to acquire content is
  a completely separate issue.  It is really a metadata issue, not a
  capability issue (given that the capability part should already be
  addressed through the acqusition protocol capability).

  If what we are really looking for is a new HTTP-minus-range-gets
  protocol for the registry, and maybe a you-must-propogate-range-gets
  metadata, then that is a different discussion, and I would like to
  clarify that first?

thanx.

--  Kevin J. Ma

> From: Scott Leibrand [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2013 2:00 AM
> To: Kevin J Ma
> Cc: Jan Seedorf; Francois Le Faucheur (flefauch); Brandenburg, R. (Ray)
> van; Larry Peterson; [email-masked]; Daryl Malas
> Subject: Re: Discussing a "Partial Caching" Capability (for byte-range
> A uCDN (with a CSP customer with a very large video library) who is doing
> partial caching themselves needs their dCDNs to do something similar, and
> only request content that users actually request (modulo some read ahead
> or whatever). Otherwise, the dCDN's requests blow up the active library on
> the uCDN's caches, causing them to have to double storage capacity to
> cache portions of the content no one is watching.
> 
> If a dCDN doesn't support the capability to only ask for what they need,
> the uCDN may be better off serving the content themselves.
> 
> >
> I'm not following. Range requests are how partial objects are transferred.
> If the dCDN doesn't support range requests, we have bigger problems.
> 
> >
> I'm not familiar enough with the spec to know what we need there. But the
> central requirement is for the uCDN to be able to tell dCDNs to do partial
> caching for a given CSP's content, and for the uCDN to be able to avoid
> using any dCDNs that don't support partial caching.
> 
> -Scott
> >
> > thanx.
> >
> > --  Kevin J. Ma
> >
> >> Same here, we have not considered this, but sure let's discuss it
> during
> >> Thursday's lunch meeting
> >>
> >> - Jan
> >>
> >>> This feature (partial object caching) is absolutely a requirement
> before
> >> we
> >>> could think about offloading on-demand video traffic to a dCDN.  If
> the
> >> dCDN
> >>> Let me give a practical example: Let's say the uCDN is hosting a 2gb
> TS
> >> file. At
> >>> wants to redirect the request to a dCDN. The dCDN receives the
> request.
> >> At
> >>> the uCDN, or does it download just the first 10mb? Of course it's
> fully
> >> up to
> >>> internal logic in the dCDN to decide what it should do here, however
> it
> >> does
> >>> the effectiveness of the inter-CDN redirect). My question is, do we
> need
> >> to

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 7 Nov 2013 19:50:14 +0000

Hi all,

I think Kevin raises an interesting point. It's not so much a capability that you want to check for, it's something you want to mandate from a dCDN, similar to how a uCDN might mandate other elements of the delivery process. In that sense, the metadata interface is indeed a more appropriate interface. 

(Now that we're discussing this, do we have to worry about people arguing that mandating something that has to do with acquisition goes against the charter which specifies the acquisition interface to be out of scope? :))

Best regards,

Ray

> On 6 nov. 2013, at 16:43, "Kevin J Ma" <[email-masked]> wrote:
> 
> Hi Scott,
> 
>  My point was that:
> 

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Sat, 9 Nov 2013 01:32:58 +0000

Hi Ray and all,

Based on a few conversations here in Vancouver on that topic, I think handling of Partial Caching in CDNI would involve:
	* defining a Capability, so the dCDN can indicate in FCI whether/how it supports "Partial Caching" (e.g. dCDN does not support Partial Caching, dCDN support Partial Caching for all content, dCDN supports Partial Caching on a per content item/set basis)
	* defining an additional CDNI Metadata information Element, allowing the uCDN to tell the dCDN (or a per content item/content sets basis) whether "partial Caching" is needed (or not) from dCDN when client issues a byte range request to this content. Something like:
		o  Partial-Caching: dCDN needs to minimise the amount of data requested on acquisition - eg by only acquiring the same byte range as requested by end-user, 
		o No-Partial-Caching: dCDN is not required to minimise the amount of data requested on acquisition - ie dCDN behaves whichever way it wants.

A possible way to progress this would be to take a similar approach to what is being done for rate-pacing, ie progress a standalone I-D that focuses on this functionality and defines the corresponding use case + overall functionality, and defines the impact and necessary extensions for each of the CDNI interfaces.
Makes sense?

Would you be interested in driving that?
Matt may be willing to work on that.

If other folks are interested in contributing in that effort, let us know.

Cheers

Francois

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 8 Nov 2013 18:54:27 -0800

I'd be happy to help review/edit/whatever. 

Scott

> On Nov 8, 2013, at 5:32 PM, "Francois Le Faucheur (flefauch)" <[email-masked]> wrote:
> 
> Hi Ray and all,
>

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Tue, 12 Nov 2013 16:01:58 +0000

I agree with this approach - a new draft with a registry to define the behavior of the dCDN w.r.t. partial caching.

Ray, I can help with this if you'd like. We can use rate pacing as a template.

Regards,
Matt

-----Original Message-----
From: Francois Le Faucheur (flefauch) 
Sent: Friday, November 08, 2013 8:33 PM
To: Brandenburg, R. (Ray) van
Cc: [email-masked]; Matt Caulfield (mcaulfie)
Subject: Suggestion for progressing on "Partial Caching"/"Byte Range request"

Hi Ray and all,

Cheers

Francois

On 7 Nov 2013, at 20:50, "Brandenburg, R. (Ray) van" <[email-masked]> wrote:

> (Now that we're discussing this, do we have to worry about people 
> arguing that mandating something that has to do with acquisition goes 
> against the charter which specifies the acquisition interface to be 
> out of scope? :))
> 
> Best regards,
> 
> Ray
> 
>> If it says it supports HTTP, it is assumed that it supports all of 
>> HTTP including range requests, so I see no reason to add an 
>> additional "Partial Caching" capability flag which essentially says: 
>> "yes I really do support range requests".  If theres a dCDN that 
>> doesnt support range requests, then it should advertise some type of 
>> HTTP-lite for its acquisition protocol.  That was a well debated use 
>> case for acquisition protocols, as I recall?
>> 
>>> Cc: Jan Seedorf; Francois Le Faucheur (flefauch); Brandenburg, R. 
>>> (Ray) van; Larry Peterson; [email-masked]; Daryl Malas
>>>> 1. Is there text somewhere that states that dCDNs MUST only cache 
>>>> what the client requested?
>>>> 
>>>> Just because the dCDN is capable of partial caching, doesnt mean 
>>>> that it won't go ahead and ask for the whole file?
>>> 
>>> A uCDN (with a CSP customer with a very large video library) who is 
>>> doing partial caching themselves needs their dCDNs to do something 
>>> similar, and only request content that users actually request 
>>> (modulo some read ahead or whatever). Otherwise, the dCDN's requests 
>>> blow up the active library on the uCDN's caches, causing them to 
>>> have to double storage capacity to cache portions of the content no one is watching.
>>> 
>>> If a dCDN doesn't support the capability to only ask for what they 
>>> need, the uCDN may be better off serving the content themselves.
>>> 
>>>> 
>>>> 2. If we assume the dCDN only does partial acquisition requests, 
>>>> when it receives a partial delivery request, then my question is, 
>>>> are we concerned that dCDN is incapable of doing range requests?  
>>>> If so, should that not show up in the acquisition protocol capability?
>>>> 
>>>> 3. If what we really want is a way for the uCDN to tell the dCDN 
>>>> whether or not to use partial caching for a given piece of content, 
>>>> then I would think what we need is a new metadata object, not a new
>>> capability?
>>> 
>>> I'm not familiar enough with the spec to know what we need there. 
>>> But the central requirement is for the uCDN to be able to tell dCDNs 
>>> to do partial caching for a given CSP's content, and for the uCDN to 
>>> be able to avoid using any dCDNs that don't support partial caching.
>>> 
>>> -Scott
>>>> 
>>>> thanx.
>>>> 
>>>> --  Kevin J. Ma
>>>> 
>>>>>> Francois Le Faucheur (flefauch); Larry Peterson; [email-masked]; 
>>>>>> Daryl
>>>>> Malas
>>>>>> downloads the entire file, that completely ruins the uCDN's 
>>>>>> efforts to
>>>>> do
>>>>>> partial caching, and the resulting increase in cache use makes 
>>>>>> things
>>>>> worse
>>>>>> Then perhaps it would make sense to include something like 
>>>>>> "Partial
>>>>> Object
>>>>>> Caching" in the set of capabilities that can be advertised in the 
>>>>>> CDNI
>>>>> Footprint
>>>>>> and Capabilities Advertisement interface (FCI). This would allow 
>>>>>> the
>>>>> uCDN to
>>>>>> select a dCDN that supports partial object caching when required 
>>>>>> (or
>>>>> possibly
>>>>>> elect to serve itself).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Jan,
>>>>>> 
>>>>>>> the case of HTTP Byte-range requests. Although in most cases 
>>>>>>> byte-
>>>>> range
>>>>>>> where byte-range requests warrant further attention. An example 
>>>>>>> is
>>> the
>>>>>>> Redirection interface. If a uCDN asks a dCDN to deliver a 
>>>>>>> particular
>>>>> user
>>>>>>> uCDN assume that the dCDN accepts any future requests for the 
>>>>>>> same
>>>>> file
>>>>>>> do we need an explicit flag in the inter-CDN redirection request 
>>>>>>> to
>>>>> indicate
>>>>>>>> To be clear: I don't think we need any new functionality to 
>>>>>>>> handle
>>>>> byte-
>>>>>>> range requests, but a few sentences in either the Framework or 
>>>>>>> the RI document might clear up any future uncertainty.
>>>>>>> 
>>>>>>> I don't see how this is any different to a sequence of non 
>>>>>>> byte-range requests.
>>>>>>> 
>>>>>>> client behaviour) as to where the client ends up going (uCDN or 
>>>>>>> dCDN)
>>>>>> when
>>>>>>> Trying to say anything here may take us down the rat hole of 
>>>>>>> trying
>>> to
>>>>>> some point it receives an incoming request for a particular byte 
>>>>>> range
>>>>> within
>>>>>> that file, let's say the first 10mb. For some reason the uCDN 
>>>>>> decides
>>>>> that it
>>>>>> that point it has to decide what to do: does it download the full 
>>>>>> 2gb
>>>>> file from
>>>>>> have an impact on the uCDN as well (potentially unnecessary 
>>>>>> traffic
>>>>> reducing
>>>>>> say anything about this case to help both the dCDN and uCDN in 
>>>>>> making
>>>>> this
>>>>>> decision?
>>>>>> 
>>>>>> Ray
>>>>>> 
>>>>>> 
>>>>>>> Ben
>>>>>>> 
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> 
>>>>>>>> Ray

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 13 Nov 2013 14:45:26 +0000

Hi Matt, Francois,

I agree that a separate document might be the best option at this point. I can't promise anything time-wise however. I might have some time before the next meeting in March, but it will probably be early next year. 

Matt, if you could help out, that would be great.

Cheers,

Ray

> From: Matt Caulfield (mcaulfie) [mailto:[email-masked]]
> Sent: dinsdag 12 november 2013 17:02
> To: Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) van
> Cc: [email-masked]
> Subject: RE: Suggestion for progressing on "Partial Caching"/"Byte Range
> request"
> 
> Based on a few conversations here in Vancouver on that topic, I think
> handling of Partial Caching in CDNI would involve:
> 	* defining a Capability, so the dCDN can indicate in FCI whether/how
> it supports "Partial Caching" (e.g. dCDN does not support Partial Caching,
> dCDN support Partial Caching for all content, dCDN supports Partial Caching
> on a per content item/set basis)
> 	* defining an additional CDNI Metadata information Element,
> allowing the uCDN to tell the dCDN (or a per content item/content sets basis)
> whether "partial Caching" is needed (or not) from dCDN when client issues a
> byte range request to this content. Something like:
> 		o  Partial-Caching: dCDN needs to minimise the amount of
> data requested on acquisition - eg by only acquiring the same byte range as
> requested by end-user,
> 		o No-Partial-Caching: dCDN is not required to minimise the
> amount of data requested on acquisition - ie dCDN behaves whichever way it
> wants.
> 
> A possible way to progress this would be to take a similar approach to what is
> being done for rate-pacing, ie progress a standalone I-D that focuses on this
> functionality and defines the corresponding use case + overall functionality,
> and defines the impact and necessary extensions for each of the CDNI
> interfaces.
> Makes sense?
> 
> > I think Kevin raises an interesting point. It's not so much a capability that
> you want to check for, it's something you want to mandate from a dCDN,
> similar to how a uCDN might mandate other elements of the delivery
> process. In that sense, the metadata interface is indeed a more appropriate
> interface.
> >
> >>>>> On Nov 5, 2013, at 8:54 PM, Kevin J Ma
> <[email-masked]>
> >>>> wrote:
> >>>>
> > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet
> de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden,
> wordt u verzocht dat aan de afzender te melden en het bericht te
> verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van
> deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke
> aard ook, die verband houdt met risico's verbonden aan het elektronisch
> verzenden van berichten.
> >
> >
> >
> > This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use it and
> for damage of any kind resulting from the risks inherent to the electronic
> transmission of messages.
> >