Subject: [Tsvwg] Re: TCP ESTATS design team

From: Michael Kirkham <[email-masked]>
Date: Fri, 31 Jan 2003 09:13:20 -0800 (PST)

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 <[email-masked]>
> To: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Matt Mathis <[email-masked]>
Date: Fri, 31 Jan 2003 15:44:48 -0500 (EST)

Thanks for the comments.

About "denote plurality", yes, we got it wrong.   The current document follows 
a prototype which doesn't use SNMP at all.  We were unaware of the naming 
convention and I am sure we missed others too.  This will get fixed.

About indexing - we know we have a problem here, but I don't know enough about 
SNMP (I am a TCP guy) to grasp the subtleties.  There are two main issues:

1) We want to support a fast way to poll on a known connection. The "generic"
approach (again, used by the non-SNMP prototype) is to have a general (but
slow) way to search a table to find a specific 4-tuple.  This yields 
a "Connection ID" which is an opaque int.  The Connection ID can then be used 
for fast polling on any variables in the logical row.

2) We want to be able to support sparse tables to reduce the memory load on a 
busy server.   The current draft has controls per group of columns 
(which are actually separate smaller tables.)   We are considering putting in 
per-connection controls as well.

I will be defering to people with more MIB expertics on the details.

BTW there is a document status page at http://www.web100.org/mib

Thanks again for taking the time to look at the document,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------