Subject: Re: [CDNi] CDNI Triggers interface

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Mon, 26 Mar 2012 13:29:12 -0500

Rob,

Great document, nice clarity. A few comments / questions:

1. A single trigger can apply to multiple URLs but only a single
"status" indicator is provided when then the trigger is polled. What
happens when prepositioning one URL succeeds and another one fails? 

2. For the cascading CDNs case, another question on status granularity.
When does a trigger complete? After the immediately downstream CDN
finishes the task? Or after the downstream CDN and its own downstream
CDNs finish the task? If one dCDN fails to preposition content while
another succeeds, is the trigger status Complete or Failed?

3. Can triggers be processed out of order? I believe Kent had a similar
comment in his email, but I'm not sure about the proposed solution.
Would basing decisions on time open us up to race conditions?

4. In the trigger request, content urls are separate from metadata urls.
How is metadata identified? Is the metadata URL in the trigger request
the url of the content for which the metatdata should be
purged/prepositioned? Or is the metadata URL that of the metadata
resource itself? If the latter, I see no reason to distinguish between
metadata and content urls. 

5. In the HTTP redirection case, each CDN uses a different URL to
identify content. For example, an upstream CDN may use
http://ucdn.com/content1 while a downstream CDN uses
http://dcdn.com/ucdn/content1. Is it a correct assumption that each CDN
in a cascade of CDNs must rewrite the trigger URLs to match what the
downstream CDN would expect?

6. From a security considerations standpoint, the Triggers interface
requires client authentication. I believe that's what you're hinting at
in the Security Considerations section but it could be more explicit. I
don't think this requirement is true for all CDNI interfaces (most need
server authentication, but maybe not all need client authentication).

7. Is polling the only option for learning about status changes? Would
registering a callback be more scalable?

8. Is there an implicit assumption that for any given piece of content,
there will only be a single source of triggers? What if a CDN receives
the same trigger from two upstream CDNs?

Thanks,
Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rob Murray
Sent: Wednesday, February 29, 2012 5:34 PM
To: [email-masked]
Subject: [CDNi] CDNI Triggers interface

Hi all,

I've just uploaded a new draft that proposes a CDNI Triggers interface
...

    http://tools.ietf.org/html/draft-murray-cdni-triggers-00

There was some discussion at the last WG meeting about whether triggers
fit best as part of the control or metadata interface - the suggestion
was
that concrete proposals for the interface might help us spot commonality
with one or the other, so let's see!

Please take a look, your comments are welcome.

Best regards,
Rob.

On 29/02/2012 19:37, "[email-masked]"
<[email-masked]>
wrote:

>A new version of I-D, draft-murray-cdni-triggers-00.txt has been
>successfully submitted by Rob Murray and posted to the IETF repository.
>
>Filename:	 draft-murray-cdni-triggers
>Revision:	 00
>Title:		 CDN Interconnect Triggers
>Creation date:	 2012-02-29
>WG ID:		 Individual Submission
>Number of pages: 33
>
>Abstract:
>   This document proposes a mechanism for a CDN to trigger activity in
>   an interconnected CDN that is configured to deliver content on its
>   behalf.  The upstream CDN can use this mechanism to request that the
>   downstream CDN pre-positions metadata or content, or that it re-
>   validate or purge metadata or content.  The upstream CDN can monitor
>   the status of activity that it has triggered in the downstream CDN.
>
>
>
>
>
>
>The IETF Secretariat
_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: Stef van der Ziel <[email-masked]>
Date: Mon, 26 Mar 2012 21:17:06 +0200

Hi all,

I would like some clarification about CDNi metadata.
It seems like it is being proposed that metadata about content is distributed alongside with the content in XML format.
However, metadata is such a vague term. What specific metadata is meant here. I can think of these metadata types:

1 - Technical content metadata (such as bit rates, screen width, codecs, length, size, ingest date, part of logical asset)
2 - Instructional metadata (such as delete, flush, TTL, prefill, distribute, lock, geo-block)
3 - Status metadata (such as popularity, integrity checksums, distribution status)
4 - Enrichment metadata (such as separate subtitles, poster frames)
5 - Description content metadata (such as name, contents, keywords, author)

These types of metadata should be treated in different ways:

1 - Technical metadata can be sent via XML files but it is up to the CDN to pass it through or parse and use it. I would prefer to exchange this data via REST or SOAP APIs if CDNs need to use the data.

2 - Instructional metadata should better not be distributed via files. Instructions should be exchanged via REST or SOAP APIs.

3 - Status metadata should better not be distributed via files. Status can be exchanged via RSS feeds or REST or SOAP APIs.

4 - Enrichment metadata should be treated as regular content, not as specific metadata.

5 - Description metadata is useful for content management systems but are less useful for CDNs
Of course a CDN can simply pass it through but then it should be treated as regular content, not as specific metadata.

I would treat logs as separate data, not as metadata.

Kind regards,

Stef van der Ziel

-- 
Owner Jet Stream BV | StreamZilla
www.jet-stream.com | www.streamzillacdn.com

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 27 Mar 2012 11:36:10 +0100

Stef,

The terminology section of draft-ietf-cdni-problem-statement-04 tries to provide some clarification.

In general I tend to think of CDNI Metadata (as exchanged over the CDNI Metadata interface) to be configuration data so includes things like:

 - What/How to contact the origin server for content
 - How to deliver the content (throttle etc.)
 - What geo-blocking rules apply to the content
 - what authorisation (tokens etc.) is required
 - etc.

more inline

> 1 - Technical content metadata (such as bit rates, screen width, codecs, length, size, ingest date, part of logical asset)

I think this is largely out of scope for CDNI. It is information the content provider might have but that information is not typically shared with CDNs.

> 2 - Instructional metadata (such as delete, flush, TTL, prefill, distribute, lock, geo-block)

Things like delete/flush/prefill/etc should be covered by draft-murray-cdni-triggers-00

TTL of metadata on the CDNI Metadata interface is determine by Cache-Control headers in the responses. Geo-blocking would be explicit in the CDNI Metadata exchanged over the CDNI Metadata interface (see above).

> 3 - Status metadata (such as popularity, integrity checksums, distribution status)

IMO this is largely internal to a CDN. upstream CDN could track popularity using log data sent back from downstream CDNs.

> 4 - Enrichment metadata (such as separate subtitles, poster frames)

This is relevant to the content provider & client but a CDN doesn;t need explicit knowledge of this IMO.

> 5 - Description content metadata (such as name, contents, keywords, author)

Same as (4).

> 1 - Technical metadata can be sent via XML files but it is up to the CDN to pass it through or parse and use it. I would prefer to exchange this data via REST or SOAP APIs if CDNs need to use the d…

Could be XML or could be JSON (how we serialise the metadata onto the wire is less critical at this stage IMO than making sure we're carrying the right metadata).

Agree on REST based APIs. I'd strongly like to avoid SOAP.

> 2 - Instructional metadata should better not be distributed via files. Instructions should be exchanged via REST or SOAP APIs.

See draft-murray-cdni-triggers-00 where we propose a REST interface for this & an RSS-inspired interface for retrieving status of the triggers.

> 4 - Enrichment metadata should be treated as regular content, not as specific metadata.

Agreed.

> Of course a CDN can simply pass it through but then it should be treated as regular content, not as specific metadata.

Agreed.

> I would treat logs as separate data, not as metadata.

Agreed.

HTH
Ben

---

From: Rob Murray <[email-masked]>
Date: Wed, 28 Mar 2012 09:56:41 +0000

Hi Matt, many thanks for the input - responses inline...

>happens when prepositioning one URL succeeds and another one fails?

I think failure of any part of the trigger should mean the overall result
is Failed.

For prepositioning, as you suggest, it'd be useful to have an indication
of which URLs caused the problem - I think that could be added to the
"error" property (which is undefined at the moment). Error types that
include a failure reason and sets of URLs would make sense.

We need to do some more analysis of likely causes of failure, and what
information uCDN will find useful. Input on that would be welcome.

>another succeeds, is the trigger status Complete or Failed?

Because uCDN can have no direct influence on further-downstream CDNs, I
think it has to be each CDNs responsibility to make sure all of its dCDNs
complete triggers before reporting upwards.

In the case of prepositioning, the net result of failure in one dCDN would
be that the footprint or capabilities advertised by the intermediate CDN
would be incorrect for that content - so the overall result of the trigger
has to be Failed.

I'm not sure whether it'd useful (or even possible/allowable) to state
which dCDNs failed in the intermediate CDN's trigger status report.
There's not much uCDN could do with that information other than report it
back to the intermediate CDN, and there might not be a way to refer to the
failed dCDN anyway - if each uCDN sees one downstream footprint it may not
know or care that it's actually composed of a cascade of other networks
(and the intermediate CDN may not want to expose that detail).

>Would basing decisions on time open us up to race conditions?

I don't think there's a race condition - the only potentially-bad
interaction would be a purge/invalidate running behind a preposition
trigger (so data that's just been carefully acquired and prepositioned
gets immediately deleted).

By creating triggers in-order, if invalidate/purge only act on data
acquired before the trigger was created, uCDN can make sure only the old
data is removed.

Thinking about other ways of achieving the ordering - I don't think we've
any requirements for clock-sync between CDNs, so it'd be nice to avoid
putting times in trigger requests. Another option might be to invent a way
of describing sequencing within a trigger request (delete first, then
preposition), but that's starting to get messy and still doesn't deal with
interaction between triggers.

I think this is a simple solution that leaves uCDN in control of the
sequencing.

>metadata and content urls.

Yes, we talked about this when coming up with the draft and decided than
making the distinction was probably useful and at-worst harmless.

Exactly how to refer to metadata is an open issue that needs more thought.
I tried to outline some options in section 5.1.1 of the draft. As the
metadata interface evolves the answers might become clearer, but ideas are
welcome.

But, whichever option we pick - metadata and content are quite distinct
and while separating them in the trigger request comes at no real cost, it
might make processing on dCDN easier. Operations on metadata may be quite
a different to operations on content in its control plane.

If it is possible to tell from the URL whether it's a metadata or content
reference, having the separation might at least be a useful sanity check
on the request.

>downstream CDN would expect?

Yes, I think that's the case - but, as above, the form of a metadata
reference is an open question. One option (not necessarily a good option!)
would be a canonical URL, in which case it wouldn't need rewriting. I
think we need to wait for the metadata interface to take more shape before
we have a final answer here.

>server authentication, but maybe not all need client authentication).

Yes, that was what I was trying to get at - I can expand on it in the
draft and as the other interfaces take shape it should start to become
clearer what can be shared. If we end up with RESTful interfaces though
(as I hope we do), there might be quite a bit of commonality.

>registering a callback be more scalable?

Exact completion time of these operations isn't likely to be critical,
particularly for prepositioning but also invalidate/purge which (depending
on the request and the implementation) may involve slow trawls through
large volumes of cached data.

The polling mechanism would still be required to allow uCDN to get
intermediate status updates, and to check that a callback hadn't gone
missing - so adding a callback mechanism would add complexity and imply
more responsiveness that is perhaps necessary.
 
With uCDN polling for status, dCDN can choose to only calculate the status
when asked - or less frequently if it wants to return a cached result.
When compared with what the rest of the CDN is doing (and is good-at),
dealing with conditional HTTP requests for trigger status probably isn't
be a huge burden.

>the same trigger from two upstream CDNs?

There has to be access control - each uCDN must only be able to create
triggers that affect its own data (one uCDN shouldn't be allowed to flush
another's content).

Where there are multiple routes from an origin to a dCDN for one set of
content (through different uCDNs to a final dCDN), it may not always be
clear which uCDN owns that content. Using metadata URLs to refer to
content as you mentioned above might help - but I think it has to be
dCDN's responsibility to resolve the conflict... perhaps that
configuration will be disallowed, or we may need a non-technical solution
in interconnect agreements.