Re: [Tsvwg] Re: WGLC for draft-ietf-tsvwg-tcp-mib-extension-10 starts NOW

[Matt Mathis <[e-mail]>]

The document at
http://www.psc.edu/~mathis/TcpExtendedMib/draft-ietf-tsvwg-tcp-mib-extension-XX.txt
Has (almost) all changes below as indicated.   After a just a bit more
inspection, I plan to submit it as the final post-WGLC version of the draft.

Thanks, for helping to make this a better document.
--MM--
On Mon, 3 Jul 2006, Magnus Westerlund wrote:

> Hi,
>
> I have reviewed the draft and have a few comments. I have not followed
> the previous discussion on this document.
>
> 1. Page 16: tcpEStatsConnTableLatency:
>
> Why is the maximum latency value restricted to 30 seconds?

It was not needed, the restriction has been removed.

> 2. Page 19: tcpEStatsListenerHCSynRcvd:
>
> I wonder over these HC values. In most cases they seem to apply to not
> that extreme values, like the tcpEStatsPerfHCDataOctetsOut that clearly
> any decently connected machine may wrap the non HC version within 1
> hours time. Based on this I have two questions:
>
> A. Why are the non HC version existing, I don't see doubling the number
> of meters simply to have 32bit versions of them provides any real benefit.

Strictly speaking the 64 bit counters ("HC") are optional in a spec, but the
32 bit are not.  The convention is to provide 64 bit counters in all
implementations that might wrap in less than an hour.  This permits small
footprint implementations, rapid polling, etc to use "easy" 32 bit counters,
while making 64 bit counters available to people who really needs them.  Once
you pay the cost of a 64 bit counter, there is no significant cost to exposing
the low 32 bits as a separate MIB object, so the 32 bit counters are not
optional.

Two side comments: for TCP throughput counters (octets), it might be rather
difficult to poll 32 bit counters fast enough: 10 Gb/s wraps 32 bits in about
a third of a second.  Also, on a 32 bit SMP system, 64 bit counters can be
extremely expensive. If the protocol processing is not already protected by
appropriate locks, you may need additional locks just to update the MIB
counters.  For the most part this is not a worry for TCP (because of existing
"PCB" locks), but it does come up from time to time.

> B. I get the feeling that the authors have considered a special model of
> how the reader of the MIB should work. A certain access pattern and
> reading the values quite often.

Yes, as described in the overview, this mib is designed to support fast
polling on one row, to monitor or diagnose one connection.   It also supports
other more conventional scanning patterns (e.g. searching down a group of
columns) with the usual sorts of overheads for the particular scan.

> 3. It might be covered somewhere in the SMI framework. However it is not
> clear how one should handle the wrapping of the meters. It seem to rely
> on that you have read it sufficiently often that the wrapping is not an
> issue.

With the HC counters, you should never need to poll more frequently than once
per hour.

> 4. Page 32:
>
> Are there any clear definition of what is considered to be Sender
> Limited, Receiver Limited, and Congestion Limited?

I added stronger definitions and references for Receiver and Congestion
limited.


> 5. Page 43:
> tcpEStatsPathECNSent  OBJECT-TYPE
>         SYNTAX          ZeroBasedCounter32
>         MAX-ACCESS      read-only
>         STATUS          current
>         DESCRIPTION
>            "Number of times CE bits have set ECN."
>         REFERENCE
>            "RFC3168, The Addition of Explicit Congestion Notification
>             (ECN) to IP"
>
> I don't understand the description for this meter. Can you please
> explain what is intended.

Oops, you are correct.  This is not at all clear.  I reviewed and tweaked up
several of the ECN instruments.   I also decided that given the churn around
ECN nonce, the relationshib between tcpEStatsPathECNsignals and
tcpEStatsPathECERcvd is a little too fuzzy, so I clarified ...ECNSignals and
dropped ...ECERcvd entirely.

Thanks again for helping to make this a better document.
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.