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

[Jürgen Schönwälder <[e-mail]>]

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?

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

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/>