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

[Kevin Ma <[e-mail]>]

Hi Andrew,

  I wanted to restart the Capacity Limit Scope Object discussion.  If I
understand correctly, you want to associate capacity more virtually with a
specific host (in the Metadata interface HostMatch sense) and possibly with
a specific path (in the Metadata interface PathMatch sense), as opposed to
a Footprint which is more of a physical association?  Could we tie it back
to the Metadata configuration?  Having something generic/opaque makes me
uncomfortable.  Would a reference back to a Metadata interface
HostMatch/PathMatch object work, or even to a specific Generic Metadata
object?

thanx!

--  Kevin J. Ma


On Fri, Jul 29, 2022 at 11:09 AM Kevin Ma <[e-mail]> wrote:

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