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

[Tianran Zhou <[e-mail]>]

Hi Andy,

Thanks for your thoughts. I really agree with you.

>Perhaps the scope of the draft should be narrowed so it is only intended to
YANG Push or server events that do not need reliable delivery.

Yes, this is our initial thoughts. I think we can clarify it explicitly in the document.

Cheers,
Tianran


发件人: Andy Bierman <[e-mail]>
发送时间: 2023年8月5日 23:44
收件人: Jürgen Schönwälder <[e-mail]>; Tianran Zhou <[e-mail]>; netconf <[e-mail]>
主题: Re: [netconf] draft-ietf-netconf-udp-notif-10



On Sat, Aug 5, 2023 at 2:49 AM Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>> 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?
If you worry about CPU efficiency, the first things to consider is
likely using a binary encoding. Or is the argument that linecards
still can't do TCP in 2023 and 'performce' means code size on
linecards, saving TCP but instead implementing ad-hoc fragmentations
in application-layer transports?

The big question: Is it OK to accept non-reliability for the notifications?
It depends on the notification content.

Configured subscriptions using UDP allow "SNMP style" collectors:
- This is a very real advantage over dynamic subscriptions.
- This is easier to implement with UDP than TCP.
- This avoids CallHome issues since no need for the collector to connect to the publisher at all

IMO the old SNMP design of needing to know the MTU and needing to hand-craft TRAPs
that fit within the MTU is truly awful, and now that we have streaming servers that rely
on chunking in the application protocol, we should not go backwards.

The UDP draft design supports a streaming server (the 'L' bit in sec. 4.1).
It is easy to identify the last buffer being sent.

The number of segments is likely to be 1 - 5 for a given push update report.
There are times when a full report is sent and this could be a lot of segments.
These are also the exact updates that the application cannot really ignore if lost.

The UDP draft is designed for hand-crafted, small 'push updates'.
However the scope is for all notifications, not just push updates.
In general, notification events are the least likely to be OK to ignore if lost.

Perhaps the scope of the draft should be narrowed so it is only intended to
YANG Push or server events that do not need reliable delivery.






UDP works great for small self-contained messages (and with small I
mean something up to the size of a typical MTU). For everything
requiring larger messages, you will have to invent a fragmentation and
reassembly logic that may at the end be in the same ballpark as a
light-weight TCP implementation.

Has this work ever been received review by transport area people?

To answer your question, there likely should be a 'do not use this'
recommendation unless you have full control of all components involved
(i.e., inside a box where the frontend NC/RC agent can ensure that
requests from the outside are mapped to internal communication flows
that stay within the operational limits of this transport).

/js


Andy

On Sat, Aug 05, 2023 at 09:21:45AM +0000, Tianran Zhou wrote:
> Hi Juergen,
>
> What’s your suggestion here?
> How about describing this as operational considerations?
>
> Cheers,
> Tianran
>
>
>
> ________________________________
>
> Sent from WeLink
> 发件人： Jürgen Schönwälder<[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>
> 收件人： Tianran Zhou<[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
> 抄送： Tschofenig, Hannes<[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>;netconf<[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
> 主题： Re: [netconf] draft-ietf-netconf-udp-notif-10
> 时间： 2023-08-05 14:49:42
>
> On Sat, Aug 05, 2023 at 06:26:50AM +0000, Tianran Zhou wrote:
> >
> > Of course, with so many fragments the probability of discarding the entire message due to the lost of one or more UDP packets is large even if the probability of loss of an individual datagram is very small. I hope you are not going to need so many fragments in a practical application.
> >
> > ZTR> I understand your point. I agree in a practical application, too large msg should not be encouraged. But the size of the message is requested by the users. Fragmentation will not introduce more loss itself. It just provide the possibility that user can request larger message.
> >
>
> If the probability of loosing a UDP datagram is 0.1% and you need
> 100 UDP datagrams to send a larger NETCONF message, then the loss
> probability for the NETCONF message is close to 10%. Yes, your
> fragmentation scheme does not change the loss probability of UDP
> datagrams but the fact that all datagrams need to arrive correctly
> in order to deliver the NETCONF message causes the loss probability
> of NETCONF messages to go up quickly as the number of fragments
> increases. The question is whether 'the requesting users' (who is
> that?) can be assumed to understand the details and that there is
> somewhere (internal?) a UDP transport involved that has possible
> message size sclability problems.
>
> /js
>
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://constructor.university/>
>

--
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://constructor.university/>

_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf