Subject: [Tsvwg] TCP Extended Statistics MIB

From: Matt Mathis <[email-masked]>
Date: Thu, 10 Oct 2002 17:01:36 -0400 (EDT)

As many of you are aware, the web100 project has been working on an extended 
statistics MIB for TCP.  This "TCP-ESTATS-MIB" would provide measurement and 
diagnostic information about TCP and its environment.   Some possible uses 
include:

TCP performance diagnostics: why is my application running so slowly?

Negotiated Features:  Are SACK and Timestamps really turned on?

Measure path properties: What is the loss rate and RTT while under full load?

Is the application keeping up, or is it the bottleneck?

The most recent draft (-01bis) can be obtained from
http://www.web100.org/mib/draft-ietf-tsvwg-tcp-mib-extension-XX.txt This
already has a number of differences from the prior IETF version
draft-ietf-tsvwg-tcp-mib-extension-01.txt.  Comments received in the next few 
weeks will be reflected in the draft due Nov 4th (cutoff for the Atlanta IETF).

Note that the IPv6MIB team already has RFC2012 (the old TCP MIB) open for
revision.  Our "plans" for merging the documents are described in the document
introduction and on the status page at http://www.web100.org/mib/ .  This
status page will be updated to reflect my sense of the community and any
evolving debate.

For the transport community I have only a couple of open issues:

Is the MIB complete?  Did I overlook something that you would like to
observe about TCP in the field?

What is the best terminology: bytes or octets?  The term octet comes from a
time when byte was ambiguous due to the prevalence of 36 bit computers with 6
bit bytes.  But even RFC1122 finds it necessary to define octet.  Most papers
today use bytes, but standards are mixed.  Before we repeat it here, can
somebody cite an old mail dialog on this issue?

The historical and revised MIBs [RFC2012 and RFC2012bis] contain a false
optimization re: excluding retransmitted data from some instruments such as
tcpOutSegs. The problem is that there are many different code paths that cause
retransmission (Tahoe, classic fast retransmit, NewReno, SACK, etc) but the
accounting is done much later, after the headers are built. Implementing this
correctly requires reconstructing why the segments is being sent (not too hard,
but still not clean) A far better approach is to take the view that there are
two classes of statistics: measures of IP resources consumed (packets and bytes
in and out, etc for all reasons)  and measures of application performance
(total advance of the ACK fields). Then
DataBytesTransmitted-DataBytesAcked(-CurrentWindow) is an exact measure of data
bytes retransmitted. I would still keep the direct measures of retransmissions
(tcpRetransSegs, etc) but I would scratch all of the language "(in/ex)cluding
retransmitted segs/octets".  The extended stats are already written this way, I
would also revise the summary and per connection stats in [RFC2012bis].

Although this is a change from past definitions, I believe that there are zero
applications that care. 

Several other more SNMP specific issues are described on the status page:
http://www.web100.org/mib/

Feedback is encouraged.  We would like to push this into the standards track as 
soon as practical.  Even positive feedback would be a help.   Please use the 
tsvwg list.

Thanks,
--MM--
----------------------------------------------
Matt Mathis <[email-masked]>    W:412.268.3319
http://www.psc.edu/~mathis      H:412.654.7529
----------------------------------------------

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 11 Oct 2002 10:30:42 -0500

Hi, Mark,

This is great work (especially compared to what you can tell about a TCP connection using the current MIB!).

I noticed there's no reference to Limited Transmit (RFC 3042) in the TCP Path table. Is this intentional, or based on (lack of) deployment to date?

http://www.ietf.org/internet-drafts/draft-ietf-pilc-2.5g3g-10.txt (currently in IESG review) recommends Limited Transmit, and I would expect OMA to pick this up for their "Wireless Profiled TCP" (the current version of their spec tracked PILC's recommendations pretty closely).

tcpEStatsPathAckAfterFR seems to accomodate the variety of spurious timeouts detected by a variety of mechanisms (Eiffel, D-SACK, F-RTO), so seems rather future-proof - I'm just looking for the leading-edge mechanisms I know about, to see whether they've been included or not. Limited Transmit is the only omission I've noticed so far.

Spencer

-----Original Message-----
From: Matt Mathis [mailto:[email-masked]]
Sent: Thursday, October 10, 2002 4:02 PM
To: [email-masked]
Subject: [Tsvwg] TCP Extended Statistics MIB

Thanks,
--MM--

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 11 Oct 2002 12:32:53 -0500

Hi, Matt,

I forgot to have Aaron check my posting for nits! Sorry...

Spencer

(and thanks, Aaron!)

-----Original Message-----
From: Aaron Falk [mailto:[email-masked]]
Sent: Friday, October 11, 2002 11:57 AM
To: Spencer Dawkins
Subject: Re: [Tsvwg] TCP Extended Statistics MIB

> Hi, Mark,

Spencer-

I think you meant "Matt."

--aaron

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 13 Oct 2002 12:12:23 +0200

Sure, I will try yo get some of the IPv6MIB design team
people to participate. List me your proposed team members
and we can get started.

Thanks,
Bert 

> From: Allison Mankin [mailto:[email-masked]]
> Sent: zaterdag 12 oktober 2002 17:09
> To: Wijnen, Bert (Bert)
> Cc: Matt Mathis; [email-masked]
> Hi, Bert,
> We have this MIB discussion in TSVWG, but we are trying
> to closely coordinate it with the TCP MIB that is
> an item in the IPv6 working group.  
> 
> I think we should actually create a team of folks to
> review the extended statistics MIB for content and 
> for its correctness/fit with the TCP MIB, and report back.  
> What do you think?  I have some ideas for folks, but this
> would be a good time for volunteers to speak up.  This
> is before the MIB doctor expert review, but I agree that
> the compilation should have been kept up :/
> 
> Allison
>