Re: [CDNi] Request for WG Adoption: Capacity Insights

[Kevin Ma <[e-mail]>]

Hi Andrew,

  Some quick responses:

> Do you feel that clarifying the range to be positive integers and leaving
the limits "unbounded" would be sufficient here?
Yeah.  That's probably good.

> I would propose that we state that invalid payloads can be ignored and
even state that any previously valid payloads can be honored until such a
time as a new valid payload can be acquired.
That works for me.

> We may need some guidance on how to best define this.
You can look at how the footprint registry was defined here (it should be
pretty similar):
https://datatracker.ietf.org/doc/html/draft-ietf-cdni-metadata-21#section-7.2

> ... Would the above two statements be useful if included into the
document?
Yes.  Thanks.  I think it is always better to show the IESG that we did
think about it and here's a quick explanation of the risks if something bad
were to happen.

> I am wondering if it make sense to try and schedule a breakout session to
discuss this further, especially with several of the folks who have been
heavily involved with new draft for footprints.
It is probably worth starting a separate thread, and if necessary, we can
schedule an interim meeting if email is too cumbersome.

thanx!

--  Kevin J. Ma

On Tue, Jul 19, 2022 at 10:48 AM Andrew Ryan <[e-mail]> wrote:

> Hi Kevin,
>
>   I wanted to take a moment before diving in to thank you for the
> fantastic feedback and engagement!  I am excited to have more and more
> folks involved with this.  As an FYI I will be unable to make the IETF CDNI
> session coming up, so I am hoping to drive a lot of progress on this
> through the email list.
>
> Please see answers inline
> On 7/9/2022 10:37 AM, Kevin Ma wrote:
>
> Hi Andrew,
>
>   Thanks for the responses.  Some additional comments:
>
> > > - What is the scope of uniqueness for the id?  If it needs to be
> global, then it needs a registry.  If it needs to be dCDN unique, then it
> is just on the dCDN to ensure?
> > @Ben keep me honest here, but the intention is that the ID be unique
> within the scope of the uCDN and dCDN, i.e. the namespace is specific to
> this CDNi delegation relationship.In this case, it would be up to the dCDN
> to ensure uniqueness in the payload that it is returning to the uCDN.
>
> This could probably just be clarified and made more explicit in the text.
>
> ack - I agree we can clarify this
>
>
>
> > > - Is there a valid range for time-granularity, data-percentile, and/or
> latency, e.g., 0-31622400, 0-100, and/or 0-2678400, respectively?  And what
> happens if values are out of range?
> > In terms of valid ranges, I think the data-percentile would have a
> natural range of 0-100.  The others, I believe would not necessarily have a
> bound (outside of integer limits).  The usefulness of very large
> time-granularity and latency values somewhat diminish the usefulness of
> this data for near real time traffic steering decisions.
>
> I guess if you are only specifying a transport encoding, and not providing
> any guidance on how to interpret a given value, I guess I can see how you
> would want to limit restrictions on those fields.  Percentages outside of
> 0-100 are obvious ones, but I also don't know what a negative latency or
> negative time-granularity means, and a latency/time-granularity beyond a
> certain point (1yr?) is pretty meaningless.  My concern is that, from an
> interoperability standpoint, if the interpretation is different, then it
> could cause problems.  If the interpretation is going to be defined in a
> different spec or customized by individual CDNs, then we could make a
> stronger statement about that, but it feels like we could still be a little
> bit tighter on the bounds.
>
> You raise a very valid point in that at a bare minimum, we should be
> restricting to non negative values, as you point out, there is no situation
> that I can think of where an advertisement of negative capacity makes any
> sense.  Do you feel that clarifying the range to be positive integers and
> leaving the limits "unbounded" would be sufficient here?
>
>
>
> > > - What happens if there are duplicate names in a source object?
> > I think the intention behind declaring that the name needs to be unique
> circumvented any discussion on how to handle duplicate names
>
> With respect to error handling, I think it might be worth going a step
> beyond just specifying what a correctly formatted object looks like and
> provide some guidance on how to handle foreseeable error conditions (e.g.,
> non-unique or duplicated ids, out-of-range values, etc.).  I don't think
> we've done this as much in the past, but the previous capabilities were
> very binary (i.e., they contain a list of tokens and either you understand
> the token or not); but the complexity of information in the telemetry
> objects feels to me like there is more room for ambiguity and so could
> benefit from more discussion of how to handle unexpected data.  It may be
> as simple as: If the data doesn't make sense, ignore/discard it.  I could
> be off here, but that's my gut feel.
>
> I agree that specifying what to do if the payload doesn't make sense is a
> valuable addition.  I would propose that we state that invalid payloads can
> be ignored and even state that any previously valid payloads can be honored
> until such a time as a new valid payload can be acquired.  This will
> prevent situations where uCDNs who fail to get a valid payload from a dCDN
> don't stop all delegation due to a lack of updated limits, the uCDN will
> continue to use previously negotiated limits.  Using stale information
> might be considered a risk if the dCDN is truly having an outage, but in
> this case, this payload is more so about capacity guidance rather than any
> guarantee of service reliability, so I feel that the "use stale" case is
> probably more productive.
>
>
> > > - Should there be a registry for telemetry source types?  Will these
> be globally unique and well specified (in an RFC?) for interoperability?
> > @Ben I do think we will want a registry for telemetry source objects.
> > > - Should there be a registry for capacity limit types?  Will these be
> globally unique and well specified (in an RFC?) for interoperability?
> > I do believe this would make sense
>
> I agree that these should be registries.
>
> ack.  We may need some guidance on how to best define this.
>
> > > - I think we also need a privacy section that discusses the potential
> issues of divulging internal information about the CDN.
> > part of the data requirements are such that the data for capacity is
> scoped specifically to the uCDN,->dCDN delegation relationship..i.e. the
> data is very narrowly scoped.  The data being presented is also data about
> the dCDN by the dCDN.  Would there be any suggestions on how we might want
> to frame a statement for this?
>
> Though we rely on the underlying FCI protocol to handle auth and
> encryption (and the rest is out of the hands of the FCI object designer), I
> think it is worth discussing what happens if there is a breach, if there
> are specific consequences of specific data loss; or a statement that the
> data is so generic that it doesn't matter.  I think the question is: is
> there anything a competitor/adversary could gain from this data?  Since it
> only describes the source and doesn't contain the actual telemetry, the
> value of units and limits is minimal without hacking the actual source
> stream?  If so, a statement to that effect would probably suffice.
>
> In terms of the FCI.CapacityLimits payload, part of the design of the
> limits provided are what the dCDN is willing to offer to a specific uCDN
> for capacity.  If we look at this another way, it's not a full and complete
> mapping of all available capacity a dCDN may have.  We decided on this
> approach for several reasons, but at least one potential benefit of this is
> that it would limit the exposure to a dCDN of competitors being able to map
> out a full capacity footprint of the dCDN.
>
>
> In terms of someone gaining access to Telemetry endpoints which are
> referenced in FCI.Telemetry, this could be considered a issue for both the
> uCDN and the dCDN as this exposes actual usage information which is
> problematic for many reasons.  This particular data set though is provided
> outside the scope of the FCI payload, and relies on external
> APIs/datrasources/etc..
>
> Would the above two statements be useful if included into the document?
>
>
> > > - This is subdividing a footprint?  Would it make more sense (or at
> least be simpler) to just define more granular footprints.  It seems
> confusing to make essentially another way specify footprints.
> > This was a very lengthy part of our discussion in this draft.  There are
> use cases where "all traffic is not created equal" i.e Low Latency HLS will
> have much different request characteristics than Bulk game downloads or
> even Video On Demand.  The CDNi Footprint object doesn't allow for
> granularity on a published host basis.  We were working under the
> fundamental premise that we were trying to cause as little disruption to
> the fundamental components of CDNi and trying to encapsulate as much as we
> could related to capacity management without major overhauls to the
> original spec.  We would greatly welcome discussion on this topic.
>
> I think this is the big one, and I too would welcome some discussion on
> the topic.  My initial reaction is: maybe we should try to define a new
> footprint type, rather than create a sub-footprint for just this one
> object; it sets a bad precedent.  But, it needs more thought.
>
> :-) this one may open up a large can of worms to be sure.  Part of our
> thought process with this draft was to keep it as isolated as we could to
> help with the adoption process, but perhaps that was not the right approach
> to take.
>
> As we mentioned, the purpose of providing the "scope" within the
> FCI.CapacityLimits object was to allow finer granularity within a
> Footprint, such that if an uCDN is delegating lots of different types of
> traffic to a dCDN, that the dCDN had a way to differentiate capacity
> advertisements for identifiers which might correlate to the type of
> delivery.  Another way of saying that would be that in a lot of cases,
> uCDNs would have different published hosts for different forms of video
> delivery (live.example.com, vod.example.com, etc..). The dCDN would be
> aware of these published hosts due to the configuration metadata associated
> with it, and would be able to be aware of "traffic type" and could decide
> to offer different rps or other such limits based on that.
>
> Published host is not the only differentiating factor though, different
> delivery types could be handled on the same domain, but with different
> paths (www.example.com/live, www.example.com/vod). In this case, using a
> published host in a scope within the FCI.CapacityLimits object would not be
> sufficient, but we did attempt to incorporate the ability to reference
> service-id or property-id which maps into groupings of configurations that
> the dCDN and uCDN are aware of.
>
> The summary of the issue is that we have a potential gap in the definition
> of footprint, the specificity that is provided by the configuration spec,
> and the potential use case for allowing capacity payloads to share the same
> specificity as the configuration spec.
>
> A counter point to providing this level of granularity is that in
> practice, it may be very cumbersome for dCDNs to provide very granular
> advertisements to a uCDN, and may simply opt to provide more of a blanket
> capacity advertisement, which the uCDN is free to use as it will (I feel
> like this will be the case for the most part).  There may be instances
> though where a dCDN does want to get very granular though, which is why we
> attempted to bring this functionality into the payload.
>
> I am wondering if it make sense to try and schedule a breakout session to
> discuss this further, esspecially with several of the folks who have been
> heavily involved with new draft for footprints.
>
>
>
>
> thanx!
>
> --  Kevin J. Ma
>
> On Fri, Jul 8, 2022 at 12:30 PM Andrew Ryan <[e-mail]>
> wrote:
>
>>
>> On 7/4/2022 12:35 PM, Kevin Ma wrote:
>>
>> Hi Andrew,
>>
>>   (As a chair) Given the reduced scope, i.e., just two FCI objects
>> (though see my comments below), I think adoption would be within scope of
>> the current charter if other folks feel this is good work for the WG to
>> take on.  I don't have a problem with issuing a formal call for adoption.
>> I've included some comments on the current draft below.
>>
>> thanx.
>>
>> --  Kevin J. Ma
>>
>> section 1.3:
>>   - In the new paragraph about the uCDN calling a dCDN API interface,
>> what interface is that?  Is that an interface outside of CDNI.  It's not
>> clear if that relates to anything in this particular draft?  It would be
>> good to clarify this.
>>
>>
>> The intention here was that the uCDN would interact with an interface
>> which provides FCI payloads.  To remove ambiguity I can remove the the
>> reference all together:
>>
>> Original:
>>
>> In normal operation a uCDN will communicate with a dCDN, via an
>> interface, to collect and understand any limits that a dCDN has set forth
>> for traffic delegation from a uCDN
>>
>> Proposed:
>>
>> In normal operation a uCDN will communicate with a dCDN to collect and
>> understand any limits that a dCDN has set forth for traffic delegation from
>> a uCDN
>>
>>
>>
>> section 2.1.1:
>>   - What is the scope of uniqueness for the id?  If it needs to be
>> global, then it needs a registry.  If it needs to be dCDN unique, then it
>> is just on the dCDN to ensure?
>>
>> @Ben keep me honest here, but the intention is that the ID be unique
>> within the scope of the uCDN and dCDN, i.e. the namespace is specific to
>> this CDNi delegation relationship.In this case, it would be up to the dCDN
>> to ensure uniqueness in the payload that it is returning to the uCDN.
>>
>>   - the configuration descriptions references a yet to be defined
>> Telemetry Interface?  Is that in the scope of this document?  If not, it
>> would be good to clarify (or remove) this.
>>
>> The Telemetry interface is NOT in scope of this document, we can add
>> clarifying language to explicitly state this.  In Section 2.1.1.1 an
>> additonal sentence can be added:
>> Proposed:  The definition of a CDNI Telemetry interface is outside the
>> scope of this document.
>>
>>
>>
>> section 2.1.1.1:
>>   - Should there be a registry for telemetry source types?  Will these be
>> globally unique and well specified (in an RFC?) for interoperability?
>>
>> @Ben I do think we will want a registry for telemetry source objects.
>> The declaration of a "generic" type was meant as a place holder until a
>> formal Telemetry Interface was defined.  The Generic source type also
>> allows CDNs which already have an existing relationship and have already
>> established data channels for providing and consuming Telemetry to be used
>> "as is" without requiring additional integration steps.
>>
>>
>>
>> section 2.1.1.2:
>>   - What happens if there are duplicate names in a source object?
>>
>> I think the intention behind declaring that the name needs to be unique
>> circumvented any discussion on how to handle duplicate names
>>
>>
>>   - Is there a valid range for time-granularity, data-percentile, and/or
>> latency, e.g., 0-31622400, 0-100, and/or 0-2678400, respectively?  And what
>> happens if values are out of range?
>>
>> The intention is that these are meant to provide guidance to the uCDN in
>> terms of how accurate and how far behind real time the data set is, to help
>> inform how to react from a traffic steering perspective.
>>
>> In terms of valid ranges, I think the data-percentile would have a
>> natural range of 0-100.  The others, I believe would not necessarily have a
>> bound (outside of integer limits).  The usefulness of very large
>> time-granularity and latency values somewhat diminish the usefulness of
>> this data for near real time traffic steering decisions.
>>
>>
>>
>>
>> section 2.2.1:
>>   - "CAN" is not an RFC2119 term.  "CAN" -> "MAY"?
>>
>> Understood, we will work to change this
>>
>>
>>   - What is the scope of uniqueness for the id?  If it needs to be
>> global, then it needs a registry.  If it needs to be dCDN unique, then it
>> is just on the dCDN to ensure?
>>
>> This should be unique between the uCDN and dCDN
>>
>>
>>   - Are there limits related to maximum-hard, maximum-soft, and current?
>> Should those be specified along with the capacity limit types?  And what
>> happens if values are out of range?
>>
>> I am not sure we want to introduce an artificial cap outside of the
>> definition of the Integer itself as this will allow for the most
>> flexibility and hopefully prevent having to revisit the draft to increment
>> values in the future.
>>
>>
>>   - section 2.2.1 already defines a "Telemetry Source Object"; can we
>> come up with a different name to make it less confusing?
>>
>> @ben ^^
>>
>>
>>
>> section 2.2.1.1:
>>   - Should there be a registry for capacity limit types?  Will these be
>> globally unique and well specified (in an RFC?) for interoperability?
>>
>> I do believe this would make sense and part of the intention of defining
>> it in this draft was an attempt to address that.  If there is a more
>> appropriate way to accomplish this, I would welcome guidance.
>>
>>
>> section 2.2.1.2:
>>   - so, these are pointers back into a "Telemetry Source Object"?  What
>> happens if the reference is not found?
>>
>> @Ben we will need to discuss this case.  It might be enough to require
>> that dCDNs ensure consistency in this manner, and if not, the payload could
>> be rejected by the uCDN.
>>
>>
>>
>> section 2.2.1.3:
>>   - This is subdividing a footprint?  Would it make more sense (or at
>> least be simpler) to just define more granular footprints.  It seems
>> confusing to make essentially another way specify footprints.
>>
>> This was a very lengthy part of our discussion in this draft.  There are
>> use cases where "all traffic is not created equal" i.e Low Latency HLS will
>> have much different request characteristics than Bulk game downloads or
>> even Video On Demand.  The CDNi Footprint object doesn't allow for
>> granularity on a published host basis.  We were working under the
>> fundamental premise that we were trying to cause as little disruption to
>> the fundamental components of CDNi and trying to encapsulate as much as we
>> could related to capacity management without major overhauls to the
>> original spec.  We would greatly welcome discussion on this topic.
>>
>>
>>
>> section 4:
>>   - I think there should probably be discussions of the potential attacks
>> if the data is intercepted/spoofed.
>>
>> Would there be any additional considerations outside of what is already
>> established for FCI in general?
>>
>>
>>   - I think we also need a privacy section that discusses the potential
>> issues of divulging internal information about the CDN.
>>
>> part of the data requirements are such that the data for capacity is
>> scoped specifically to the uCDN,->dCDN delegation relationship..i.e. the
>> data is very narrowly scoped.  The data being presented is also data about
>> the dCDN by the dCDN.  Would there be any suggestions on how we might want
>> to frame a statement for this?
>>
>>
>> nits:
>>
>> section 1.3:
>>   "it's current usage" -> "its current usage"
>>   "uCDN of limits of" -> "uCDN limit on"
>>   ", so that the uCDN can use to" -> " so that the uCDN can use it to"
>>   " i.e. " -> ", i.e., "
>>   "In the event that a" -> "In the event a"
>>
>> ACK
>>
>>
>>
>> section 2.1:
>>   "CDNi" -> "CDNI"
>>   "reference, allows" -> "reference allows"
>>   "non ambiguous metric use use" -> "non ambiguous metric use be used"
>>   "current usage and how" -> "current usage.  How"
>>   "to it's dCDN" -> "to its dCDN"
>>
>> ack
>>
>>
>> section 2.1.1.2:
>>   " .  I.e. is" -> ", e.g., is"
>>   "5 minutes" -> "300 seconds (i.e., 5 minutes)"
>>   "one hour" -> "3600 seconds (i.e., one hour)"
>>
>>
>>
>> ack
>>
>>
>>
>> On Tue, Apr 5, 2022 at 9:08 AM Andrew Ryan <[e-mail]>
>> wrote:
>>
>>> Greetings,
>>>
>>>    Similar to the recent solicitation for adoption of the CDNI Metadata
>>> Model Extensions, I would like to submit a draft for consideration of
>>> adoption:
>>>
>>>
>>> https://datatracker.ietf.org/doc/draft-ryan-cdni-capacity-insights-extensions/
>>>
>>> The draft outlines extensions to the FCI payload registry, which will
>>> enable communication of Capacity/Delegation limits between a uCDN and
>>> dCDN.  This draft has been presented at IETF 111, IETF 112 and most
>>> recently at IETF 113  from which we have incorporated some great feed
>>> back into several revisions of the draft.
>>>
>>> I look forward to any feedback and/or support for the adoption of this
>>> draft.  Thank you very much for your time.
>>>
>>> Andrew Ryan
>>>
>>> _______________________________________________
>>> CDNi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/cdni
>>>
>>