Re: [netconf] draft-ietf-netconf-udp-notif-10

Hi Jürgen,

Let me follow up on Tianran answer.

I think Thomas Graf has already shown why a non-reliable solution for monitoring is also needed for operators but let me add the following.

Currently, there are two transport protocols defined at the IETF for YANG-push configured subscriptions: HTTPS-notif and UDP-notif.
Both transport protocols are useful and have different usecases. 
For state-change notifications that need to be reliable, HTTPS-notif should be used.
On the other hand, for periodical notifications where the node exports counters for example, losing a packet is still tolerable and using UDP-notif allows the collector to avoid the burden of dealing with great amount of transport sessions.

Within the draft, when the authors speak about performance, we refer to both the exporter process (to avoid dealing with the transport session within the line card), and to the collector (avoid managing great amount of transport sessions between the collector and the multiple exporters). 
We did at INSA Lyon, long time ago, a performance test between both transports protocols (HTTPS-notif vs UDP-notif), and UDP-notif could manage more throughput and more messages with a single collector process.
Something we realised during our tests is that in Linux, when the packet passes the MTU and it fragments at IP level, the performance drops greatly (in terms of throughput and amount of messages we can deal with).

Please also note that even if the segmentation is specified within the draft, small messages are still preferred to avoid using the segmentation. I believe CBOR can help in reducing the size of the message.

Cheers,
Alex

> On 7 Aug 2023, at 10:50, <Thomas.Graf@swisscom.com> <Thomas.Graf@swisscom.com> wrote:
> 
> Dear Jürgen,
> 
> Following up on Tianran's and Benoit's comments. 
> 
> The reason why I am co-authoring and supporting draft-ietf-netconf-udp-notif and draft-ietf-netconf-distributed-notif because it is important that a network operator has the choice between two transport protocols for YANG push. One, draft-ietf-netconf-https-notif, which maintains states between YANG push publisher and receiver, and draft-ietf-netconf-udp-notif which doesn't require to maintain states. It should be the operators choice to chose which of the transport protocols make most sense for which type of metrics. Speaking for Swisscom, accounting metrics should be sent without states, directly from network processors on line cards, where re-transmitting packets are not feasible and at YANG push receiver. Where state changes, should be sent through a transport protocol which maintains states and re-transmission is supported and can be sent from the route processor. It is desirable to have minimal interaction between Network Telemetry data collection and the network node exporting the metrics, in particular when load is distributed among multiple YANG push receiver daemons in a redundant fashion.
> 
> I believe in running code. draft-ietf-netconf-udp-notif and draft-ietf-netconf-distributed-notif describe both an implementation status section where open-source code is linked. For https-notif we published a YANG push publisher https://github.com/network-analytics/https-notif-c-publisher and YANG push receiver https://github.com/network-analytics/https-notif-c-collector as well. Udp-notif has been integrated into the pmacct Network Telemetry open-source project.
> 
> I confirm that CBOR will be a further important step to make YANG push equally scalable and efficient than the other Network Telemetry protocols in use. I am looking forward to contribute to the netconf working group.
> 
> Best wishes
> Thomas
> 
> -----Original Message-----
> From: netconf <netconf-bounces@ietf.org> On Behalf Of Benoit Claise
> Sent: Monday, August 7, 2023 9:17 AM
> To: Tianran Zhou <zhoutianran@huawei.com>; netconf <netconf@ietf.org>
> Subject: Re: [netconf] draft-ietf-netconf-udp-notif-10
> 
> Dear all,
> 
> On 8/7/2023 8:55 AM, Jürgen Schönwälder wrote:
>> On Mon, Aug 07, 2023 at 06:34:36AM +0000, Tianran Zhou wrote:
>>>> The abstract says:
>>>> 
>>>>    The objective is to provide a lightweight approach to enable higher
>>>>    frequency and less performance impact on publisher and receiver
>>>>    processes compared to already established notification mechanisms.
>>>> 
>>>> It is not clear what 'performance impact' means here. Anyway, is there a proof that this design accomplishes the objective and how much is the gain over a transport that does segmentation properly, e.g., TCP?
>>> ZTR> There is no such proof from my side. I am not sure if there is any from coauthors.
>>> 
>> It would help to demonstrate that the design achieves the stated 
>> goals... This will likely make you think more clearly what you mean 
>> with 'less performance impact on publisher and receiver processes' and 
>> how much the gain is over 'established notification mechanisms'.
>> 
> There is a reason why NetFlow was exported over UDP and why IPFIX is still exported over UDP (independently of what the IPFIX RFC mandates).
> 
> Regards, Benoit
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf