Re: [CDNi] Cache management interface | Triggers v2

[Guillaume Bichot <[e-mail]>]

Hi Alan.
There are several use cases wherein the AS number is not appropriate and also several ones wherein we do not need the cdn-path at all.
Therefore, I would go with your two proposals: 1/ making the cdn-path optional and 2/ allowing an alternative format for the CDN PID. The latter is related to CDN identification as a general problem in SVTA OC. This came up as a subject related to authentication where the uCDN is identified through a dedicated claim. The token used during authentication is computed by the dCDN that decides by itself how to identify the uCDN. We could have imagined reusing this uCND id as a the CDN PID. However, this is not standardized process as the form of the token is not imposed in Open Caching.  So, we are back with the pb: how to identify uniquely a CDN. I would propose a mechanism where the dCDN selects and impose the uCDN PID. This could be done through a dedicated API as part of the bootstrap API. For now, regarding the I-D, allowing an alternative scheme would be sufficient maybe like instead of an id starting with AS, we would have a scheme starting with PR (for private) .

Guillaume


From: CDNi <[e-mail]> On Behalf Of Alan Arolovitch
Sent: Tuesday, March 5, 2024 1:43 AM
To: [e-mail]
Subject: Re: [CDNi] Cache management interface | Triggers v2

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]> | M +1.617.8939400<tel:(617)%20893-9400> | W www.2you.io<http://www.2you.io/>

Broadpeak, S.A. Registered offices at 3771 Boulevard des Alliés, 35510 Cesson-Sévigné, France
Trade Register: 524 473 063
This e-mail and its attachments contain confidential information from Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only for the person to whom it is addressed.
If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy laws, and is committed to the protection of personal data. Emails and/or attachments thereof exchanged between us may include your personal data which may be processed by Broadpeak and/or its affiliates according to applicable privacy laws & regulations.
In compliance with Regulation (EU) 2016/679 (GDPR) and applicable implementation in local legislations, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing.
For such purpose, or to know more about how Broadpeak processes your personal data, you may contact Broadpeak by email [e-mail].
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr