Subject: RE: NFS MIB ideas

From: Venkat Rangan <[email-masked]>
Date: Sat, 17 Mar 2001 15:44:45 -0800

Brent,

Thanks for your points.

> My guess is that admins would be interested in higher-level
> statistics, e.g. which filesystems are hot? which clients
> are beating on my server? what's the average call processing
> time? How many bytes/sec are being read/written?

I agree that these are useful. In many cases, MIB designers choose
to provide the raw information, and allow the SNMP Manager to derive
interesting higher-level info.

> which filesystems are hot?

This is hopefully available by the Operation Counters, which we should
provide on a per filesystem basis.

> which clients are beating on my server?

This becomes slightly harder, as it requires building a matrix of
statistics. RMON (RFC2819) Matrix table is a good example of this, but
those implementations typically run in a separate box, promiscuously
monitoring
the wire.

> what's the average call processing time?

This would be useful, but will now require timestamps being maintained
on requests and responses. I suppose one would want this broken down per
filesystem and per operation, rather than an overall average.

> How many bytes/sec are being read/written?
This should be on filesystem objects, but my preference would be to
merely count the bytes, rather than provide a rate. Once we try a rate
computation, we run into a time base for it. If the server chooses a
rate base, that may not be what a particular application wants. If the
SNMP agent is "rate-aware" for multiple clients, it poses more difficulties
in rate computations. And typically, this is left to management applications
to decide on a polling rate they feel is convenient for their desired
granularity of time base.

>> 1. Do we need to also handle v2 and v3 protocol implementations?
>
> I think most v4 servers will also support v2 and v3.  It would be
> an obvious omission not to support those versions too.

I agree.

>> 2. Do we need a separate MIB for RPC layer?
>
> Yes.  That would be a good place to accumulate things
> like duplicate request counts, bad xids etc.

I was also motivated by diagnostic information of this type, but
there were some difficulties mentioned in this thread. We should at the
very least, provide the RPC layer MIB as used by NFS. i.e., if NFS is the
only app that causes the RPC layer counters to be updated, that may be
a reasonable start.

>> 4. Object model for the MIB, along the lines of iSCSI.
>
> That would be interesting.  Is there an iSCSI MIB we can look at?
The iSCSI MIB model is available at:

http://www.haifa.il.ibm.com/satran/ips/Visio-iscsi-uml-model-02.pdf

iSCSI MIB table structure

http://www.haifa.il.ibm.com/satran/ips/iscsi-mib-structure-02.pdf

The MIB itself is at:

http://www.haifa.il.ibm.com/satran/ips/draft-bakke-iscsimib-02.txt

>> 5. Does it make sense to have a MIB for the client side as well?
>
> Yes.
Agreed. It may be even more helpful given the delegation model of v4.

>> 7. Conformance levels and object grouping to support flexible conformance
>> levels.
>
> Sounds some kind of MIB compliance model.  You may need to educate us.

This isn't very complicated. Rather than have all the objects in the MIB
be mandatory for implementation, one can group objects and mark them as
mandatory. IF-MIB (RFC2833) has several examples. As an example, if we place
both Server and Client side objects in the same MIB, they could be grouped
so that an implementation can choose to provide the groups that are relevant
for
it.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsoynetworks.com

-----Original Message-----
From: Brent [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 6:19 PM
To: [email-masked]
Subject: Re: NFS MIB ideas

Venkat Rangan wrote:

> I created a very early version of the MIB which covers the following
areas:
> 
> - Error counters that count the number of occurrences of almost all errors
> 
> - Statistical counters for all the NFS v4 operations
> 
> - Table of current locks and their owners

I'm a neophyte to MIB design, but it seems that you should design
a MIB so that it provides access to data that an NFS administrator needs.

I'm an NFSv4 engineer, so error and operations counts would
be lovely, but it doesn't seem all that useful to an NFS sysadmin
no matter how much you process the data.

My guess is that admins would be interested in higher-level
statistics, e.g. which filesystems are hot? which clients
are beating on my server? what's the average call processing
time? How many bytes/sec are being read/written?

> 1. Do we need to also handle v2 and v3 protocol implementations?

I think most v4 servers will also support v2 and v3.  It would be
an obvious omission not to support those versions too.

> 2. Do we need a separate MIB for RPC layer?

Yes.  That would be a good place to accumulate things
like duplicate request counts, bad xids etc.

> 3. How much configuration and operation-level objects do we need?

I'm not sure of the distinction.  Can you give examples?

> 4. Object model for the MIB, along the lines of iSCSI.

That would be interesting.  Is there an iSCSI MIB we can look at?

> 5. Does it make sense to have a MIB for the client side as well?

Yes.

> 6. Besides 'nfsstat' like statistics, what other measurements are most
> useful? Is it interesting to include 'Response Time' measurements?

nfsstat provides a minimal set of NFS statistics.  For Solaris, you can
get per-mount statistics on the client, but not per-share statistics
on the server.  I think a MIB could provide more useful statistics.

> 7. Conformance levels and object grouping to support flexible conformance
> levels.

Sounds some kind of MIB compliance model.  You may need to educate us.

	Thanks
		Brent

---

From: Eric Werme USG <[email-masked]>
Date: Mon, 19 Mar 2001 11:30:05 -0500

This is already done, at least in some client implementations.  The
information is used to set the minimum retransmit timer so we are less likely
to retransmit on a high latency link.  I think Solaris prints some of this, I
think it may be an awful mess in Tru64.  The intent is to time three classes
of operation (lookup, read, and write) to anticipate the different costs of
each class.  This is done per mount.  Then V3 came along with readdirplus,
unstable writes, commit, and bigger I/Os that cause increased latency due to
congestion.  It was all one of the arguments for letting TCP deal with
retransmission.

	-Ric Werme