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

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

Well, I asked a bunch of questions...

/js

On Sun, Aug 06, 2023 at 02:36:50AM +0000, Tianran Zhou wrote:
> Hi Jurgen,
> 
> IMO, your suggestion makes sense.
> 
> Best,
> Tianran
> 
> -----邮件原件-----
> 发件人: Jürgen Schönwälder <[e-mail]> 
> 发送时间: 2023年8月5日 17:49
> 收件人: Tianran Zhou <[e-mail]>
> 抄送: netconf <[e-mail]>
> 主题: Re: [netconf] draft-ietf-netconf-udp-notif-10
> 
> 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:jschoenwaelde
> > [e-mail]>>
> > 收件人： Tianran 
> > Zhou<[e-mail]<mailto:[e-mail]>>
> > 抄送： Tschofenig, 
> > Hannes<[e-mail]<mailto:hannes.tschofenig@siemens.
> > com>>;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/>
> 

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