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

["Mishra, Sanjay" <[e-mail]>]

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