"Mark S. Lewis" <mlewis@telebit.com> Wed, 09 February 1994 02:15 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25938; 8 Feb 94 21:15 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25934; 8 Feb 94 21:15 EST
Received: from apache.telebit.com by CNRI.Reston.VA.US id aa24257; 8 Feb 94 21: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 AA03958 to ietf-archive@cnri.reston.va.us; Tue, 8 Feb 94 18:07:39 PST
Received: from yoyo.telebit.com by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718) id AA25781 to modemmgt@apache.Sunnyvale.Telebit.COM; Tue, 8 Feb 94 18:07:31 PST
Date: Tue, 08 Feb 1994 18:07:31 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Mark S. Lewis" <mlewis@telebit.com>
Message-Id: <9402090207.AA25781@america.Sunnyvale.Telebit.COM>
Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA13500; Tue, 8 Feb 94 18:07:28 PST
To: zoran@netcomm.pronet.com
Cc: modemmgt@telebit.com
In-Reply-To: <m0pTJzy-000278C@netcomm.netcomm.pronet.com> (zoran@netcomm.pronet.com)
Reply-To: Mark.S.Lewis@telebit.com
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"

>>>>> On Mon, 7 Feb 94 10:38 AEST, zoran@netcomm.pronet.com (Zoran Tomasevic) said:

> I AM NOT SHURE THAT MY PREVIOUS MAIL HAVE BEEN DELIVERED,
> SO I FEEL FREE TO REPOST IT AGAIN. APOLOGY FOR ANY POSSIBLE
> INCOVENIENCE.

Thanks for the comments.  They seem to have made it to the list just
fine both times.

> 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. 

I agree we need both incoming and outgoing stats.

> <stuff deleted>

> 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 }

In general, I believe we have more than enough statistics.  I would
like to keep the set to the core of functionality.  I think I would
prefer to defer this object to consideration as part of an extensions
group.  Anybody else?

> 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.

Steve Waldbusser and other raised an important question that bears on
this point.  This key question is for incoming connections, it it
possible to differentiate abnormal from normal terminations.

I understand that at the link layer, carrier goes just goes away and
the connection terminates.  There reason for the termination is not
known.  However if the modem is using an error control protol (eg. MNP
or LAPM), the modem can differentiate between normal and abnormal
termination.

Given that it is only possible to differentiate this under certain
circumstances, I suggest we drop trying to keep track of
AbnormalTerminations.  Beside we don't want to impose any unecessary
implementation requirements on modem manufacturers which would require
firmware modifications to support an object like this.

I propose something like Rick suggests:

	mdmStatsIncomingConnections
	mdmStatsIncomingConnectionFailures.
	mdmStatsOutgoingConnections
	mdmStatsOutgoingConnectionFailures.

Where Connections = success, and Requests = Connections + Failures.  I
think it is handier to talk about Connections (successes) and Failures
rather than Requests.

... Mark

==========--------------       Mark S. Lewis      ----------==========
Mark.S.Lewis@Telebit.com       Telebit Corp.      Voice (408) 745-3232
  •   Zoran Tomasevic
  •   Mark S. Lewis