Subject: [Tsvwg] Discontinuity timer for TCP-MIB counters

From: Rajiv Raghunarayan <[email-masked]>
Date: Thu, 05 Feb 2004 18:58:02 -0800

Hi Folks,

This point came out of the IESG review of the TCP-MIB, and possibly
requires wider discussion. Hence this mail to all the aliases.

The current update to TCP-MIB (draft-ietf-ipv6-rfc2012-update-05.txt)
does not define any special discontinuity objects, for a case
when the counters in the mib experience a discontinuity. There is
an implicit assumption that this would be represented by sysUpTime
(SNMPv2-MIB).

The IESG review suggested that we provide a discontinuity timer
for the counters in the mib - could be via sysUpTime or a new
discontinuity object. But we state it either way. There are issues
to going either way:

1. sysUpTime: If any Counter, that uses sysUpTime as the
    discontinuity indicator, experiences a discontinuity, then
    it must reset sysUpTime (basically means a warm (re-)start).
    Therefore, all *other* counters that also use sysUpTime are
    going to look and be treated as if they also had a discontinuity.
    This may have performance implications, in terms of network
    management stations generating additional queries for these
    (unaffected) counters as well.

2. Add a new object for indicate discontinuity: This would
    necessitate adding a new (perhaps) unnecessary object, if
    sysUpTime can serve the purpose. In addition, systems would
    have an additional overhead of maintaining this information.

Hence the question to folks here is:

1. Are there any known systems that can experience a discontinuity
    in the TCP counters without affecting the network management
    portion of the system. For e.g. are there systems that can
    restart the TCP portion of the system without restarting the
    network management portion of the system (or the whole system)?

2. Does anyone see any other case in which we might need to/want to
    maintain a discontinuity timer in the TCP-MIB?

My assumption is that there might not be any systems that need an
explicit discontinuity timer (but I could be wrong). Hence, would
appreciate responses.

Thanks,
Rajiv.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Feb 2004 09:55:01 +0100

>>>>> Rajiv Raghunarayan writes:

Rajiv> The IESG review suggested that we provide a discontinuity timer
Rajiv> for the counters in the mib - could be via sysUpTime or a new
Rajiv> discontinuity object. But we state it either way. 

Here are my 3 thoughs on this:

1) So far, sysUpTime has been used by the existing TCP-MIB objects.
   Introducing a new discontinuity indicator now raises the question
   whether doing so breaks existing implementations.

2) Personally, I doubt that there will be many implementations where
   TCP can experience discontinuities that do not also affect other
   parts of the networking stack or the whole system.

3) I do see the problem that sysUpTime might be more frequently reset
   as we like due to some other MIBs which do not use explicit
   discontinuity indicators and experience more frequent
   resets. However, the root of the problem is then really in those
   MIBs, not in the TCP-MIB. (Sure, by introducing a discontinuity
   indicator for the TCP-MIB we can protect against other misbehaving
   MIBs - but is this going to set a precedence which at the end
   requires a CLR that better every MIB module has at least one,
   perhaps multiple discontinuity indicators?)

In the case of the TCP-MIB, I believe 1) is the killing argument. To
introduce a new discontinuity indicator changes the implicit semantics
of existing objects and would require to introduce new objects, which
I think is prohibitive.

Conclusion: Spell out that sysUpTime is used as a discontinuity
indicator for the counters.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Sun, 08 Feb 2004 14:18:24 -0800

Hi Juergen,

Thanks for the feedback. My comments inline.

>    whether doing so breaks existing implementations.

Yep. It would probably break implementations if 2) were to be an
incorrect assumption for any implementation. Else, I think we
shouldn't be affecting other implementations (but those case wouldn't
need a separate discontinuity indicator as well!)?

>    parts of the networking stack or the whole system.

I suspected that, but wasn't sure.

>    perhaps multiple discontinuity indicators?)

Agreed.

> indicator for the counters.

I've modified the mib to indicate it - will submit the mib, if I do
not receive any arguments to the contrary in the next couple of days.

Thanks,
Rajiv.