Subject: RE: [Isms] Transport protocol discussion

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 2 Aug 2005 04:50:06 -0400

> Well, that's not datagram, that's record-oriented stream transport.
> The key difference being reliability and in-sequence delivery.
> One scenario where this is important is in real-time multimedia
> applications. If a packet gets lost, having it get retransmitted
> 500ms or 1s later doesn't do much good. What you *do* want is
> the next packet. But in reliable stream transport like TCP,
> packet n+1 can't be read until packet n is received.
>
> I'm not enough of an SNMP expert to say whether this is important
> in SNMP....

Normally, on a well-behaving network - this quality is not important to
SNMP, and SNMP can live OK with reliable transport underneath it. When a
network is in trouble - it is better not to depend on TCP reliability
and ordering qualities.

SNMP is supposed to work in both "good" and "troubled" networks. Thus
IMHO it is important for SNMP not to depend on packet N arrival.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 08:02:19 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blumenthal, Uri
> 
And I agree that this is an important consideration when a network is
broken, and for situations where you are trying to detect a broken
network, but probably 98% of SNMP usage occurs on non-broken networks,
where depending on packet N arrival is not a problem.

Having UDP transport available for heartbeat polling (polling for
sysuptime to make sure you get an answer), and to tweak a few
variables in a configuration is best done using UDP. To retrieve
routing tables and other large masses of SNMP data would be better
done over a streaming protocol like TCP.

This could have implications for future MIB module development, in
that it would be good to identify the use cases for the MIB module; if
it is expected that certain tables will get large, the MIB module
should describe that it is expected to be run over a TCP connection,
not a UDP connection, but the "lastChanged" timestamp for the table
can be polled effectively using UDP.

David Harrington
[email-masked]