Re: [CDNi] Cache management interface | Triggers v2

[Alan Arolovitch <[e-mail]>]

Guillaume,

PIDs allocated by dCDN is one option, and it's probably sufficient for
directly attached CDNs and when multiple uCDNs work with one dCDN.
In case of cascading and assuming you want transparency across the chain
(CDNA <--> CDNB <--> CDNC), having a shared identity server (as in OAuth
2.0) would be needed.
Also, I think we want to optimize for a single uCDN accessing multiple
dCDNs using common identifier and credentials.
So it seems that once you look at many-to-many relationships, we would need
a 3rd party identity provider option.
The full CDN PID would consist of at least CDN identifier and identity
provider URI.
dCDN can provide its own URI for simple and/or private use cases.
In my response to Jay, I proposed that we leave room for such PID in the
CI/T v2 draft as an optional field.

Best regards,
Alan

On Tue, Mar 5, 2024 at 4:49 AM Guillaume Bichot <
[e-mail]> wrote:

> 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]> 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
>
>
>
> <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
>