Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 2 Oct 2011 09:33:19 +0100

Hi Kevin,

Thanks for reading the draft, answers inline.

On 30 Sep 2011, at 05:00, Kevin J Ma wrote:

> Hi Ben,
> 
>  I read through the draft and had a couple of questions:
> 
>  - The Site has a list of DeliveryGlobs which identify a set of URIs to
>    which Restrictions apply?

Restrictions in the form of Selection & Delivery ACLs can also be specified in the Site itself. The idea is that the Site lists the default restrictions and then DeliveryGlobs can be used to apply further DeliveryACL restrictions based on a pattern match against the URI.

>  Do all restrictions apply to all globs,
>    or can individual restrictions be associated with individual globs?

The restrictions specified in the Site object apply to all URIs. Restrictions in a particular DeliveryGlob only apply to URIs that match that DeliveryGlob. The first DeliveryGlob in the list that matches the URI is applied (i.e. the ordering of DeliveryGlobs is important).

>  - The SelectionACL seems to suggest Surrogate selection restrictions,
>    but is Surrogate information not intra-CDN information and outside
>    the scope of CDNI?

Ultimately the selection of a specific Surrogate is an intra-CDN function, however there is a need to be able to express surrogate selection policy between CDNs based on CSP policy. For example the ability to express a policy such as "content can be delivered to End Users in country X but must not be delivered from Surrogates in country X".

I expect that SelectionACLs will not normally contain specific lists of individual Surrogate IP addresses and will use Locations that reference class 1b names (as defined in draft-jenkins-cdni-names-00). We have a proposal for describing class 1b names in Locations which we will include in a future version of the draft (we didn't include it in the -00 version because we wanted folks to concentrate on feedback on the base approach, data model & interface specification first).

>  - The origin parameters seem HTTP specific?

The Introduction does state:

   Note: In order to make this document more accessible, it does not
   attempt to articulate all the CDNI Metadata that would be required to
   satisfy all CDNI use cases.  Rather, a smaller set of properties are
   proposed.  These should be sufficient to implement a minimal
   interconnect of basic HTTP delivery.

:-)
 
>  Should they be encapsulated
>    based on an origin protocol?

I'm not sure exactly what you mean by "encapsulated" in this context, do you just mean naming the properties appropriately, e.g. changing origin.basic.active to origin.http.basic.active etc?

>  Would the origin protocol not be related
>    to the DeliveryProtocol in some way?

In general it is not possible to infer the Origin protocol from the Delivery protocol as a CDN may support the use of multiple different origin protocols for a single delivery protocol. Specifically which origin protocols are supported for which delivery protocols is down to the specific capabilities of a particular CDN.

>  Could there also be support for
>    multiple origin protocols and DeliveryProtocols within a Site?

For origin protocols that may be a possibility, although I am not sure how realistic it is. I would expect that the choice of origin protocol is selected when the origin is built/deployed and the service is deployed. I'm not sure that offering multiple origin protocols for a particular Site offers any kind of advantage over a single origin protocol.
 
Having multiple DeliveryProtocols for a single Site will be problematic when DNS based redirection is used because at Surrogate selection time the Request Router does not have information on which DeliveryProtocol the client is intending to use and therefore would not be able to make an appropriate Surrogate selection because it is a common deployment design for each individual Surrogate to only have a subset of the available/supported (by that CDN) DeliveryProtocols enabled.

HTH
Ben

> thanx.
> 
> --  Kevin J. Ma
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Ben Niven-Jenkins
>> Sent: Monday, September 12, 2011 10:08 AM
>> To: [email-masked]
>> Subject: [CDNi] Proposal for a CDNI Metadata model & interface
>> 
>> Colleagues,
>> 
>> We just uploaded a proposal for a CDNI Metadata model and an interface
>> specification for distributing CDNI Metadata (see below).
>> 
>> This initial version does not attempt to articulate all the CDNI Metadata
>> that would be required to satisfy all CDNI use cases. Instead, we have
>> proposed a smaller set of properties that should be sufficient to
>> implement a minimal interconnect of basic HTTP delivery.
>> 
>> This is because, at this stage the important thing in our opinion is to
>> focus any discussion on the overall structure of the interface rather than
>> on the details or omission of particular properties.
>> 
>> Our proposal is available here:
>> http://tools.ietf.org/html/draft-jenkins-cdni-metadata-00
>> 
>> Thanks
>> Ben, David & Grant
>> 
>> _______________________________________________
>> CDNi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cdni

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 3 Oct 2011 14:27:46 -0400

Hi Ben,

  Thanx for the clarifications.  In response to your question:

  > I'm not sure exactly what you mean by "encapsulated" in this context, do
  > you just mean naming the properties appropriately, e.g. changing
  > origin.basic.active to origin.http.basic.active etc?

  This is pretty much what I meant, along with perhaps an origin.http.enabled
  property for the case where there are multiple protocol options and only a
  subset of protocols are supported.

thanx.

--  Kevin J. Ma

> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Sunday, October 02, 2011 4:33 AM
> To: Kevin J Ma
> Cc: [email-masked]
> Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface
> 
> Hi Kevin,
> 
> Restrictions in the form of Selection & Delivery ACLs can also be
> specified in the Site itself. The idea is that the Site lists the default
> restrictions and then DeliveryGlobs can be used to apply further
> DeliveryACL restrictions based on a pattern match against the URI.
> 
> The restrictions specified in the Site object apply to all URIs.
> Restrictions in a particular DeliveryGlob only apply to URIs that match
> that DeliveryGlob. The first DeliveryGlob in the list that matches the URI
> is applied (i.e. the ordering of DeliveryGlobs is important).
> 
> Ultimately the selection of a specific Surrogate is an intra-CDN function,
> however there is a need to be able to express surrogate selection policy
> between CDNs based on CSP policy. For example the ability to express a
> policy such as "content can be delivered to End Users in country X but
> must not be delivered from Surrogates in country X".
> 
> I expect that SelectionACLs will not normally contain specific lists of
> individual Surrogate IP addresses and will use Locations that reference
> class 1b names (as defined in draft-jenkins-cdni-names-00). We have a
> proposal for describing class 1b names in Locations which we will include
> in a future version of the draft (we didn't include it in the -00 version
> because we wanted folks to concentrate on feedback on the base approach,
> data model & interface specification first).
> 
> I'm not sure exactly what you mean by "encapsulated" in this context, do
> you just mean naming the properties appropriately, e.g. changing
> origin.basic.active to origin.http.basic.active etc?
> 
> In general it is not possible to infer the Origin protocol from the
> Delivery protocol as a CDN may support the use of multiple different
> origin protocols for a single delivery protocol. Specifically which origin
> protocols are supported for which delivery protocols is down to the
> specific capabilities of a particular CDN.
> 
> For origin protocols that may be a possibility, although I am not sure how
> realistic it is. I would expect that the choice of origin protocol is
> selected when the origin is built/deployed and the service is deployed.
> I'm not sure that offering multiple origin protocols for a particular Site
> offers any kind of advantage over a single origin protocol.
> 
> Having multiple DeliveryProtocols for a single Site will be problematic
> when DNS based redirection is used because at Surrogate selection time the
> Request Router does not have information on which DeliveryProtocol the
> client is intending to use and therefore would not be able to make an
> appropriate Surrogate selection because it is a common deployment design
> for each individual Surrogate to only have a subset of the
> available/supported (by that CDN) DeliveryProtocols enabled.
> 
> HTH
> Ben
> 
> > thanx.
> >
> > --  Kevin J. Ma
> >