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

[Andy Bierman <[e-mail]>]

On Sat, Aug 5, 2023 at 2:49 AM Jürgen Schönwälder
<[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]>>
> > 收件人： Tianran Zhou<[e-mail]<mailto:[e-mail]>>
> > 抄送： Tschofenig, Hannes<[e-mail]<mailto:
> [e-mail]>>;netconf<[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]
> https://www.ietf.org/mailman/listinfo/netconf
>