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

[Kevin Ma <[e-mail]>]

Agreed.  Looking forward to seeing/discussing the proposal

thanx!

--  Kevin J. Ma

On Fri, Nov 11, 2022 at 10:47 AM Mishra, Sanjay <[e-mail]>
wrote:

> Hi Andy, Ben - Looping in @Nir Sopher <[e-mail]> here and I do
> agree that footprint draft/rfc would be a good way forward.
>
> Thanks
> Sanjay
>
> On Fri, Nov 11, 2022 at 1:16 PM Andrew Ryan <[e-mail]>
> wrote:
>
>> Wanted to pull in some of the discussion we had during the IETF115 CDNi
>> session related to this.
>>
>> There seemed to be a general consensus surrounding the topic of the scope
>> object within the FCI.CapacityLimits payload would most likely be better
>> addressed with the ability to define these more granular elements
>> (published host, path,etc.) into the footprint itself rather than the FCI
>> payload.
>>
>> This is great feedback and seems like a great way to address some of the
>> use cases we were hoping to address with the scope object within the
>> FCI.CapacityLimits object itself.
>>
>> There will be some work to do in terms of coming up with a proposal on
>> how best to accomplish this within the footprint, but this seems like the
>> best path forward.
>>
>> Andrew
>> On 11/11/2022 7:01 AM, Andrew Ryan wrote:
>>
>> Kevin,
>>
>>   Correct, in this sense serviceA.cdn.example.com is the "host" in the
>> metadata sense.  If I understand what you are proposing is that we would
>> want to essentially reference and/or reuse the same construct that the
>> configuration API uses?
>>
>>  At a high level, that would probably be ideal, since one of the concepts
>> were were looking to leverage is that the dCDN would become aware of the
>> hostname during the provisioning process (config API) and there would be a
>> "service type" associated at that time, which would somewhat define what
>> type of traffic this is.  This would be the indicator to the underlying
>> system providing the data for the capacity limits.    Having a way to use a
>> one to one mapping of what was referenced/defined in the configuration api
>> in the capacitylimits FCI payload would probably remove any ambiguity.
>>
>> There are some considerations surrounding the fact that footprints don't
>> cleanly align with configuration especially when you consider redirection
>> models (especially DNS since ).
>> On 11/10/2022 11:48 PM, Kevin Ma wrote:
>>
>> Hi Andrew,
>>
>>   Thanks for the clarification.  If I look at this example:
>>
>>    - traffic within 10.0.10/24 must stay under 20000000000 as per
>>    capacity_metrics_region2
>>    - traffic for serviceA.cdn.example.com
>>    <https://urldefense.proofpoint.com/v2/url?u=http-3A__serviceA.cdn.example.com&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=IYjzPAxcnu39YTSG1L_qPPE-asWz-5QGKI5fwK9uS7k&e=>
>>     within 10.0.0.0/8
>>    <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.0_8&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=Qh1xhqJcuZCpva8KsJHoi9GuqlTUT6fRIZuKv-wlYfw&e=> must
>>    stay under 30000000000 as per capacity_metrics_serviceA_region1
>>
>>   "serviceA.cdn.example.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__serviceA.cdn.example.com&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=IYjzPAxcnu39YTSG1L_qPPE-asWz-5QGKI5fwK9uS7k&e=>"
>> is the "host" in the CDNI Metadata sense (i.e.,
>> https://www.rfc-editor.org/rfc/rfc8006.html#section-4.1.2
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc8006.html-23section-2D4.1.2&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=acmRdZcFokL7JYi4UvSuuCt4GSd_MoD1hSCyy9-igXQ&e=>)
>> and can be extended with a "path-pattern" in the CDNI Metadata sense (i.e.,
>> https://www.rfc-editor.org/rfc/rfc8006.html#section-4.1.4
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc8006.html-23section-2D4.1.4&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=o2HHxYF5smAui5LE1LM7DpK9l0KmKB33otrPf-7aHiU&e=>),
>> e.g., "serviceA.cdn.example.com/hls
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__serviceA.cdn.example.com_hls&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=1IEqFTQQB1tzpRZC8BdQ9BhwXyjhs-axO7a2nXDgxPk&e=>".
>> It just feels to me like we already have a construct for this, and perhaps
>> just need a better surfacing of it.  Would you agree that "host" or
>> "host+path-pattern" (on top of existing footprints) meet your
>> requirements?  If so, we can figure out a good way to use them.  If not,
>> then I still may be misunderstanding the use case.
>>
>> thanx!
>>
>> --  Kevin J. Ma
>>
>>
>> On Wed, Nov 9, 2022 at 5:05 PM Andrew Ryan <[e-mail]>
>> wrote:
>>
>>> Kevin,
>>>
>>>   Apologies for the delayed response.
>>>
>>> The use case for the sub-scoping is as follows:  How could we define a
>>> limit specific to the type of traffic being delegated.  The type of traffic
>>> being delegated is a more granular component of the Footprint in which it
>>> would be associated with.
>>>
>>> My current understanding of the Footprints (there seems like there is
>>> some active discussion on this topic which I have yet to catch up with) is
>>> that these are associated with geoIP and/or network locations.  At this
>>> level, we would be dealing with a limit which is only defined by the user's
>>> location.  Some use cases were brought up surrounding the idea that "not
>>> all traffic is created equal". Example; game download traffic might be high
>>> bps low rps, where as Low Latency HLS could be high rps and high bps.
>>> These different traffic profiles could have different impact on the
>>> underlying CDN and therefore we wanted to allow for some additional
>>> granularity which would leverage an association of traffic type with the
>>> delivery host (or an identifier which maps to a configuration)
>>>
>>> The idea behind this is that the footprint provides the
>>> geographical/network boundary, which is consistent with FCI, but within the
>>> CapacityLimits FCI payload, we would leverage a scope object which would
>>> further define the limit to apply to not only the footprint but also this
>>> additional scope-type.
>>>
>>> The following was an example that was put together to highlight how this
>>> might be used in practive
>>> {
>>>   "capabilities":[
>>>     {
>>>       "capability-type":"FCI.CapacityLimits",
>>>       "capability-value":{
>>>           "limits":[
>>>           {
>>>             "id":"capacity_limit_region1",
>>>             "limit-type":"egress",
>>>             "maximum-hard":50000000000,
>>>             "maximum-soft":40000000000,
>>>             "telemetry-source":{
>>>               "id":"capacity_metrics_region1",
>>>                 "metric":"egress_5m"
>>>             }
>>>           },
>>>           {
>>>             "id":"capacity_limit_serviceA_region1",
>>>             "scope":{
>>>                 "type":"published-host",
>>>                 "values":[
>>>                 "serviceA.cdn.example.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__serviceA.cdn.example.com&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=IYjzPAxcnu39YTSG1L_qPPE-asWz-5QGKI5fwK9uS7k&e=>
>>> "
>>>                 ]
>>>             },
>>>             "limit-type":"egress",
>>>             "maximum-hard":30000000000,
>>>             "maximum-soft":20000000000,
>>>             "telemetry-source":{
>>>                 "id":"capacity_metrics_serviceA_region1",
>>>                 "metric":"egress_5m"
>>>             }
>>>           }
>>>           ]
>>>       },
>>>       "footprints":[
>>>           {
>>>           "footprint-type": "ipv4cidr",
>>>           "footprint-value": ["10.0.0.0/8
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.0_8&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=Qh1xhqJcuZCpva8KsJHoi9GuqlTUT6fRIZuKv-wlYfw&e=>
>>> "]
>>>           }
>>>       ]
>>>     },
>>>     {
>>>       "capability-type":"FCI.CapacityLimits",
>>>       "capability-value":{
>>>         "limits":[
>>>         {
>>>           "id":"capacity_limit_region2",
>>>           "limit-type":"egress",
>>>           "maximum-hard":20000000000,
>>>           "maximum-soft":10000000000,
>>>           "telemetry-source":{
>>>             "id":"capacity_metrics_region2",
>>>               "metric":"egress_5m"
>>>           }
>>>          }
>>>           ]
>>>       },
>>>       "footprints":[
>>>           {
>>>           "footprint-type": "ipv4cidr",
>>>           "footprint-value": ["10.0.10.0/24
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.10.0_24&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=ZJ8jzzWXFQtDEDgD8ZDURKizCAGZ809VcmeRNTEepXo&e=>
>>> "]
>>>           }
>>>       ]
>>>     }
>>>   ]
>>> }
>>>
>>>
>>>
>>> The following is a summary of what the FCI.CapacityLimits payload
>>> specifies represented in a hierarchical manner of the IPv4 CIDR ranges.
>>>
>>>    - 10.0.0.0/8
>>>    <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.0_8&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=Qh1xhqJcuZCpva8KsJHoi9GuqlTUT6fRIZuKv-wlYfw&e=>
>>>       - ALL traffic <= 50000000000
>>>       - serviceA.cdn.example.com
>>>       <https://urldefense.proofpoint.com/v2/url?u=http-3A__serviceA.cdn.example.com&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=IYjzPAxcnu39YTSG1L_qPPE-asWz-5QGKI5fwK9uS7k&e=>
>>>       <= 30000000000
>>>    - 10.0.10/24
>>>       - ALL traffic <= 20000000000
>>>
>>>
>>> In a scenario a uCDN is considering how to delegate traffic for
>>> serviceA.cdn.example.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__serviceA.cdn.example.com&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=IYjzPAxcnu39YTSG1L_qPPE-asWz-5QGKI5fwK9uS7k&e=>
>>> towards 10.0.10/24,   the following conditions need to be met:
>>>
>>>    - traffic within 10.0.10/24 must stay under 20000000000 as per
>>>    capacity_metrics_region2
>>>    - traffic for serviceA.cdn.example.com
>>>    <https://urldefense.proofpoint.com/v2/url?u=http-3A__serviceA.cdn.example.com&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=IYjzPAxcnu39YTSG1L_qPPE-asWz-5QGKI5fwK9uS7k&e=>
>>>    within 10.0.0.0/8
>>>    <https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.0_8&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=Qh1xhqJcuZCpva8KsJHoi9GuqlTUT6fRIZuKv-wlYfw&e=>
>>>    must stay under 30000000000 as per capacity_metrics_serviceA_region1
>>>
>>>
>>> Ideally, the scoping would be fully contained within the Footprint
>>> object but in lieu of that, we implemented sub-scope specific to the
>>> CapacityLimits object
>>>
>>> This will likely be a good topic for discussion during IETF115.  We
>>> welcome any feedback on the topic.  Thanks!
>>>
>>> Andrew
>>> On 10/23/2022 11:27 PM, Kevin Ma wrote:
>>>
>>> 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
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dcdni-2Dmetadata-2D21-23section-2D7.2&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=vhzqq7JbWYhvpeODxIT_MTiSMGYNtdoTarH5FW81E4c&e=>
>>>>
>>>> > ... 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
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__live.example.com&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=4OYRGQAHEKkznvyHqpXv1XDtLMSPJtANO52HtXqk7T0&e=>,
>>>>> vod.example.com
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__vod.example.com&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=pIzoAK_O-5x2Zcczxf27DnQPU0v7A4xAnW_sPcrUv0Y&e=>,
>>>>> 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
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.example.com_live&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=4Z1Oy8aAQVFmJ-lRU-THsgy7TojJzbU6Yw3I1T672Wg&e=>,
>>>>> www.example.com/vod
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.example.com_vod&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=f9y7FT16laKmgIhXBB_Ov7xPjnfm3pcnmRRZAFRYF8o&e=>).
>>>>> 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
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__2.1.1.1&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=REiaOul2DNDOVtZ5F9SESgoYec766vwechWJ-Wg-Ado&e=>
>>>>>> :
>>>>>>   - 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
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__2.1.1.2&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=vy73u432xiIWhEg5D4wfCB0l6bQFVjxlfmLEoguiOpI&e=>
>>>>>> :
>>>>>>   - 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
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__2.2.1.1&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=bluva75ALyA5rNYKXfqiYllCaSzXlpwlic99nUCufWs&e=>
>>>>>> :
>>>>>>   - 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
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__2.2.1.2&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=m1F4vvgLCmCO9AchaIziimrSMG30rWyG32ZywEOY_jM&e=>
>>>>>> :
>>>>>>   - 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
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__2.2.1.3&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=Haxx4yLsIkeggbzCcIgPSAbTKPRRsCEE-5fcuXyScN4&e=>
>>>>>> :
>>>>>>   - 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
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__2.1.1.2&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=vy73u432xiIWhEg5D4wfCB0l6bQFVjxlfmLEoguiOpI&e=>
>>>>>> :
>>>>>>   " .  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/
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dryan-2Dcdni-2Dcapacity-2Dinsights-2Dextensions_&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=3fVcDpwTtVAKp0Rh5-56SZUtJHIKX1abnUx4d-ADC6k&e=>
>>>>>>>
>>>>>>> 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
>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwMDaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=p0KOmZ6wOPF25Psz3uC12NBmxMRl5ih559dj29LFehF_-FWgOwLPxzKIxsjHObr0&s=8Jhgxw2axxP-k--ArMlJRkNvAw5ApMQ4mEUxJUPwv9A&e=>
>>>>>>>
>>>>>>