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

[Benoit Claise <[e-mail]>]

Hi,


On 12/17/2024 3:44 PM, Rob Wilton (rwilton) wrote:
>
> 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)
>
> oI don’t know how big of a problem this is.
>
> oAssuming long-lived connections, the overhead of the asymmetric key 
> handshake is negligible.
>
> oThe overhead for symmetric-key encryption (e.g., AES) is also pretty 
> negligible
>
> oThe “overhead” is mostly a concern on the receiver-side, as logging 
> is a many-to-one activity, but it’s easy to scale receivers.
>
> oEncryption 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?
>
What Rob said.
IPFIX has been proving that UDP works and scales in production now.

Regards, Benoit
>
> Regards,
> Rob
>
> Kent / contributor
>
>
> _______________________________________________
> netconf mailing list [e-mail]
> To unsubscribe send an email [e-mail]