Zoran Tomasevic <zoran@netcomm.pronet.com> Fri, 04 February 1994 22:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26811; 4 Feb 94 17:44 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26806; 4 Feb 94 17:44 EST
Received: from apache.telebit.com by CNRI.Reston.VA.US id aa22232; 4 Feb 94 17:44 EST
Received: from america.Sunnyvale.Telebit.CO (america-bb.sunnyvale.telebit.com) by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA27504 to ietf-archive@cnri.reston.va.us; Fri, 4 Feb 94 14:28:03 PST
Received: from apache.telebit.com by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718) id AA00988 to modemmgt@apache.Sunnyvale.Telebit.COM; Fri, 4 Feb 94 14:27:56 PST
Received: from orac.pronet.com by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA27486 to modemmgt@Telebit.COM; Fri, 4 Feb 94 14:27:47 PST
Received: from cristal.syd.pronet.com by orac.pronet.com with smtp (Smail3.1.28.1 #14) id m0pSGp6-00034dC; Fri, 4 Feb 94 13:03 EST
Received: from netcomm.netcomm.pronet.com by cristal.syd.pronet.com with bsmtp (Smail3.1.28.1 #3) id m0pSFp3-0002BIC; Fri, 4 Feb 94 12:59 AEDT
Received: by netcomm.netcomm.pronet.com (Smail3.1.28.1 #3) id m0pSFPz-00027OC; Fri, 4 Feb 94 11:33 AEST
Message-Id: <m0pSFPz-00027OC@netcomm.netcomm.pronet.com>
Date: Fri, 04 Feb 1994 11:33:00 -0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Zoran Tomasevic <zoran@netcomm.pronet.com>
To: MIB_comments_1@netcomm.pronet.com, modemmgt@telebit.com

After I have been lurker for some time in this mailing list,
I would like to add some comments regarding modem statistic
group.

Chris Rosmans idea to merge incoming and ougoing abnormal
termination is not reasonable to me. Also, looks that nobody
knows what abnormal termination could be! At the moment I can
think of only three events in that category:

	a) disconnection during or after some number of
	unsuccessefull retrains (ref. V58),

	b) disconnection during or immediately after fallback,

	c) disconnection during or immediately after fallforward.

All this means that objects should stay in the group.

Following Steven Walbusser note that
	failures + successes = requests
I would like to rename - mdmStatsOutgoingConnectionsRequests -to
			 mdmStatsOutgoingConnectionsAccepted
and to propose NEW object
			 mdmStatsUnsuccesseefullDialAttempts

mdmStatsUnsuccessefullDialAttempts OBJECT-TYPE
	SYNTAX		Counter
	ACCESS		read-only
	STATUS		current
	DESCRIPTION
		"This object reflects count of performed dials
		failed because modem didn't go off hook, there
		is no dialtone or there is error in dialing
		stored number from NVRAM"
	::= { mdmStats xxx }

This way, we can split connection process failure statistic in to
three stages:
	a) early stage where connection is hardware dependable,
	and where RingsNoAnswer/DTERingsNoAnswer are covering 
	incoming connection and object above outgoing connection,

	b) handshake,sync stage through exisiting objects,
	mdmStatIncomingConnectionsFailures and
	mdmStatOutgoingConnectionsFailures and,

	c) late stage through abnormal termination object.

The number of successefull connections can be calculated from
above objects as
	incomingSuccess = incomingAccepted - incomingAbnormalTerminations
and same for outgoing connections.

Comments are welcome.
  •   Zoran Tomasevic