I've taken your private note to me and gone to the list because I want to be sure people don't mistake my reasons for supporting SNMP over TCP, and to generate some discussion on this oh-so-quiet list.
You'll note that I didn't mention reliability at all in my reasoning for supporting TCP. I am a firm believer that reliability is not a significant benefit of moving from UDP to TCP.
My reasons for supporting SNMP over TCP (as a *supplement* to SNMP over UDP)?
First, I believe that SNMP would benefit from larger message sizes to transport table retrievals, and scripts, and other distributed management functionality, and in the future maybe object-oriented components or something. I believe that removing the UDP size constraints would enable SNMP to be used for more things, and in more innovative ways, than it can within the UDP size constraints.
Second, I think the SNMP authentication and access control models are made needlessly expensive by having to authenticate and apply access control to each of the small UDP-constrained packet sizes. By allowing much larger messages, the authentication and access control overhead can be spread (to a degree) across a whole session of back-to-back-to-back packets. Given the cost of security overhead, I believe one large TCP message will suffer less security overhead than many small UDP messages.
Third, there are a number of standardized security protocols that only work over TCP. SNMP cannot leverage the benefits of widely-deployed protocols like SSL. vendors cannot use their existing SSL implementation to support an SSL authentication model for SNMP. Even if the message sizes didn't change at all, I believe SNMP would benefit from the ability to utilize widely-deployed session-based security protocols in its security models. Being constrained to using UDP as a transport largely prevents, or at least complicates, leveraging those protocols.
Fourth, by constraining SNMP to use UDP for troubleshooting reasons, SNMP is prevented from integrating with a number of widely-deployed protocols/solutions like centralized AAA and key management. These have brought a great deal of benefit to companies, making it easier to maintain large networks through centralized management. SNMP cannot use any of this because of the "requirement" that all SNMP be able to be used for troubleshooting when a network is operating poorly. But most networks nowadays work fine most of the time. So why not expand SNMP to be able to offer useful services, and to integrate with other deployed services including off-box services, when the network is operating correctly? So part of my support is not really for TCP, it's for breaking out of this box we've built ourselves into to support troubleshooting. I believe SNMP can be used in both environments, and some mibs may need to be designed for use when a network is in trouble, while other mibs are expected to be useful only when the network is operating properly. I think we need to get past this barrier, and utilizing TCP would force a rethink of the broken-network constraint.
Those are my reasons.
> -----Original Message-----
> From: Keith McCloghrie [mailto:email@example.com]
> Sent: Thursday, August 22, 2002 9:43 AM
> To: Harrington, David
> Subject: Re: support for new work
> Dave, SNMP-over-TCP has almost zero benefit in terms of reliability.
> (If you don't believe me, see section 2.4 of
> including this paragraph:
> A reliable transport is thus only a poor approximation for
> operations. Applications that need confirmation of delivery or
> processing are encouraged to use the confirmed operations, such as
> the inform-request, rather than using unconfirmed
> operations, such as
> snmpV2-trap, over a reliable transport.
> The usefulness of TCP comes because of its adaptable
> retry-timer and its
> flow-control, which SNMP-over-UDP lacks. These are needed
> when there is a
> need to send many packets back-to-back-to-back. So, saying that "the
> TCP transport is by far the most important evolutionary
> advancement for
> SNMP" is equivalent to saying that you think the every SNMP manager
> needs to send back-to-back-to-back, which I find highly surprising.