Subject: [Tsvwg] ESTATS question about ..ConnectIdTable

From: Matt Mathis <[email-masked]>
Date: Thu, 2 Mar 2006 13:58:42 -0500 (EST)

I'm thinking we should have pulled all of the RFC4022 ..ConnectionTable
into ESTAT.  This would make ESTATS ..ConnectIdTable a strict superset of
the corresponding table in the TCP MIB.

In practical terms this only requires the addition of ..State and ..Process.

What are the relative merits of leaving it as is, vs making the additions?

Thanks,
--MM--
The latest update to draft-ietf-tsvwg-tcp-mib-extension-08.txt
can be obtained from http://www.web100.org/mib
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------

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

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Thu, 02 Mar 2006 16:36:19 -0800

Hi Matt,

Duping the contents of the tcpConnectionTable would mean keeping
updates to the two tables in sync i.e. any updates to the TCP MIB
(specifically the connection table) in the future would, in most
cases, mean corresponding duplicate work for the estats mib &
vice-versa! Personally, I'd be inclined to avoid the duplication
unless it provides any major benefit.

My 2 cents.

Thanks,
Rajiv.

---

From: Matt Mathis <[email-masked]>
Date: Fri, 3 Mar 2006 09:01:33 -0500 (EST)

(Message reordered for clarity, since I am extending the conversation).

> Matt Mathis wrote:
> >
> > I'm thinking we should have pulled ALL of the RFC4022 ..ConnectionTable

> unless it provides any major benefit.

...or if they were synced now, in the future we might chooses to extend
ESTATS::ConnectIdTable and not TCP::ConnectionTable.

If we could amend the latency behavior of tcpConnectionTable, I would
have used AUGMENTS to add the ID to it rather than creating a whole new table.
Note that changing the latency behavior of tcpConnectionTable is almost
certainly backwards compatible with existing management stations.  (ESTATS
calls for rows to remain for ..ConnTableLatency seconds after connection close,
so the final statistics can be read).

As it currently stands, it strikes me as problematic for anybody trying to
extend it in the future because they will have to decide which table to
AUGMENT.   If we make ..ConnectIdTable a strict superset of ..ConnectionTable
then it is easier to extend ..ConnectIdTable (assuming it is well deployed).

So I think the current situation is the worst of the three options:
->1) Two similar but different tables
  2) Amend the tcpConnectionTable to have row latency and then AUGMENT it.
  3) Make the ESTATS::ConnectIdTable a strict superset of TCP::ConnectionTable.

I actually prefer (2), but would need some help to do so.   I can easily
prepare for (3), but I will not alter the document until I get some advice
from the doctors.

Dan, Bert - Any advice?

Thanks,
--MM--

---

From: Rajiv Raghunarayan <[email-masked]>
Date: Fri, 03 Mar 2006 17:00:43 -0800

Hi Matt,

Please find my comments inline.

> prepare for (3), but I will not alter the document until I get some advice

 From RFC 4022:

tcpConnectionEntry OBJECT-TYPE
     SYNTAX     TcpConnectionEntry
     MAX-ACCESS not-accessible
     STATUS     current
     DESCRIPTION
            "A conceptual row of the tcpConnectionTable containing
             information about a particular current TCP connection.
             Each row of this table is transient in that it ceases to
             exist when (or soon after) the connection makes the
             transition to the CLOSED state."

The tcpConnectionEntry does allow the option of "soon after" - where
"soon after" isn't really defined in the mib or RFC as of now! I'm
not sure if/how this maps to the latency requirements of the ESTATS
mib. But it does provide a hole, and maybe the estats mib could just
augment the tcpConnectionEntry as you're indicating above??

This may require us stating the extra constraints on the "soon after"
clause - maybe this could be done in the estats draft?? I'm not sure
if this is possible?? Maybe Bert or Dan can comment on this option?

Personally, I'm open to any of the options above, but personally I'd
prefer an option that does away with duplicates.

Thanks,
Rajiv.

---

From: Matt Mathis <[email-masked]>
Date: Sat, 4 Mar 2006 08:23:06 -0500 (EST)

Ok you convinced me:  I am going to try to complete these change today, since
the draft is due at 9:00 AM ET.

I was hoping for WGLC on this draft, but I am a little beyond my depth here and
if I make *any* mistakes, we will have to roll another draft.

If you are around at all today *please* call, and I can shoot you something to
look at.

Thanks,
--MM--

---

From: Matt Mathis <[email-masked]>
Date: Sat, 4 Mar 2006 20:11:48 -0500 (EST)

I believe that this draft addresses all of the comments from the MIB Doctor
review plus a number of comments from other people.  It does need further
review, but is is very close to WGLC.

Thanks,
--MM--

---

From: Kristine Adamson <[email-masked]>
Date: Sun, 5 Mar 2006 11:13:50 -0700

Folks, 
   As Ragiv pointed out, the current description of the tcpConnectionTable 
in RFC 4022 states:
"Each row of this table is transient in that it ceases to
 exist when (__or soon after__) the connection makes the
 transition to the CLOSED state."

Ragiv thought that the phrase "or soon after" could be redefined to equate 
to the latency period defined in the ESTATS MIB:
"The additional requirement being that this soon after must be made
equal to the estats definition of tcpEStatsConnTableLatency. And I
suspect that for an implementation that supports the estats mib this
might not be a difficult thing to do.

Having said that, it would still be something that needs to be called
out/specified in one (or both) of the RFCs/drafts. And if/how this
can be done is a question I'd have for the mib doctors. But, if this
can be achieved, this might be the simplest option on hand."

So Matt added the following paragraph in the ESTATS MIB 09 draft:
"In the discussion of tcpConnectionTable row latency in RFC4022
 the words "soon after" are understood to mean after
 tcpEStatsConnTableLatency, such that all rows of all tables
 associated with one connection are retained
 tcpEStatsConnTableLatency after connection close, to permit
 reading final connection completion statistics."

Does that mean the the ESTATS MIB has to Update RFC 4022?  Also, what does 
this mean for products that have already implemented support for the 
tcpConnectionTable.  Does it mean that they don't have to change their 
implementation unless they implement support for the ESTATS MIB? 

Thanks, 

Kristine Adamson
IBM z/OS Communications Server: TCP/IP Development
Phone: (919) 254-7911   T/L 444-7911
Internet e-mail:[email-masked]

---

From: Matt Mathis <[email-masked]>
Date: Sun, 5 Mar 2006 18:34:07 -0500 (EST)

> implementation unless they implement support for the ESTATS MIB?

This does not change products that already implement RFC 4022.  Let me
construct a illustration:

Supposes I have a management application that enforces a software license by
using 4022 to monitor the number of established connections on a system. Since
the agent is allowed to wait (an unspecified) short while after the close
before deleting the row, the management application would be *incorrect* if it
counted table rows without checking the connection state.    ESTATS just
clarifies 4022 by specifying the "short while" to be tcpEStatsConnTableLatency.

Note that many management applications don't care if the connection is already
closed.  For example if you are summing received segments, it is not incorrect
to count segments that arrive after the FIN and the transition to the closed
state because they are (or at least were) part of the connection.

This is the whole point of the tcpEStatsConnTableLatency language in ESTATS:
you can make the rows persist after the close so you have the opportunity to
collect final exit statistics on every connection.

Since ESTATS just clarifies RFC 4022 in a way that does not affect correct
implementations, I doubt it would even count as "an update" as far as standards
process goes.  If somebody does a new implementation of 4022, w/o ESTATS, "soon
after" is still unspecified and the management applications still have to be
cognizant of the potential for delayed row deletion.

I have to say that the language in 4022 was absolutely brilliant: it left just
the right amount of flexibility where it could be "clarified" by ESTATS without
either duplicating the table or creating a circular dependency between the two
documents.   Thank you Rajiv!

This is the whole point of the discussion in section 3.1, on diversity in TCP
implementations.

Thanks,
--MM--