Subject: RE: [Tsvwg] TCP Extended Statistics MIB

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 11 Oct 2002 13:38:02 +0200

Just did a MIB compile and I get these SMICng errors/warnings:

  E: f(estats.mi2), (1702,32) Item "tcpEStats" is not defined as 
     an OBJECT-GROUP or NOTIFICATION-GROUP in module "TCP-ESTATS-MIB"
  E: f(estats.mi2), (1703,32) Item "tcpEStatsControl" is not
     defined as an OBJECT-GROUP or NOTIFICATION-GROUP in module
     "TCP-ESTATS-MIB"
  E: f(estats.mi2), (1704,32) Item "tcpEStatsNotifications" is not
     defined as an OBJECT-GROUP or NOTIFICATION-GROUP in module 
     "TCP-ESTATS-MIB"
  W: f(estats.mi2), (1710,8) OBJECT-GROUP "tcpEStatsGroup" is not
     used in a MODULE-COMPLIANCE in current module
  W: f(estats.mi2), (1807,8) OBJECT-GROUP "tcpEStatsControlGroup"
     is not used in a MODULE-COMPLIANCE in current module

And the following from SMILINT

  output of smilint -l 9 follows,
  empty output means everything is fine.
  --start--
  1710: warning: current group `tcpEStatsGroup' is unconditionally optional
  1807: warning: current group `tcpEStatsControlGroup' is unconditionally optional
  --end--

Bert
> -----Original Message-----
> From: Matt Mathis [mailto:[email-masked]]
> Sent: donderdag 10 oktober 2002 23:02
> To: [email-masked]
> Subject: [Tsvwg] TCP Extended Statistics MIB
> 
> 
> 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-X
> X.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
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Matt Mathis <[email-masked]>
Date: Sat, 12 Oct 2002 09:01:56 -0400 (EDT)

Ummm, thanks, however these messages mean nothing to most people on this list (including 
me). 

This list is the right community to address transport issues: is the coverage
appropriate?  Did I miss instrumentation for your favorite algorithm? Is it 
future proof? etc

On the SNMP side of the house the errors below are minor compared to other more
serious issues pertaining to process, MIB merging, dataa types, etc.  The list
on the status page http://www.web100.org/mib/ is pretty long.  I would rather
start these conversations in a more SNMP centric community and not bother the
transport people with the thrilling details.

But first I need to recruit some more SNMP help, because I know very little
about MIBs and such.  - I'm just good a faking it.

I will take this as an offer to help -

Thank you!
--MM--