Re: [CDNi] Cache management interface | Triggers v2

[Alan Arolovitch <[e-mail]>]

One of the goals of the CI/T v2 changes proposed below is to make the cache
management interface defined under the open caching architecture
fully interoperable with the CI/T v2 triggers.
One of the topics that came up in this context is cascaded CDN use case and
I would like to solicit the group's feedback to the following:

The CDNI architecture in several places deal with CDN cascading, including
at least:
- request redirection loops (
https://www.rfc-editor.org/rfc/rfc7337.html#section-5)
- trigger loop detection (CI/T v1
https://datatracker.ietf.org/doc/html/rfc8007#section-4.6,  CI/T v2
https://datatracker.ietf.org/doc/html/draft-ietf-cdni-ci-triggers-rfc8007bis-11#name-loop-detection-and-preventi
)
- distribution of metadata in a chain (
https://datatracker.ietf.org/doc/html/rfc8006#section-3.2)

RFC8007 p4.6 prescribes use of CDN Provider ID (CDN PID) based on ASN, to
prevent loops in a cascaded use case
The CI/T v2 draft prescribes attaching CDN PID to trigger commands going
from uCDN down the chain and error statuses going up the chain from dCDN(s)
to uCDN.
This is clearly lacking flexibility for actual deployments, where neither
uCDNs nor dCDNs necessarily align on AS boundaries.

By contrast, the open caching architecture takes a simpler view of the
topology and concerns itself with directly attached CDNs only.
It doesn't preclude cascading, so it is possible for CDN A to delegate
traffic to CDN B which in turn delegates it to CDN C, so that CDN B (tCDN
in CDNI terminology)
acts as dCDN to CDN A, and as uCDN to CDN C.
However under open caching it would be the duty of CDN B to relate commands
and metadata between CDN A and CDN C, in a way that prevents loops and
without
CDN A and the CDN C on either side of CDN B being aware of each other's
existence.
Also the loop detection appears to be less of a concern, because of how the
open caching primarily handles delegation from CDNs with broad coverage
footprint down to
(ISP-based) CDNs with increasingly narrowing footprint. This is unlike CDNi
which initially envisioned a federated delegation model, which made loops
in a delegation chain much more likely.

One way to make CI/T v2 triggers (and broader CDNI architecture)
interoperable with the open caching specs is by either:
a. making CDN cascading information optional (e.g. "cdn-path" in CI/T v2
trigger command and "cdn-id" in Error.v2 Description in the CI/T v2 draft)
b. OR by allowing self-allocated CDN PIDs that are not AS-based

Alternatively, if there's a real need to support explicit cascading, we
would minimally need a mechanism for CDN PID allocation and management that
doesn't depend on AS numbers.

Is it a fair assessment of the status quo?
Thoughts and comments are welcome.

Cheers
Alan



On Tue, Feb 13, 2024 at 7:18 PM Alan Arolovitch <[e-mail]> wrote:

> Hello,
> As a follow-up to my email from last year, I have had sidebar
> conversations with Nir and Sanjay about the below.
> There's an interim proposal for the CI/T v2 draft modifications outlined
> here
>
> https://docs.google.com/document/d/11oBs3CMnYSbuXR0rHNU26qe3lLKaug2yKp81aML265c/edit?usp=sharing
>
> To summarize it briefly, the CI/T trigger execution model today leaves
> room for dCDN to process triggers submitted to it by uCDN
> in any order, in parallel or sequentially, immediately or in batches.
> There's a need for uCDN to determine trigger processing in further
> detail, including order and timing of processing, trigger
> inter-dependencies, and to monitor trigger processing queueing in further
> detail.
>
> To address the above, it is primarily proposed to:
> - Introduce ExecutionPolicy trigger extension, that would allow uCDN to
> indicate (i) relative trigger priority (ii) trigger urgency (iii) trigger
> dependency on other triggers
> - Introduce trigger labels in key-value format, that can be set at trigger
> level and/or by trigger extensions, so that trigger status collections
> can include trigger labels in addition to the trigger URLs, and trigger
> status collections can be filtered by label in addition to being filtered
> by
> trigger state
>
> We would like to merge the proposal into the next CI/T v2 draft
>
> Kind regards,
> Alan
>
>
> On Thu, Oct 26, 2023 at 1:26 PM Alan Arolovitch <[e-mail]> wrote:
>
>>
>> Hello
>>
>> I'm leading the cache management interface project at SVTA. The scope is
>> to define a full-fledged CDNi-compliant cache management interface as part
>> of the open caching architecture
>> We are heading towards completion of the initial spec draft, and I would
>> like to share my thoughts on how to best bring this work into CDNi.
>> The current high-level scope includes:
>> - Trigger-based cache data operations that rely on and extend CDNi
>> triggers v2 as currently defined in CDNI CI/T 2nd edition
>> - Additional CDNi metadata objects allowing uCDN to assign cache objects
>> in configuration hierarchy to cache buckets; tag cache objects for use in
>> triggers via content.ccid trigger type; indicate cache object priority
>> - Cache bucket management API
>>
>> The current thinking is to split the work into two documents - one that
>> specifies extensions to triggers v2, and the other that pertains to cache
>> management specific metadata and related API.
>>
>> If so, would it make sense to incorporate the triggers v2 changes into
>> the current draft - all or some of them, or introduce them as a separate
>> document?
>>
>> The proposed triggers v2 change scope is as follows:
>> 1. New trigger extension PrepositionPolicy, per paragraph 8 of CDNI CI/T
>> v2, governing prepositioning policies like retry, patrial retrieval,
>> preposition methods, concurrency and bandwidth, and use of CDNi metadata
>> 2. New trigger extension PurgePolicy, governing purge semantics
>> 3. New trigger extension CommonPolicy, governing trigger execution
>> priority and type of URLs referenced in triggers (published vs. cache-key
>> URLs)
>> 4. Changes to trigger extension TimePolicy (8.2 in CDNi CI/T v2), adding
>> trigger execution scheduling, based on JSON-based iCAL [RFC7265], allowing
>> specifying start, stop, recurrence, duration, timezone etc.
>> 5. Changes of new content.playlist trigger spec(7.5.1 in CDNi CI/T v2) to
>> content.objectlist spec, in conjunction of introducing new types of object
>> list, in addition to hls, dash and mss types per 7.5.2 in CDNi CI/T v2,
>> allowing specifying lists of objects for trigger in JSON-encoded and plain
>> text formats
>> 6. Changes to Trigger Status Resource v2 (6.1.3 in CDNi CI/T v2) to
>> specify objectlists that were derived from content.objectlist triigger spec
>> 7. Changes to error codes in Error v2 to support the new extension
>> functionality
>>
>> One possible option is to incorporate changes to existing objects (items
>> 4-7) in the current draft, and defer the new trigger extensions (1-3) to a
>> separate document.
>>
>> Sanjay, Kevin,
>> I would appreciate some time in the open mic section in Prague to talk
>> about this
>>
>> Kind regards
>> Alan
>>
>>
>>
>
>
>

-- 
Alan Arolovitch
CEO, 2You IO
*E* [e-mail] | *M* +1.617.8939400 <(617)%20893-9400> | *W* www.2you.io