Zoran Tomasevic <zoran@netcomm.pronet.com> Mon, 07 February 1994 01:15 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20886; 6 Feb 94 20:15 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20882; 6 Feb 94 20:15 EST
Received: from apache.telebit.com by CNRI.Reston.VA.US id aa04851; 6 Feb 94 20:15 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 AA13525 to ietf-archive@cnri.reston.va.us; Sun, 6 Feb 94 17:09:12 PST
Received: from apache.telebit.com by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718) id AA15452 to modemmgt@apache.Sunnyvale.Telebit.COM; Sun, 6 Feb 94 17:09:11 PST
Received: from orac.pronet.com ([192.88.6.3]) by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA13517 to modemmgt@Telebit.COM; Sun, 6 Feb 94 17:08:54 PST
Received: from cristal.syd.pronet.com by orac.pronet.com with smtp (Smail3.1.28.1 #14) id m0pTLL6-0002wCC; Mon, 7 Feb 94 12:04 EST
Received: from netcomm.netcomm.pronet.com by cristal.syd.pronet.com with bsmtp (Smail3.1.28.1 #3) id m0pTKKS-0001YyC; Mon, 7 Feb 94 11:59 AEDT
Received: by netcomm.netcomm.pronet.com (Smail3.1.28.1 #3) id m0pTJzy-000278C; Mon, 7 Feb 94 10:38 AEST
Message-Id: <m0pTJzy-000278C@netcomm.netcomm.pronet.com>
Date: Mon, 07 Feb 1994 10:38:00 -0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Zoran Tomasevic <zoran@netcomm.pronet.com>
To: modemmgt@telebit.com
I AM NOT SHURE THAT MY PREVIOUS MAIL HAVE BEEN DELIVERED, SO I FEEL FREE TO REPOST IT AGAIN. APOLOGY FOR ANY POSSIBLE INCOVENIENCE. 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.