Subject: [Tsvwg] TCP-ESTATS-MIB questions

From: Kristine Adamson <[email-masked]>
Date: Wed, 25 Feb 2004 07:37:31 -0500

Hello,
   We are beginning to investigate implementing this MIB and have the 
following questions:

- Since there is a separate table for Listeners, I assume that no TCP 
connections in Listen state should be supported in any of the other 
tables, correct?  If so, should the description of 
tcpEStatsConnectionState indicate that listen(2) should never be used, as 
is stated in the version-neutral TCP-MIB for object tcpConnectionState?

- The tcpEStatsConnectIdTable description states that "Entries are 
retained in this table for at least 30 seconds after the TCP connection 
first enters the closed state."  Is this true only of this table and not 
the entries in the other tables?  If so, why does this apply to this 
table?  Doesn't this mean that there could be entries in this table, for 
which there are no corresponding entries in the other tables?           

- tcpEStatsConnectionState has a MAX-ACCESS of read-only, but 
tcpConnectionState in the version-neutral TCP-MIB has a MAX-ACCESS of 
read-write.  Should they both have the same MAX-ACCESS value?

- tcpEStatsDataIpTos: Haven't IPv4 TOS and IPv6 traffic class been 
superceded by DSCP?  Since TOS seems to belong to IPv4, wouldn't it be 
better to use a different name for this object, one that applied to both 
IPv4 and IPv6?

- tcpEStatsDataSndNxt: Should this object have a syntax of 
ZeroBasedCounter32 instead of Integer32?

- tcpEStatsDataStartTimeStamp: What does "start of the connection" mean? 
Does it mean the time the connection entered the Established state?  

- Notifications: with lots of short-lived web connections, couldn't there 
be a flood of notifications for this MIB?  Should there be a scalar object 
that controls whether notifications should be created or not?
 
Thanks!

Kristine Adamson
IBM Communications Server for MVS: TCP/IP Development
Internet e-mail:[email-masked]

---

From: Matt Mathis <[email-masked]>
Date: Wed, 25 Feb 2004 19:57:50 -0500 (EST)

My comments are inline below.

> is stated in the version-neutral TCP-MIB for object tcpConnectionState?

Correct.  I will update the document.  

> which there are no corresponding entries in the other tables?           

This is a feature to make it possible to collect completion stats (total
packets, bytes, retransmissions, etc) for each connection.  To be sure that you
see everything you want to be able to read the stats after the connection 
is really dead.   I don't think the other tables are useful after the 
connection is closed, but I will think about it.

> read-write.  Should they both have the same MAX-ACCESS value?

Writing to tcpConnectionState supports a special function to force connections
closed (as in an mechanism to remotely abort connections).  This has always
been subject to debate (and as far as I know, never implemented).  It doesn't
seem useful in the extended statistics MIB.

> better to use a different name for this object, one that applied to both 

Ooops I am out of date here.   Can you provide a pointer to a similar object in 
some other MIB?

> ZeroBasedCounter32 instead of Integer32?

Nope, because SndNxt in not monotonic.  During a "Tahoe" style loss recovery
SndNxt is pulled back to SndUna.  In modern TCPs this generally happens only
following a timeout, but it is a required part of the TCP specifications.  For
the other sequence numbers, the standard specification for the TCP state
variables happens to be consistent with SNMP counters, even though the TCP
specification predates SNMP by about a decade.

The description should emphasize this point.

> Does it mean the time the connection entered the Established state?  

Correct.  I will fix it.

> that controls whether notifications should be created or not?

Yep.   Here is we discover that I am a TCP geek who is just pretending to know 
something about SNMP.   I will ask my SNMP experts for a revision.

Thanks!   I really do appreciate the feedback.

BTW I will be at the IETF, so I away not be too responsive next week.
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
A good plan today is better than a perfect plan tomorrow.
	- Gen Patton

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