Subject: [CDNi] Trigger time policy using local time

From: Ori Finkelman <[email-masked]>
Date: Mon, 15 Oct 2018 12:23:56 +0300

Hi,
In the last CDNI meeting we have agreed to add to the time policy the
local-time flag (see below).
The required semantics is the instruct the dCDN to run the trigger at the
given time window in there own local time.
For example: "I want you to run this trigger between 3AM-5AM at your own
local time".

The reasoning is that network resource availability and prices may vary
across the day, and specifically are more available and less expensive at
off-peak hours. however off-peak hours are local per region.
In the past we have proposed to avoid adding this flag by using a
combination of location policy and time policy, but that would require
calling a separate trigger for each region.

While working on adding this "local-time" flag, I have realized that
TimeWindow as defined in https://tools.ietf.org/html/rfc8006#section-4.2.3.2
in UTC and it is better not be used to represent local time.
The only option I can think of using textual time format as defined in
RFC3339, and the local time flag should be interpreted by the dCDN as "you
should interpret this as if it in your own local time".
Using RFC3339 means we need to add a new time object instead of the
TimeWindow.

Thoughts ?

Thanks,
Ori

On Sun, Jul 22, 2018 at 9:19 AM Ori Finkelman <[email-masked]> wrote:

> Here are the comments we got CDNI meeting.
>
> *Playlist:*
> change abr-protocol to media-protocol, as it may be used for other media
> rather than video abr.
>
> *Trigger TimePolicy:*
> Add local-time flag. When true the trigger should be executed at the local
> time, per zone.
>
> *Trigger error and warning propagation:*
> Considering triggers may be propagated to a chain of dCDNs, and
> considering we allow extensions to be safe-to-redistribute even if not
> understood, we should add a mechanism for propagating errors and warnings
> back to the uCDN.
>
> Thanks,
> Ori
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> [email-masked]
>

-- 

*Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
[email-masked]

---

From: Ori Finkelman <[email-masked]>
Date: Mon, 15 Oct 2018 12:58:41 +0300

Dear all,
In the last CDNI meeting we have agreed to add the ability to propagate
errors upwards in the trigger chain.
The reason for that is that when adding trigger extensions, some extensions
may be incomprehensible down the CDN path, and will result in an error
returned to the calling dCDN.

For example if uCDN-A calls a trigger on dCDN-B which is also propagated to
dCDN-C.
If dCDN-C has an error and it is returned to cCDN-B, then dCDN-B has the
option to either fail, or succeed with the "ecdn" error code, which is not
informational enough to understand what happened.

In order to face this we have agreed to add a mechanism to propagate the
error that happened and the dCDN in which it happened.

I am proposing to add to the Error Description defined in
https://tools.ietf.org/html/rfc8007#section-5.2.6 one of the following
options:
+ the cdn PID where this error occurred, this will all propagation of the
error upwards and at each point one can tell where it happened. in the
above example:
   * dCDN-C will issue an error to dCDN-B with "cdn": "dCDN-C"
   * dCDN-B will propagate this error to uCDN-A with "cdn": "dCDN-C"
+ or, a cdn-path in a stack order for example, in the case above
   * dCDN-C will issue an error to dCDN-B with "cdn-path": { "dCDN-C" }
   * dCDN-B will propagate this error to uCDN-A with "cdn-path": {
"dCDN-B", "dCDN-C"} - meaning that the error occurred in dCDN-C and the
ones before are merely propagating the error.

Thoughts ?

Thanks,
Ori

--