Subject: [Disman] DISMAN-PING-MIB questions: default address type, message interval and pingCtlDSField

From: Bill Fenner <[email-masked]>
Date: Fri, 27 Oct 2006 12:11:48 -0700

I'm implementing a manager that uses the DISMAN-PING-MIB, and
have three questions.

1. RFC 4560 says:
          A single SNMP PDU can be used to create and start a remote
   ping test.  Within the PDU, pingCtlTargetAddress should be set to the
   target host's address (pingCtlTargetAddressType will default to
   ipv4(1)), pingCtlAdminStatus to enabled(1), and pingCtlRowStatus to
   createAndGo(4).
However, the DEFVAL of pingCtlTargetAddressType is unknown, and
that's the value that the agent I'm testing against uses when you
don't specify it.  It seems that the agent is right, based on the
MIB, and the text that says that the addresstype has a default of
ipv4(1) is wrong?

2. There's no object that explicitly talks about the interval between
probes when the probe is successful.  If I set pingCtlProbeCount=15 and
leave pingCtlTimeOut=3, I naively assumed that when the probe response
was received, it would wait less time (I assumed 1 second, since that's
what UNIX ping defaults to) to send the next probe.  I thought that
partly because of the wording in section 3.1.2:

   Using the maximum value for the parameters defined within a pingEntry
   can result in a single remote ping test's taking at most 15 minutes
   (pingCtlTimeOut times pingCtlProbeCount), plus whatever time it takes
   to send the ping request and to receive its response over the network
   from the target host.

If the probes are always spaced pingCtlTimeOut (plus RTT) apart, then
this really means "*at least*" 15 minutes, right?  Saying "at most"
made me think it could take 15 seconds if the tests completed
successfully.

3. I don't understand the discussion of the use of pingCtlDSField.
Since zero is a valid value for the DSCP/ToS field in the IP header,
and is in fact the value that most senders fill in, I don't understand
how zero can mean that this function of filling in the DSCP/ToS field
is not supported.  The DESCRIPTION says:

           This option can be used to determine what effect an
           explicit DS Field setting has on a ping response.
           Not all values are legal or meaningful.  A value of 0
           means that the function represented by this option is
           not supported.

and the compliance says
           OBJECT pingCtlDSField
           MIN-ACCESS  read-only
           DESCRIPTION
               "Write access is not required.  If write access is
               not supported, return a 0 as the value of this object.
               A value of 0 means that the function represented by
               this option is not supported."

Since the default value is zero, and zero is a valid value, a manager
can't use the value of zero to know that write access is not
supported.  In fact, the agent that I'm testing against puts zero
into the row if the value isn't specified in the set that creates
it (unsurprisingly, since that's the DEFVAL) but also supports write
access:

frogbits% ./pset 'pingCtlTargetAddressType."test"."test"' i ipv4 'pingCtlTargetAddress."test"."test"' x c014e128 'pingCtlRowStatus."test"."test"' i createAndWait
DISMAN-PING-MIB::pingCtlTargetAddressType."test"."test" = INTEGER: ipv4(1)
DISMAN-PING-MIB::pingCtlTargetAddress."test"."test" = Hex-STRING: C0 14 E1 28 
DISMAN-PING-MIB::pingCtlRowStatus."test"."test" = INTEGER: createAndWait(5)
frogbits% ./pget 'pingCtlDSField."test"."test"'
DISMAN-PING-MIB::pingCtlDSField."test"."test" = Gauge32: 0
frogbits% ./pset 'pingCtlDSField."test"."test"' u 160
DISMAN-PING-MIB::pingCtlDSField."test"."test" = Gauge32: 160

I'm inclined to simply ignore the claim that zero means not supported,
and try to set it anyway and let an SNMP error tell me that it's not
supported.  Is there anything wrong with that tactic?

Thanks,
  Bill

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 27 Oct 2006 13:30:45 -0700

Hi -

> From: "Bill Fenner" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, October 27, 2006 12:11 PM
> Subject: [Disman] DISMAN-PING-MIB questions: default address type,message interval and pingCtlDSField
>
>

It looks like this is a long-standing error in the document.  The same
problem exists in RFC 2925.  The error was introduced in the changes
from draft-ietf-disman-remops-mib-07.txt to produce the draft
draft-ietf-disman-remops-mib-08.txt. in August / Spetember of 2000.
The only relevant discussion I could find is in Ken White's
message of August 28, 1999 (see ftp://ftp.ietf.org/ietf-mail-archive/disman/)
and that doesn't explain why the change was made to the DEFVAL.

I can see two ways to correct this.  Either would result in an erratum:
  a) fix the DEFVAL, since the change wasn't agreed in the WG
      as far as I can tell (please correct me if I'm wrong and just
      couldn't find or remember the discussion).
  b) fix the single-PDU text.  someone will need to count the bytes
      to see if the additional varbind would take us over the limit.

> made me think it could take 15 seconds if the tests completed

15 minutes is the largest amount of time that could be contributed to the
total time dues to the (pingCtlTimeOut times pingCtlProbeCount)
component.  The "plus" is an essential part of the total formulation.
Using "at least" would be wrong - 15 minutes is indeed the maximum
contributed by that component (it could be much less if smaller
values are chosen for pingCtlTimeOut or pingCtlProbeCount)
to the total time.

In short, the text looks ok to me.

> frogbits% ./pset 'pingCtlTargetAddressType."test"."test"' i ipv4 'pingCtlTargetAddress."test"."test"' x c014e128
'pingCtlRowStatus."test"."test"' i createAndWait
> supported.  Is there anything wrong with that tactic?
...

Nope.  As I understand it...

The language could have been been better.
If the feature is not supported, the object should read as zero.
If read as zero, no conclusion is possible about whether the
feature is supported. If read as non-zero, the feature is supported.

Randy

---

From: Bill Fenner <[email-masked]>
Date: Fri, 27 Oct 2006 21:19:40 -0700

Thanks for the answers, Randy.

[DEFVAL for pingCtlTargetAddressType]
>      to see if the additional varbind would take us over the limit.

I only have experience with one implementation, but it uses the DEFVAL
specified in the MIB, which seems like an eminently reasonable thing
to do - so to avoid making reasonable implementations non-compliant,
I think option b might be better.  I don't know what the limit is, but
an SNMPv2c set with the following varbinds:

DISMAN-PING-MIB::pingCtlTargetAddressType."12345678901234567890123456789012"."12345678901234567890123456789012" = INTEGER: ipv4(1)
DISMAN-PING-MIB::pingCtlTargetAddress."12345678901234567890123456789012"."12345678901234567890123456789012" = Hex-STRING: 04 02 02 02
DISMAN-PING-MIB::pingCtlAdminStatus."12345678901234567890123456789012"."12345678901234567890123456789012" = INTEGER: enabled(1)
DISMAN-PING-MIB::pingCtlRowStatus."12345678901234567890123456789012"."12345678901234567890123456789012" = INTEGER: createAndGo(4)

was 401 bytes, including IP and UDP headers, according to tcpdump.

>> ... section 3.1.2:

I guess we're reading this from opposite sides.  You're reading "a test
could take at most 15 minutes because of the contribution from these
values".  I'm reading "Using the maximum values, you can expect the test
to take at most 15 minutes plus...".  The first one is true; the second
is only barely true (it'll take exactly 15 minutes, plus ...).  I think
this may just be one of those areas where those who are familiar with
a document read it differently because they know what it's trying to say.

This is the behavior of the agent I'm using, so since my real question
was "is this the behavior I should expect" and the answer seems to be
"yes", that's good enough.

>Nope.

Ok!

Thanks,
  Bill

---

From: Bill Fenner <[email-masked]>
Date: Sun, 29 Oct 2006 14:37:03 -0700

I wrote:
>I'm reading "Using the maximum values, you can expect the test
>to take at most 15 minutes plus...".

And if I wasn't being so stubborn, I would have realized that was
true.  If the final probe succeeds, it will take 14 minutes plus...;
if it times out it will take 15 minutes plus...

I apologize for being dense.  It takes some work to switch from
the UNIX ping model of "send a packet every second and collect
the results asynchronously".

  Bill