Radius MIBs statistics misunderstandings (fwd)

[Bernard Aboba <aboba@internaut.com>]

---------- Forwarded message ----------
Date: Wed, 28 Jul 2004 17:25:53 +0200
From: Nagi Reddy Jonnala <Nagi_Reddy.Jonnala@alcatel.be>
To: gwz@cisco.com, radiusext@ops.ietf.org
Cc: stefaan.de_cnodder@alcatel.be, 'Bernard Aboba' <aboba@internaut.com>
Subject: Radius MIBs statistics misunderstandings

As suggested by Bernard, since the WG is revising the MIBs,  this
discussion might be generally useful.

Glen,

I would like to resolve these statistics misunderstandings once and for
all. Could you please review if my understanding match with your
interpretations.

Issue-1:

Stefaan asked:


  > Some questions we have regarding the existing RFCs (since you are
  > updating these) we found while writing our draft:
  >
  > 1) Is the definition o TotalIncomingPackets in RFC2618 on page 6
  > correct? I believe there is something wrong with it.


Glen replied:

  I think that you are right.  With the curent definition, it appears
that
  "Successfully Received" could be negative, since we're subtracting
  counters from TotalIncomingPackets that were not include in the sum.
  Also, I guess that "AccessRequests + PendingRequests + ClientTimeouts
=
  Successfully Received" just below should read "AccessRequests +
  PendingRequests + ClientTimeouts = Successfully Transmitted".


Nagi commented:

My understanding is that RFC-2618 considers that an Access Response
(Accept or Reject or Challenge) counter MUST be incremented before it is
validated. i.e.,
Either one of Malformed responses or bad authenticators or  packets
dropped counters will be incremented if the packet is invalid.

Do you interpret the same from the RFC-2618. If yes, I would like to
know what are the reasons for this. Isn't that an Access Response
counter MUST be incremented
only after the packet is found *valid*.

If you are convinced that the approach in RFC-2618 is OK, then I would
say that the first two equations hold good. i.e., Your statement above
(saying
Successfully_Received could be negative) is incorrect. Am I right? or
missing something?

Issue-2:

Stefaan asked:

  > 3) radiusAuthClientPendingRequests: upon retransmission this counter

  > is decremented. So a retransmitted packet is not considered as being

  > pending, although such restransmissions can still be considered as
  > being pending requests.

Glen replied:

  Yup, it probably shouldn't be decremented on retransmissions,
especially
  since it's already decremented on timeouts.


Nagi commented:

My understanding is that Pending requests should be decremented on
receiving an Access response and on an expiry of timeout. It looks
obvious to me that Pending
requests should be incremented on a retransmission (to the same server).

Please see the text

"This variable is incremented when an Access-Request is sent and
decremented due to
 receipt of an Acess-Accept, Access-Reject or Access-Challenge, a
timeout or retransmission."

I suspect that the text is misleading. The text should be like

"This variable is incremented when an Access-Request and retransmission
is sent and decremented due to receipt of an Acess-Accept, Access-Reject
or
Access-Challenge, a timeout "

Do you guys agree?

Issue-3:

See the equation:

AccessRequests + PendingRequests + ClientTimeouts = Successfully
Received

I agree with you that left hand side value should be equal to
"Successfully Transmitted".  Also  "AccessRequests +
AccessRetransmissions = Successfully
Transmitted" equation holds good. Right?


Thanks & regards
Nagi.





--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>