Re: [CDNi] draft-ryan-cdni-capacity-insights-extensions

[Andrew Ryan <[e-mail]>]

Kevin,

   Thank you very much for the feedback!  Please see responses inline:

On 11/7/2021 1:50 AM, Kevin Ma wrote:
> Hi Andrew,
>
>   Thanks for updating the draft.  There's a lot of good content in the 
> new version.  Some comments, questions, and nits below:
>
>   - section 2.1.2: should "FCI.Telemetry" be "FCI.TelemetrySource"?

The long term goal for this is that it would be meant to describe not 
only the source of Telemetry, but also the specifics of the telemetry 
data, which types of telemetry sources are supported etc.  I don't have 
a strong opinion on the naming, but my thought process here is that it's 
meant to describe several components of Telemetry capabilities, 
including source.

>      Is it correct that this just describes attributes of the metrics 
> emitted by the given source and that it is not actually streaming any 
> metrics?  i.e., if I attached to the "capacity_metrics_region1" 
> metrics source, I could then expect to see streams of different types 
> of metrics, e.g., a 5m median bandwidth usage that is 25 minutes old?

That is correct, this is meant to act as a mechanism for the dCDN to 
inform the uCDN about available Telemetry sources and the 
characteristics of those sources.  There will be no communication of 
telemetry data via the FCI interface.  Data collection from a referenced 
Telemetry source is an out of band process at this point. though 
eventually, we would like to work to put together an RFC proposing a 
formal Telemetry interface, which leads into the next point.

> And is it then completely up to the CDNs to negotiate out-of-band how 
> to connect to a given source (push vs pull, endpoint addr/url, etc) 
> and in what format to expect the data (open telemetry, etc)?  
> Should that be in the source object?
Extending on the last statement I made, we have a goal to put together a 
formal specification for a Telemetry interface, in which the actual 
format of data and transport of data is well defined. This would help 
standardize all things Telemetry, and we feel this would be valuable, 
but also will require a fair amount of effort which wasn't necessarily 
fully coupled with Capacity.  During our discussions it was recognized 
that there are already many instances where Content Providers and/or 
uCDNs have already established mechanisms for consuming telemetry data 
from a dCDN.  We wanted to be able to allow the Capacity components to 
leverage these existing data sources (via a Generic Telemetry Source) 
but leave room such that when a formal Telemetry interface is proposed, 
that the Capacity signaling could easily integrate with that. So to 
summarize, at the moment with the Generic Telemetry source, it is 
expected that the interaction with the telemetry source and format of 
data is completely out of band process and is really meant for already 
existing data integrations, in the future though we hope to make a more 
formal Telemetry interface where the transport and format is well defined.
>
>   - section 2.2: Do "total-limits" and "host-limits" need to be 
> separate arrays?  Is the only distinction that the former is not 
> allowed to have capacity limit objects with "host" names and the 
> latter is?  Could it be a single "limits" array, or is there some 
> parsing efficiency to keeping them separate?

The intention behind total-limits was to represent limits scoped to the 
entire uCDN<->dCDN delegation (i.e.  these are the total limits of 
traffic delegation).  The host-limits are to be scoped to a specific 
host (CDN Domain).  The idea is that the CDN Domain used in a 
host-limits would allow more granular limits to be specified, for 
example the total traffic delegation towards the dCDN would be X, but 
for traffic on low-latency-hls.example.com, there is a much higher RPS 
requirement to handle this traffic, so the dCDN will need to provide a 
specific limit for that traffic delegation.
In terms of the format of the JSON, We might be able to potentially 
remove the top level array, and then mark the "host" as an optional 
component, and assume that a lack of a host means the scope is total 
traffic.

>
>   - section 2.3: I would remove RequestedCapacityLimits from the other 
> draft and just specify it here, if the context makes more sense.

This makes sense, I can bring this up with Glenn

>
>   - section 3: Is the intent to also create new registries for the 
> telemetry source and capacity limit types?

For capacity limit types, yes.  I think there is no way around not 
having a list to iterate over such that the uCDN and dCDN can agree on 
limits they both can agree on. Example the uCDN might support sessions, 
where as the dCDN has no notion of what a session is and therefore can 
not specify limits based on that.

The Telemetry sources though is more of a TBD and at the moment we have 
only gone so far as to specify a Generic source for the reasons listed 
above.

>
>   - sections 4/5: The security section probably needs to discuss 
> issues related to misuse or falsification of metrics information.  A 
> privacy section should also be added and probably needs to discuss 
> concerns related to exposing the proposed types of metrics information.

This is a very interesting call out.  If I recall there is mention in 
some of the other documents about potential abuse in the CDNi workflow 
and that a reputation service would be a potential means for addressing 
that, but was somewhat listed as out of scope.  Would it be fair to 
follow the same approach here?

In terms of Privacy this is also a very good call out, we can certainly 
add a section stating that it is up to the parties involved to ensure 
that any data exposed is in compliance with current legislation.  My 
initial thought is that the aggregated Telemetry data would be 
obfuscated enough to remove any PII, but it is still a good thing to 
call out for sure.


>
>   thanx!
>
> --  Kevin J. Ma
>
> nits:
>   - section 1: payload types are actually defined in section 2.2 of 
> RFC 7736 (https://datatracker.ietf.org/doc/html/rfc7736#section-2.2)
>   - section 2.1: "it's dCDN" -> "its dCDN" (multiple)
>   - section 2.1: "a non ambiguous" -> "an unambiguous"
>   - section 2.1.1.1 <http://2.1.1.1>: "format,etc" -> "format, etc"
>   - section 2.1.1.2 <http://2.1.1.2>: "describe the metric" -> 
> "describes the metric"
>   - section 2.2.1: "deducing" -> "reducing"
>   - section 2.3: "per host" -> "per-host"
>   - section 3.1: "simialr" -> "similar"
>   - section 3.1: will need to tighten up the language here
>   - section 3.1.1; should link to section 2.1.2
>   - section 3.1.2; should link to section 2.2.2
>   - section 3.1.3; should link to section 2.3.2

Thank you for catching these.  I will work on these in the next version 
for sure.


>
>
>
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni