[netconf] Re: [Tsv-art] UDP default port

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent, all.

Not an author (but I am involved with the implementation of the UDP Notif draft), one comment inline …


From: Kent Watsen <[e-mail]>
Date: Friday, 13 December 2024 at 16:41
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [netconf] Re: [Tsv-art] UDP default port

Hi Joe and UDP-Notif Authors,

It seems that this thread has stalled.  What can we do to move it forward?

Kent and Per // NETCONF chairs


A couple thought-provoking questions:

1.      What does "udp-notif" bring that isn’t supported by the "https-notif" draft, assuming the https-notif draft supports the QUIC transport?
2.      If the https-notif draft with QUIC transport is deemed unacceptable, would a "quic-notif” draft work?


PROs:

·         QUIC is well-defined (RFC 9000) and tooling should prominent.
·         HTTP/3 is well-defined (RFC 9114) and tooling should prominent.
·         QUIC supports reliability on a per frame-type basis, thus muxing both types is possible (see RFC 9221)
·         Stateful firewalls supporting QUIC will allow the return packets, thus enabling an “encoding-discovery” mechanism.
·         QUIC is still UDP, and so (I think) continues to support the properties desired by the “distributed-notify” draft.
·         Anything else?

CONs:

·         No ability to disable encryption (for “private” networks)
o    I don’t know how big of a problem this is.
o    Assuming long-lived connections, the overhead of the asymmetric key handshake is negligible.
o    The overhead for symmetric-key encryption (e.g., AES) is also pretty negligible
o    The “overhead” is mostly a concern on the receiver-side, as logging is a many-to-one activity, but it’s easy to scale receivers.
o    Encryption negates the ability to copy frames directly to persistent storage.  This is unlikely a good idea anymore, but ~20 years ago I designed the binary logging protocol such that the packets could be mmap-ed directly to disk, in their final storage format (note: a post-sweep would build indices).

·         Anything else?
Yes, it is not what the clients/servers are implementing. ;-)  I.e., the UDP notif draft ticks the running code box, but AFAIK nobody is yet implementing a QUIC based transport, although I understand that there is potentially interest in future.
Another key benefit of the UDP stack is that it is lightweight.  We implemented the core of it in a few weeks.  A QUIC implementation will take significantly more time and effort, or most likely we will try and find a suitable third-party library to leverage.
But ultimately, If the operators are saying that UDP fits their requirements, and the vendors are implementing then what is the stumbling block to publishing this?
Regards,
Rob


Kent / contributor