Subject: Re: [CDNi] CDNI Triggers draft updated

From: Kevin J Ma <[email-masked]>
Date: Mon, 5 Nov 2012 14:35:22 -0500

Hi Rob/Ben,

  A couple questions about the updated draft:

  - Is section 2.1 wrt purge/invalidate, are we saying that
    purge/invalidate takes precedence over pre-position when both are
    in the same request, i.e., pre-position always gets processed
    first, and a transit CDN must complete its own preposition and
    purge/invalidate before sending the preposition and purge/invalidate
    request to any cascaded dCDN?

    If, however, separate requests for pre-position and purge/invalidate 
    are used and the pre-position is only partially complete when the
    purge/invalidate comes in, the CDN may purge/invalidate a portion of
    the newly pre-positioned content, but the uCDN may not know which
    portion was purged after pre-positioning?  Same goes for cascaded dCDNs?

    If so, then are we saying that if the uCDN wants to maintain the
    order of operations, it must wait for the trigger result from the
    pre-position before issuing the purge/invalidate?  And that applies
    recursively to all cascaded dCDNs?

  - In section 4, when it talks about loops, wrt the much discussed
    diamond deployment, how would the proposed de-duplication schemes
    affect the no-loops requirement?

      The dCDN must ensure that activity triggered by uCDN only affects	
      metadata or content originating from that uCDN. Since only one CDN	
      can be authoritative for a given item of metadata or content, this	
      requirement means there cannot be any "loops" in trigger requests	
      between CDNs.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rob Murray
> Sent: Thursday, August 30, 2012 2:34 PM
> To: [email-masked]
> Subject: [CDNi] CDNI Triggers draft updated
> 
> Hi all,
> 
> We've submitted an update to the CDNI Triggers draft dealing with comments
> against the first version, we've not addressed open issues yet...
> 
>     http://tools.ietf.org/html/draft-murray-cdni-triggers-01
> 
> 
> The main change in this version is to allow multiple trigger actions in a
> single request, so that an invalidate/delete can be packaged with
> prepopulate in order to replace content.
> 
> Open issues include:
>   - how to refer to content and metadata, including pattern matching for
> invalidate/purge (depends on metadata draft)
>   - how to report failure (need to come up with error codes, and deal with
> partial failure)
>   - encoding may change to align with metadata and other interfaces
> 
> We'll continue to work on those things.
> 
> Best regards,
> Rob.
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Rob Murray <[email-masked]>
Date: Tue, 6 Nov 2012 17:56:55 +0000

Hi Kevin - responses inline ...

>    request to any cascaded dCDN?

The transit CDN has to pass-on the combined request, so its dCDN also has
to obey the rules about not deleting the content it just prepositioned as
part of the same request.

>    portion was purged after pre-positioning?  Same goes for cascaded

I think purge/invalidate are to get rid of broken content, it only really
makes sense to use them when the origin is fixed or disabled, otherwise
the broken content can just be reacquired. In that case, if the
preposition continues to run after the purge/invalidate arrives, it will
either be acquiring mended content or the acquisition will fail.

But ... we've been thinking only about making sure that content
pre-positioned after an invalidate/purge isn't immediately disposed of.

The converse is perhaps a more serious problem, and I don't think we've
dealt with it ... if uCDN hasn't finished its purge/invalidate and it
still serves that content, it could be picked up by the dCDN's
pre-position and therefore not picked up by the associated
invalidate/purge in dCDN.

One way to deal with that would be to say that caches have to check
requests it's serving against the invalidate/purge requests they've not
completed (and re-validate/re-acquire at that point if necessary). That'd
mean from an external viewpoint the invalidate/purge takes affect as soon
as the cache learns about the request, the search of cached URLs doesn't
have to complete - the CDN could hold on to the trigger until it's
distributed it to all of its affected caches.

Not sure whether all CDN implementations would be able to do that.

>    recursively to all cascaded dCDNs?

Holding on to triggers until they're complete in each uCDN doesn't seem
like a good idea, in a cascade it could be a very long time before the
trigger affects content being served to end users.

Perhaps we are best to leave it to the originator of the triggers to
sequence triggers - they can send in invalidate/purge requests and expect
them to cascade quickly, but they should wait for the response before
triggering pre-position.

If deleted content is requested before it's all re-pre-positioned it'll be
acquired in the normal way... there's always a fallback for pre-position
but not for invalidate/purge. So I think we have to make sure
invalidate/purge are acted upon quickly, and perhaps shouldn't get hung up
in the delete then immediately pre-position use case.

>      requirement means there cannot be any "loops" in trigger requests	

We've not considered the content de-duplication mechanisms in this yet
since they're not settled. (We should remember the impact of
de-duplication on other aspects of CDNI when considering them though.)