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

Hi Thomas,

I have no problem with your choice of two transports. I was reading the draft trying to understand what was written.

When packet loss is neglectable and payload sizes are small then everything is fine -- even with UDP.
If this is not the case then there is a problem. The document needs to say that.

If you expect to send large volumes of data without flow and congestion control I fear you will see a lot of incomplete messages arriving at the receiver. You will be unhappy.

Once you use fragmentation you will have to maintain state since otherwise you cannot put the sent message together. 
Once you use security you will also have to maintain state. 

Thanks for the pointers to the implementations. Will try them. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: netconf <netconf-bounces@ietf.org> Im Auftrag von
> Thomas.Graf@swisscom.com
> Gesendet: Montag, 7. August 2023 10:51
> An: benoit.claise=40huawei.com@dmarc.ietf.org; zhoutianran@huawei.com;
> netconf@ietf.org; jschoenwaelder@constructor.university
> Betreff: Re: [netconf] draft-ietf-netconf-udp-notif-10
> 
> 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