Subject: RE: [Tsvwg] TCP Extended Statistics MIB

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 4 Nov 2002 20:03:46 -0600

Doh - I meant "Matt", of course. A-gain.

Sorry!

Spencer, who expects to be slugged by Mark Allman in Atlanta if I don't stop doing this...

-----Original Message-----
From: Spencer Dawkins 
Sent: Monday, November 04, 2002 7:06 PM
To: Matt Mathis
Cc: [email-masked]
Subject: RE: [Tsvwg] TCP Extended Statistics MIB

Mark,

- Is there a canonical list of "consistency checks", as used in tcpEStatsDataSoftErrors and
tcpEStatsDataSoftErrorReason (part of TCP Data Table)?

- The description for tcpEStatsPathAckAfterFR ties the variable to Eifel - would the same variable be used for prematurely retransmitted data, no matter how detected?

- Should a variable for "number of times Limited Transmit is invoked" be included in the TCP Path table? (pro: it's a proposed standard, con: it's not widely deployed, pro: ECN is included and it's not widely deployed, either ... )

Thanks again for taking this work on!

Spencer
_______________________________________________
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: Tue, 5 Nov 2002 17:30:13 -0500 (EST)

> Doh - I meant "Matt", of course. A-gain.
No problem.  You are not the first to confuse us.

> tcpEStatsDataSoftErrorReason (part of TCP Data Table)?

There should be....  There are some open issues here: Some of the events can be
pretty common.  e.g. belowDataWindow (meaning data arriving at the receiver
that has already been ACKed) would include duplicate data after retransmission
as well as window probes and keep alives.  These are common enough that they
would mask some infrequent but really interesting events such as
aboveDataWindow or aboveAckWindow which only happen if the sender has a bug or
is engaged in mischief (e.g. not honoring rwin).

Second, the merits of counting CRC errors is a little dubious.  We felt that
the data was valuable enough to be worth the headaches.  The metric is
intrinsically noisy, because the CRC error may mean that the addresses or ports
are corrupted.  However, in the prototype we even ran into an additional class
of problems because the CRC check happens well before the connection lookup.  
It proved to be problematic to restructure the code just to support 
instrumenting CRC errors.

Minor SMI technicality - I don't know what the syntax is supposed to look like 
for descriptions on enumerated integers.

> - The description for tcpEStatsPathAckAfterFR ties the variable to Eifel - 
> would the same variable be used for prematurely retransmitted data, no matter 
> how detected? 

Yep - Although "e.g." is an abbreviation of the Latin for "for example" - I 
guess it doesn't belong in an ID.  'tis spelled out for the next draft.

> - Should a variable for "number of times Limited Transmit is invoked" be 
> included in the TCP Path table? (pro: it's a proposed standard, con: it's not 
> widely deployed, pro: ECN is included and it's not widely deployed, either ... )

Although I believe in limited transmit (we investigated something very similar
in connection with our FACK work), it's impact is embodied through the number
of timeouts.  If you have zero timeouts, you don't know if limited transmit
helped, if you have many timeouts, you can't tell if limited transmit would
have helped/didn't help.  By definition limited transmit does not effect cwnd,
except through avoiding timeouts.

I haven't adequately keep a list of "maybe" instruments that might be subject 
to future debate.   This will be first on the list.

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