Re: Proposal for two new objects

Steven Waldbusser <waldbusser+@cmu.edu> Wed, 23 February 1994 18:21 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08692; 23 Feb 94 13:21 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08688; 23 Feb 94 13:21 EST
Received: from apache.telebit.com by CNRI.Reston.VA.US id aa14909; 23 Feb 94 13:21 EST
Received: from america.Sunnyvale.Telebit.CO (america-bb.sunnyvale.telebit.com) by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-940210) id AA10051 to ietf-archive@cnri.reston.va.us; Wed, 23 Feb 94 10:13:00 PST
Received: from apache.telebit.com by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718) id AA17538 to modemmgt@apache.Sunnyvale.Telebit.COM; Wed, 23 Feb 94 10:12:57 PST
Received: from po4.andrew.cmu.edu by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-940210) id AA10048 to Mark.S.Lewis@Telebit.COM; Wed, 23 Feb 94 10:12:55 PST
Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.6.4/8.6.4) id NAA00861; Wed, 23 Feb 1994 13:12:43 -0500
Received: via switchmail; Wed, 23 Feb 1994 13:12:41 -0500 (EST)
Received: from zeus.net.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.QhOtli600WArM0Nipw>; Wed, 23 Feb 1994 13:11:58 -0500 (EST)
Received: from zeus.net.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr5/sw0l/.Outgoing/QF.ghOtlf200WArRH338w>; Wed, 23 Feb 1994 13:11:55 -0500 (EST)
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.zeus.net.cmu.edu.sun4m.412 via MS.5.6.zeus.net.cmu.edu.sun4c_411; Wed, 23 Feb 1994 13:11:50 -0500 (EST)
Message-Id: <shOtlaS00WArRH32wS@andrew.cmu.edu>
Date: Wed, 23 Feb 1994 13:11:50 -0500 (EST)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steven Waldbusser <waldbusser+@cmu.edu>
To: Mark.S.Lewis@telebit.com
Subject: Re: Proposal for two new objects
Cc: modemmgt@telebit.com
In-Reply-To: <9402190033.AA28574@america.Sunnyvale.Telebit.COM>
References: <9402190033.AA28574@america.Sunnyvale.Telebit.COM>

Excerpts from modemmgt: 18-Feb-94 Re: Proposal for two new ob.. Mark S.
Lewis@Telebit.CO (2251*)

> 1.  How many administrators would use these objects in normal
> operations?

We would.  We do now.  I can only answer for us, but I think that the
functionality makes sense for most administrators:  They get a call,
user says "Communications are slow", they see that the user is running
at 2400 baud and need to know, is this a capabilities/negotiation
problem, or is it a line problem?  If they know the initial line rate
was 14,400, that tells them something.

Excerpts from modemmgt: 18-Feb-94 Re: Proposal for two new ob.. Mark S.
Lewis@Telebit.CO (2251*)

> 2.  Can vendor readily provide both the current and initial line
> rates?  For example, Telebit modems can provide the current rate but
> does not keep any historic info on rates.  So this would not be easy
> for us as modem vendors.

The requirements are:

1) The modem needs to know the initial line rate
	Every modem I've used has said: "Connect 14400..." or  "Connect 2400". 
This seems easy.

2) You need to get it at the right time
	It's possible that there could be a problem in that the modem knows the
initial line
	rate, but doesn't tell the management software, and/or the management software
	can't look continuously for the rate at connection startup.  But this
won't be a problem if:
		a) the modem stores the initial rate for later retrieval
		b) the modem send the initial rate to the RCU or to the MS
		c) the RCU or MS is continuously polling and can see the initial rate
		   (e.g., in a connect message).

3)  You (may) need to store it
	If the MS/RCU can't get the initial rate on demand from the modem, it
needs to store it
	locally.  This requires four bytes of memory.

Did I miss something?

Excerpts from modemmgt: 18-Feb-94 Re: Proposal for two new ob.. Mark S.
Lewis@Telebit.CO (2251*)

> Also, it might be more informative to keep the lowest rate rather than
> the initial rate.  The current rate can be higher or lower than the
> initial rate.

Actually, in the application above, I'd be looking for the highest rate,
and either the lowest rate or the current rate.  I rank them in this
order:

1	initial + current
2	highest + current
3	initial + lowest
4	highest + lowest

The reason that lowest is less attractive is that I don't know how long
it was in that state.  In a week-long connection, 2 minutes spent at a
very low rate is irrelevant, and might mask a couple of days at a
higher, but non-optimal rate.


Steve