Re: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription

[Qin Wu <[e-mail]>]

Hi, Zixiong:
Thank for your interests in this work and valuable review, please reply inline below.
>发件人: netconf [mailto:[e-mail]] 代表 Zhixiong Niu
>发送时间: 2022年2月6日 14:24
>收件人: [e-mail]
>主题: Re: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription

>Hi, folks

>Thanks for writing this draft and providing an extension to YANG push RFC. If my understanding is correct, the current YANG Push mechanism only allows you to select a fixed sampling rate. You may set the sampling rate too high, which the
>device cannot afford, or you may set the sampling rate too slow, which cannot capture enough data.

>One alternative solution is to use on change subscription, which has already been defined in RFC8641. However, if my understanding is correct, on change subscription is not suitable for data that changes frequently and consumes a
>tremendous amount of CPU resources device cannot afford as well.

>So the idea of this draft is to choose one compromised, or optimized solution that allows the device to switch sampling rate dynamically, but this also require the devices to be configured explicitly with multiple sampling intervals.

>I think this idea is similar to Microsoft adaptive sampling mechanism, although it doesn’t use the YANG model to define such a mechanism. I think the concept is similar.
[Qin Wu] Yes, Microsoft adaptive sampling in Azure is related (https://mailarchive.ietf.org/arch/msg/netconf/whMFjU6i8idoF3Q3AOvshCQkYog/) thanks for pointing this out.
The common goal is to reduce I/O contention and resource while maintain a certain level accuracy when facing massive data collection, currently we focus on how the data is reported in which time interval, instead of how the data is measured or sampled.
Routers and switches function as embedded monitoring probes and do not have enough computing power to monitor network traffic on high-speed links.  If every packet was captured and its statistic recorded, too much CPU power, cache memory and network bandwidth would be consumed in order to record, store and export data to the collector. Optimal packet sampling is a method that effectively reduces the measurement overhead in context of device’s resource usage and bandwidth consumption but at the cost of sacrificing some data accuracy.
>Therefore, I think this draft is a good starting point and could benefit to use Microsoft adaptive sampling as input, e.g., I am wondering whether this draft support configuration on packet sampling, e.g., minimum sampling percentage or
>maximum sampling percentage?
[Qin Wu] It is a good question, in the current draft, we right now more focus on using per packet monitoring and capture all the packets. But we could also consider time based sampling or counter based sampling if there is interests to do so and a clear use case, e.g., Microsoft Azure adaptive sampling use case.

>Section 2.1 last two bullets:
>What is the relationship between watermark and xpath-external-eval? It looks to me, xpath-external-eval has to be represented using watermark parameters which is a constant value and datastore node. Maybe a watermark parameter is
>not needed.
[Qin Wu] You are right, watermark parameter is part of xpath-external-eval. Take thermostat as an example,
“
module thermostat {
…
leaf actual-temp {
type int32;
config false;
units “degrees Celsius”;
description “The measured temperature”;
}
}
”
You might need to measure actual temp and but you also want to control actual-temperature not greater than a preconfigured threshold, e.g, actual-temp<80,  in this case, 80 is the preconfigured threshold or watermarks.
If you want to control actual-temperature not less than a preconfigured threshold B, e.g., actual-temp>10, in this case, 10 is another watermarks or preconfigured threshold.
So you are right, the waterwark  taken out from xpath-external-eval, in some cases, it is not required.
>Nevertheless, I do not have a strong opinion about this.

>--
>Best,
>Zhixiong

发件人： Mahesh Jethanandani<[e-mail]<mailto:[e-mail]>>
收件人： Netconf<[e-mail]<mailto:[e-mail]>>
抄送： draft-wang-netconf-adaptive-subscription<[e-mail]<mailto:[e-mail]>>
主题： Re: [netconf] Adoption call for draft-wang-netconf-adaptive-subscription
时间： 2022-01-25 06:19:39

We have received a tepid response to this adoption call, and are therefore extending this adoption call by another two weeks to February 7. At that time, and unless we receive any objections, we are going to go ahead and adopt this draft.

We are aware of least two implementations of YANG Push, and this draft is an extension of that work.

Cheers

On Jan 10, 2022, at 2:07 PM, Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>> wrote:

Hi WG,

The authors posted -08 version of the draft just before the new year, which addressed the comments they received in IETF 112.

 https://www.ietf.org/archive/id/draft-wang-netconf-adaptive-subscription-08.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-netconf-adaptive-subscription-08.txt&data=04%7C01%7CZhixiong.Niu%40microsoft.com%7Cd2c1ad3002f6435db18f08d9e932f3df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797227984116232%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=COTDhD5eRLCOPwjBwKZqbsg6RPiR8ihr69QZ2sv5Q60%3D&reserved=0>

This starts a 2 week poll ending on January 24, to decide whether this document should be made a WG document or not. Please reply to this email whether or not you support adoption of this draft by the WG. Indications that the draft has been read will be also be appreciated. The Intended Status of the draft is Standards Track.

A separate IPR call will be issued on the draft.

Thanks.


Mahesh and Kent (as co-chairs)