Re: [Tsvwg] Re: ESTATS question about ..ConnectIdTable

> 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?

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--
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
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg