RE: support for new work

Hi Keith,

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.

dbh

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email protected]]
> 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 
> draft-irtf-nmrg-snmp-tcp-09.txt,
> including this paragraph:
> 
>    A reliable transport is thus only a poor approximation for 
> confirmed
>    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.
> 
> Keith.
>