Subject: [MIB-DOCTORS] (no) discontinuity timer in UDPLITE-MIB

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Oct 2007 15:36:37 +0200

The UDPLITE-MIB
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udplite-mib-02.txt
in review this week at the IESG telechat has the following sentence in
the DESCRIPTION object of its counters:

> Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other times as
indicated by discontinuities in the value of sysUpTime.

This sentence is taken from the UDP MIB (RFC 4113) from which this work
is largely inspired. Yet I am inclined to push back and ask for the
inclusion of a discontinuity object as required by 4181 and 2578. I
believe that overloading sysUpTime with semantics of 'at other times'
cases of discontinuity from counters of different MIB modules is a
dangerous practice. While in the case of the UDP MIB assuming sysUpTime
should reflect a discontinuity of a UDP counter because it's part of the
original IP stack (and MIB I / MIB II implementation) for other
protocols I believe separate discontinuity indicators is better. 

Any other opinions? 

Dan

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Wed, 17 Oct 2007 16:42:25 +0200

Dan, for what it is worth, I for one support and agree with 
your position here.

Bert Wijnen  

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Wednesday, October 17, 2007 3:37 PM
> To: [email-masked]
> Subject: [MIB-DOCTORS] (no) discontinuity timer in UDPLITE-MIB
> 
> The UDPLITE-MIB
> in review this week at the IESG telechat has the following 
> sentence in the DESCRIPTION object of its counters:
> 
> re-initialization of the management system, and at other 
> times as indicated by discontinuities in the value of sysUpTime.
> 
> This sentence is taken from the UDP MIB (RFC 4113) from which 
> this work is largely inspired. Yet I am inclined to push back 
> and ask for the inclusion of a discontinuity object as 
> required by 4181 and 2578. I believe that overloading 
> sysUpTime with semantics of 'at other times'
> cases of discontinuity from counters of different MIB modules 
> is a dangerous practice. While in the case of the UDP MIB 
> assuming sysUpTime should reflect a discontinuity of a UDP 
> counter because it's part of the original IP stack (and MIB I 
> / MIB II implementation) for other protocols I believe 
> separate discontinuity indicators is better. 
> 
> Any other opinions? 
> 
> Dan
> 
>  
> 
>

---

From: Dave Thaler <[email-masked]>
Date: Wed, 17 Oct 2007 09:10:36 -0700

I know the stance the authors have taken is to not fix any problem
which also exists in the UDP MIB.  For example, the process object
is known to be problematic, and the authors chose to repeat the
same problems as in the UDP MIB, with the expectation that
both would be fixed by a subsequent MIB.

This seems like it fits into the same category.  Pushing on
one problem without pushing on all known problems seems
inconsistent to me.  So either don't push (accept the authors'
position that a new MIB is needed in the future), or push on
both issues would be my recommendation.

-Dave

> Sent: Wednesday, October 17, 2007 6:37 AM
> To: [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Oct 2007 18:23:12 +0200

The difference is that this is not a problem that exists in the UDP MIB.
In the UDP MIB I think that the approach is acceptable, especially as
this is derived from an original MIB I / MIB II MIB group. Overloading
sysUpTime semantics further is not. This MIB module is according to the
authors supposed to work on high speed links (they gave up counter32
objects) and for each packet they need to compute checksum and count
checksum errors - so it may be very possible that the implementation is
on a separate module, maybe hardware. Zeroing sysUpTime each time such a
counter on that module runs into a discontinuity is not a good thing. 

Dan

> From: Dave Thaler [mailto:[email-masked]] 
> Sent: Wednesday, October 17, 2007 6:11 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: (no) discontinuity timer in UDPLITE-MIB
> 
> I know the stance the authors have taken is to not fix any 
> problem which also exists in the UDP MIB.  For example, the 
> process object is known to be problematic, and the authors 
> chose to repeat the same problems as in the UDP MIB, with the 
> expectation that both would be fixed by a subsequent MIB.
> 
> > This sentence is taken from the UDP MIB (RFC 4113) from which this 
> > work is largely inspired. Yet I am inclined to push back 
> and ask for 
> > the inclusion of a discontinuity object as required by 4181 
> and 2578. 
> > I believe that overloading sysUpTime with semantics of 'at other 
> > times'
> > dangerous practice. While in the case of the UDP MIB assuming 
> > sysUpTime should reflect a discontinuity of a UDP counter 
> because it's 
> > part of the original IP stack (and MIB I / MIB II 
> implementation) for 
> > other protocols I believe separate discontinuity indicators 
> is better.
> >
> > Any other opinions?
> >
> > Dan
> >
> >
> >
> >

---

From: Dave Thaler <[email-masked]>
Date: Wed, 17 Oct 2007 09:41:43 -0700

I didn't follow why you think UDP and UDPLITE are different.
Technically the UDP and UDPLITE protocols are at the same
layer with the same persistence attributes.

Can you elaborate on why you think the discontinuity of
their counters has different semantics?

-Dave

> Sent: Wednesday, October 17, 2007 9:23 AM
> To: Dave Thaler; [email-masked]
> In the UDP MIB I think that the approach is acceptable,
> especially as this is derived from an original MIB I / MIB II
> MIB group. Overloading sysUpTime semantics further is not.
> This MIB module is according to the authors supposed to work
> on high speed links (they gave up counter32
> objects) and for each packet they need to compute checksum
> and count checksum errors - so it may be very possible that
> the implementation is on a separate module, maybe hardware.
> Zeroing sysUpTime each time such a counter on that module
> runs into a discontinuity is not a good thing.
>
> Dan
>
>
>
>
>
> > which also exists in the UDP MIB.  For example, the process
> object is
> > known to be problematic, and the authors chose to repeat the same
> > problems as in the UDP MIB, with the expectation that both would be
> > fixed by a subsequent MIB.
> >
> > This seems like it fits into the same category.  Pushing on one
> > problem without pushing on all known problems seems inconsistent to
> > me.  So either don't push (accept the authors'
> > position that a new MIB is needed in the future), or push on both
> > issues would be my recommendation.
> >
> > -Dave
> >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Oct 2007 18:52:20 +0200

The issue is not that the semantics of the objects are so different, but
that we are overloading sysUpTime by making it a discontinuity marker
for an extra set of new objects, which may lead the agent to have to
reset it more often. The two protocols are obviously at the same layer,
but I expect UDP to be universally deployed in all IP stack
implementations while UDP lite not. Then, the extra MIB objects that I
mentioned seem to be more resource consuming for UDP-lite while they do
not exist in 4113 which may lead to being implemented in a different
module or process. 

Dan

> Sent: Wednesday, October 17, 2007 6:42 PM
> Can you elaborate on why you think the discontinuity of their 
> counters has different semantics?
> 
> -Dave
> 
> especially as 
> > sysUpTime semantics further is not.
> > This MIB module is according to the authors supposed to 
> work on high 
> > speed links (they gave up counter32
> and count 
> > checksum errors - so it may be very possible that the 
> implementation 
> > is on a separate module, maybe hardware.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Oct 2007 19:19:40 +0200

> protocols I believe separate discontinuity indicators is better. 

The really important questions are:

a) Which events can cause discontinuities for the counters?
b) How frequently do we expect these events to happen?

If the answer to a) is "a restart of the operating system" (which kind
of implies to reset sysUpTime), then the question to b) does not even
matter. So if the UDPLITE-MIB is similar to the UDP-MIB in terms of a)
and b), then I think what is in the DESCRIPTION clauses is just fine.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Oct 2007 11:26:48 -0700

Hi -

Let's make sure this isn't just a mis-reading of the text; the words
that are there apparently permit two interpretations.

  a) (this is the way I've always understood it)  A discontinuity in
       sysUptime means that there is a discontinuity in the counter.
       Continuity of the counter MUST be maintained under all
       circumstances except system re-initialization, which is the
       only case where sysUptime is permitted to lose continuity.

   b) (this had reading had not occurred to me)  If the instrumentation,
        for whatever implementation-specific reason, fails to maintain
        continuity of the counter, sysUptime MUST be reset.

I find it hard to believe that (b) could be correct.  Two reasons:
   1) it is horrific data modeling practice for the DESCRIPTION
        of one OBJECT-TYPE to change the behaviour of another
        OBJECT-TYPE.
   2) The DESCRIPTION of sysUpTime merely says:
        "The time (in hundredths of a second) since the
          network management portion of the system was last
          re-initialized."  While perfectly compatible with reading
          (a), this is not at all compatible with reading (b)
          UNLESS the set of "other times" is the empty set.

Does anyone know of any specific implementations for which this set
of "other times" is not empty, and for which someone has actually
implemented a means of trashing sysUpTime?  If there are no such
implementations, then we should simply clarify (by way of an erratum)
that reading (a) is the intended one.

Randy

----- Original Message ----- 
From: "Dave Thaler" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>
Sent: Wednesday, October 17, 2007 9:10 AM
Subject: [MIB-DOCTORS] RE: (no) discontinuity timer in UDPLITE-MIB

-Dave

---

From: "David Harrington" <[email-masked]>
Date: Thu, 18 Oct 2007 08:26:20 +0800

If they are responding to discontinuities other than system restart,
they should use their own discontinuity indicator.

dbh

> Sent: Wednesday, October 17, 2007 9:37 PM
> To: [email-masked]
> this work
> sysUpTime

---

From: Dave Thaler <[email-masked]>
Date: Wed, 17 Oct 2007 18:23:31 -0700

I agree reading (a) is also the correct one.

I think your point is that the "at other times" clause in the UDPLITE-MIB
should be deleted, and I agree with that.  This would result in

"Discontinuities in the value of this counter can occur
at re-initialization of the management system as indicated by
discontinuities in the value of sysUpTime."

-Dave

> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2007 11:27 AM
> To: [email-masked]
> Subject: Re: [MIB-DOCTORS] RE: (no) discontinuity timer in UDPLITE-MIB
>
> Hi -
>

---

From: Dave Thaler <[email-masked]>
Date: Wed, 17 Oct 2007 18:23:31 -0700

-Dave

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Oct 2007 08:22:01 +0200

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, October 17, 2007 7:20 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> Subject: Re: [MIB-DOCTORS] (no) discontinuity timer in UDPLITE-MIB
> 
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udplite-mib-02.tx
> > t in review this week at the IESG telechat has the 
> following sentence 
> > in the DESCRIPTION object of its counters:
> > 
> > I believe that overloading sysUpTime with semantics of 'at 
> other times'
> If the answer to a) is "a restart of the operating system" 
> (which kind of implies to reset sysUpTime), then the question 
> to b) does not even matter. So if the UDPLITE-MIB is similar 
> to the UDP-MIB in terms of a) and b), then I think what is in 
> the DESCRIPTION clauses is just fine.
> 
> /js
> 

You are asking the right questions, I think. 

My understanding is that the answer from start to question a) is 'not
only at restarts of the operating system' for both UDP and UDP-lite,
this is why they added  'and at other times' after  'Discontinuities in
the value of this counter can occur at re-initialization of the
management system'. The question and reason of my concern is whether
UDP-lite implementations have more chances of these events to happen
because of the need to perform checksum and count errors on each packet
at high-speed which may lead to some implementations to use a separate
block for this purpose.

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Oct 2007 08:49:32 +0200

> at high-speed which may lead to some implementations to use a separate

Still to abstract for me. Which events can cause discontinuities of
the counters, other than system reboot or restart of the SNMP agent?

/js

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Thu, 18 Oct 2007 09:32:02 +0200

That would be a fine solution too, if indeed discontinuities
can only occur at re-start time.

Bert Wijnen  

> Sent: Thursday, October 18, 2007 3:24 AM
> To: Randy Presuhn; [email-masked]
> Subject: RE: [MIB-DOCTORS] RE: (no) discontinuity timer in UDPLITE-MIB
> 
> I think your point is that the "at other times" clause in the 
> UDPLITE-MIB should be deleted, and I agree with that.  This 
> would result in
> 
> "Discontinuities in the value of this counter can occur at 
> re-initialization of the management system as indicated by 
> > Does anyone know of any specific implementations for which 
> this set of 
> > "other times" is not empty, and for which someone has actually 
> > > in review this week at the IESG telechat has the 
> following sentence 
> > > the inclusion of a discontinuity object as required by 4181 and 
> > > 2578. I believe that overloading sysUpTime with semantics of 'at 
> > > other times'
> > > sysUpTime should reflect a discontinuity of a UDP counter because 
> > > it's part of the original IP stack (and MIB I / MIB II 
> > > implementation) for other protocols I believe separate 
> discontinuity 
> > > indicators is better.
> > >
> > > Any other opinions?
> > >
> > > Dan
> > >
> > >
> > >
> > >

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Thu, 18 Oct 2007 09:29:26 +0200

Inline

Bert Wijnen  

> Sent: Wednesday, October 17, 2007 8:27 PM
> To: [email-masked]
> Let's make sure this isn't just a mis-reading of the text; 
> the words that are there apparently permit two interpretations.
> 

I have always understood (b) to be the case.
Maybe we can ask Keith (I think he monitors this list) as well.

My understanding is also, that if a Counter object does not specify 
a discontinuity timer, that then by default  sysUpTime becomes that
discontinuity timer. As a result, if a discontinuity occurs,
then that results (or should result in my reading) a reset of
sysUpTime. That would (I think) also result in a warm start 
notification. But some of this may be my subjective (and possibly
incorrect) understanding.

>         of one OBJECT-TYPE to change the behaviour of another

Indeed, and I thought that that was exactly the reason why we
REQUIRE that Counter objects include text that states which
timer is to be used as the disconbtinuity timer.

>           UNLESS the set of "other times" is the empty set.

As I said above, when sysUpTime gets reset, then I think such would
result in a warm-start notification, and so then reading (b) 
again is fine, because it implies a (warm) restart.

Bert
> this set of "other times" is not empty, and for which someone 
> has actually implemented a means of trashing sysUpTime?  If 
> there are no such implementations, then we should simply 
> clarify (by way of an erratum) that reading (a) is the intended one.
> 
> Randy
>

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Thu, 18 Oct 2007 09:32:02 +0200

If in the UDP-MIB, the "and at other times" is really stating that
dioscontinuities can occur at other times than at system restrat,
then yep, the UDP-MIB would have better defined an extra
discontinutity timer object as well.

In rpactice, if it happens very very rarely, then it does not
matter much. But if such discontinuities "at other times"
happen more often, then the result is, that all other counters
that specify that they only show discontinuities at restart
would all be marked as having a discontinuity. That is the
problem.

Bert Wijnen  

> Sent: Thursday, October 18, 2007 3:23 AM
> If there is a problem with UDP-lite, the same problem would 
> already exist with the UDP counters.  If the agent has found 
> a way to solve that, then the same solution would work for UDP-lite.
> 
> In other words, your argument seems to really be that making 
> sysUpTime cover UDP in MIB-II was wrong.  Is that what you're saying?
> 
> Don't know if anyone else follows your argument, or if it's 
> just me that's confused.
> 
> -Dave
> 
> > Sent: Wednesday, October 17, 2007 9:52 AM
> > The issue is not that the semantics of the objects are so 
> different, 
> > but that we are overloading sysUpTime by making it a discontinuity 
> > marker for an extra set of new objects, which may lead the agent to 
> > have to reset it more often. The two protocols are obviously at the 
> > same layer, but I expect UDP to be universally deployed in all IP 
> > stack implementations while UDP lite not. Then, the extra 
> MIB objects 
> > that I mentioned seem to be more resource consuming for 
> UDP-lite while 
> > they do not exist in 4113 which may lead to being implemented in a 
> > different module or process.
> >
> > Dan
> >
> >
> >
> >
> > > > The difference is that this is not a problem that exists
> > in the UDP
> > > > MIB.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Oct 2007 11:57:48 +0200

This not exactly what I am saying. UDP is part of any IP stack and the
UDP MIB group is part of the original MIB I and MIB II groups. Making
sysUpTime the discontinuity marker of basic IP protocols may not be the
best solution but is justified to a certain extent and was justified by
the time MIB I and MIB II were written.

This is not the case with other protocols that are not part of a basic
IP stack. We cannot make all protocols use sysUpTime as discontinuity
marker, applications make an assumption that sysUpTime resets when the
device or at least the agent is reinitialized, we do not want this to
happen for discontinuity of any counters, and this is why 2578 and 4181
recommend to use distinct discontinuity objects. So the question is
where we believe UDP-lite falls. I think it is not part of the basic IP
package and that discontinuities with a separate checksum block may
happen without the need to reinitialize the whole agent, and this is why
a distinct notification object is needed for UDP-lite. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Oct 2007 12:04:30 +0200

I can live with such a solution. It makes clear that sysUpTime can be
trusted as discontinuity marker for agent restart only. Other cases are
not covered, which is not so good (and contrary to what 2578 and 4181
recommends) but at least the text is not mis-leading. Best would be to
create this discontinuity object though. 

Dan

> the words

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Oct 2007 17:03:59 +0200

> 
> Still to abstract for me. Which events can cause 
> discontinuities of the counters, other than system reboot or 
> restart of the SNMP agent?

A reset of the module that performs checksum computation, detects and
counts checksum errors. 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Oct 2007 17:31:35 +0200

> A reset of the module that performs checksum computation, detects and

Kernel module?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Oct 2007 17:38:14 +0200

> Sent: Thursday, October 18, 2007 5:32 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> discontinuities of 

Not necessarily. Different implementation models should be supported and
they may go as far as HW implementations.

Dan