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

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 12 Sep 2011 15:07:48 +0100

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

---

From: Daryl Malas <[email-masked]>
Date: Mon, 12 Sep 2011 17:03:36 -0600

Ben,

I struggle with the statement used in the draft:

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.  Readers are encouraged to focus
   on the overall structure of the protocol rather than on the details
   or omission of particular properties.  Additional properties may be
   added in future drafts or may be better placed in separate documents
   that focus on the CDNI Metadata required to interconnect delivery of
   individual end-user protocols.

I was hoping this type of draft would begin to answer questions that are
raised by statements in the framework draft, such as "Request Router for
Operator A processes the DNS request for CDN-domain cdn.csp.com and
recognizes that the end-user is best served by another CDN."

What in the metadata indicates to Operator A that the end-user is best
served by another CDN, and more importantly which Downstream CDN?

While, this draft is a good start, I'm anxious to get into the meet of
what is exchanged and how it will help the upstream CDN make good
decisions about the varying downstream CDNs could possibly better serve
the end user.

Thanks,

Daryl

On 9/12/11 8:07 AM, "Ben Niven-Jenkins" <[email-masked]> wrote:

>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.
>
>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 13 Sep 2011 01:24:32 +0100

Daryl,

Thanks for reading the draft and commenting, please see inline for some responses.

> served by another CDN, and more importantly which Downstream CDN?

I think you may be confusing the scope of CDNI Metadata with other components in a CDNI solution (or the existing documents do not explain the distinctions/boundaries well enough). CDNI Metadata flows from the upstream CDN to the downstream CDN and the CDNI Metadata interface is the mechanism for communicating the CDNI Metadata. The CDNI Metadata is how the Upstream CDN tells the Downstream CDN how to deliver the content.

In order for an Upstream CDN to be able to select an appropriate Downstream CDN the Upstream CDN needs to be aware of the capabilities of the Downstream CDN which may be advertised in some fashion or configured/communicated out of band (e.g. through some business process such as a contract). Discussion/specification of how to do that advertisement is in scope of CDNI but the actual mechanism an upstream CDN uses to make the final decision is out of scope of the WG and is implementation specific.

While CDN capability advertisement is in scope of CDNI it is not IMO a function of the CDNI Metadata interface as it is not directly related to how a Downstream CDN must deliver content.

> decisions about the varying downstream CDNs could possibly better serve

That's a good discussion that the group needs to have and I have some initial ideas for how it could be done that I haven't had the chance to put on paper yet but the place for that discussion is not in the scope of the CDNI metadata interface IMO for the reasons I give above.

Communicating capabilities from a Downstream CDN to an Upstream CDN and the specific properties for how to deliver some content that need to be communicated by an Upstream CDN to a Downstream CDN are obviously related. However, the statement that you quote above is meant to convey that for CDNI Metadata, let us first agree that the proposed data model in the draft and the structure of the proposed interface are (or are not) the right starting points for describing how a CDN should deliver content and for communicating/distributing that CDNI Metadata from an Upstream CDN to a Downstream CDN rather than risking going off on a tangent with comments such as "you haven't included a property to allow an Upstream CDN to indicate that a piece of content should be delivered no faster than X Mbps" etc. because adding/describing new properties to convey different ways to deliver content is trivial compared to making sure we have a solid foundation for the CDNI Metadata Model & interface on which to overlay such properties.

Ben