Re: [CDNi] Cache management interface | Triggers v2

[Jay Robertson <[e-mail]>]

Hi Alan,

After giving this some consideration, I am not entirely unconvinced that
making the cascading information optional is the best approach.  This is a
simple safety mechanism meant to prevent loops that have unintended, and
potentially detrimental, consequences.  While I understand that open
caching is today's most likely use case for CDNi rather than a federated
delegation model, I think assuming that this will be the primary or only
use case going forward is not the safest bet as we often cannot predict how
these specifications may be used in the distant future--or even the odd
ways that someone might be using them now.  Additionally, I know that some
amount of care and effort has been spent amending CI/T without breaking the
original RFC8007.

I think you have an interesting point regarding the use of AS numbers.  One
thing I might note is that the context that AS numbers are being used is
simply for identification.  I don't think they necessarily need to impart
any meaning regarding the underlying network architecture.  If a CDN has
multiple AS numbers in its network, I think they could simply pick one and
use it consistently for identification purposes.  However, an organization
could possibly have no AS numbers, particularly if they operate a pure open
caching network that embeds caches in service provider networks, for
example.  While I recognize that this could happen, I'm not sure I
understand how large of a problem this is, and I struggle to think of a
great solution.  Guillaume suggested possibly negotiating this with a
bootstrap API, but as far as I can tell, that still remains an
unimplemented suggestion of RFC7337.  If this is not a huge problem to
solve, one thing that could be considered is that there is a large range of
32-bit private AS numbers (4200000000–4294967294) available.  While not
wonderful or elegant, one could pick a number at random out of this pool
and feel reasonably certain about having a unique number.  As written, CI/T
makes no judgment about the AS number chosen.  Of course, I'm open to other
suggestions if someone can think of a better approach.

Thanks,
- Jay


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
>
>
>
>
> --
>
> Alan Arolovitch
>
> CEO, 2You IO
>
> *E* [e-mail] | *M* +1.617.8939400 <(617)%20893-9400> | *W* 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
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>


-- 
*Jay Robertson*  CDN System Architect
Qwilt | [e-mail] | qwilt.com