[Tsvwg] Re: TCP ESTATS design team

[Michael Kirkham <[e-mail]>]

I thought I'd take a quick look through the MIB and make a few comments.
I assume this is a new MIB and not one that's currently deployed (given
the 'experimental' branch placement and the MODULE-IDENTITY's only
revision DESCRIPTION).  If I'm wrong, feel free to ignore these comments
as they aren't things that can be changed due to revision policy.

1. It is recommended (although not required) that objects with 'Counter'
types (Counter32, Counter64) denote plurality by ending in 's'.  Of the
the objects in this MIB with 'Counter' types, several do denote plurality,
although by ending in (for example) 'AcksOut' versus 'OutAcks', and many
do not.  You might consider reversing the suffix where plurality is
denoted, and modifying the descriptors of those that don't denote
plurality to do.  There are quite a few, so for the sake of brevety I
haven't listed them.

2. The indexing scheme of the various tables seems a little confusing to
me.  Most of the tables are indexed solely on tcpEStatsConnectIndex except,
oddly enough, the table that actually defines tcpEStatsConnectIndex:

   tcpEStatsConnectIdEntry  OBJECT-TYPE
       SYNTAX       TcpEStatsConnectIdEntry
       MAX-ACCESS   not-accessible
       STATUS       current
       DESCRIPTION
           "Connection ID table."
       INDEX   { tcpEStatsConnectLocalAddressType,
                 tcpEStatsConnectLocalAddress,
                 tcpEStatsConnectLocalPort,
                 tcpEStatsConnectRemAddressType,
                 tcpEStatsConnectRemAddress,
                 tcpEStatsConnectRemPort }
       ::= { tcpEStatsConnectIdTable 1 }

   TcpEStatsConnectIdEntry ::= SEQUENCE {
                 tcpEStatsConnectLocalAddressType  InetAddressType,
                 tcpEStatsConnectLocalAddress      InetAddress,
                 tcpEStatsConnectLocalPort         InetPortNumber,
                 tcpEStatsConnectRemAddressType    InetAddressType,
                 tcpEStatsConnectRemAddress        InetAddress,
                 tcpEStatsConnectRemPort           InetPortNumber,
                 tcpEStatsConnectIndex                Integer32
                 }

I'm guessing that the intent here was to make it easy to find the
tcpEStatsConnectIndex values for a particular 'local' address by
e.g. doing a get-next walk of tcpEStatsConnectIndex.<AddressType>.<Address>
and because all but tcpEStatsConnectIndex are not-accessible (and at
least one column of a table must be accessible).  But I don't see that
this provides much benefit to the other tables.

Why not have the other tables indexed by the same objects if they
are going to be indexed externally anyway?  Or, perhaps better,
have the tcpEStatsConnectIdEntry table map only a single type/address/port
triplet per row, and use a pair of tcpEStatsConnectIndex values
(one for each side of the connection) to index the other tables?
That way you locate statistics from either vantage point, that way
you could quickly locate statistics from either direction (what
defines 'local' versus 'remote' in the context of this MIB?)

Disadvantage: using this method to allow for statistics to be located from
either direction means doubling the data.  Though maybe the data is
already doubled, if the intent is for tcpEStatsConnectIdTable to contain
two rows for every connection, with different values for
tcpEStatsConnectIndex.  Is the intended meaning behind the DESCRIPTION for
tcpEStatsConnectIndex that there be two rows in TcpEStatsConnectIdTable
for each connection, and for each of those two rows to have the same
tcpEStatsConnectIndex value?

I believe this could use some clarification.

That's all for now.  I appologize if I've overlooked something in my
cursory viewing or if these issues have already been hashed out (I've only
just subscribed to this list, in response to your mibs list posting).

On Tue, 21 Jan 2003, Matt Mathis wrote:

> Date: Tue, 21 Jan 2003 15:15:21 -0500 (EST)
> From: Matt Mathis <[e-mail]>
> To: [e-mail]
> Subject: TCP ESTATS design team
>
> We are in the process of assembling a design team to update the TCP extended
> statistics MIB, draft-ietf-tsvwg-tcp-mib-extension-02.txt.    If you would like
> to help with this effort please send a note to Peter O'Neil or me.
>
> The extended statistics MIB will endow TCP with substantial diagnostic
> capabilities.
>
> We will have a new draft for review by the TSVWG in time for the ID cutoff.
> This draft will incorporate the detailed per connection statistics from the
> web100 project and the good transport work that was done by the IPv6 team and
> later determined to be out of scope.
>
> The IPv6 team is finishing up update to rfc2012.  Our document will be an
> extension to it.
>
> Thanks,
> --MM--
> -------------------------------------------
> Matt Mathis      http://www.psc.edu/~mathis
> Work:412.268.3319    Home/Cell:412.654.7529
> -------------------------------------------
>
>
>
>
>

--
Michael Kirkham
www.muonics.com

_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg