Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!CCV.BBN.COM!brescia
From: brescia@CCV.BBN.COM.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: tcp counters
Message-ID: <8702252011.AA06273@ucbvax.Berkeley.EDU>
Date: Wed, 25-Feb-87 14:50:19 EST
Article-I.D.: ucbvax.8702252011.AA06273
Posted: Wed Feb 25 14:50:19 1987
Date-Received: Fri, 27-Feb-87 20:46:19 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 36
Approved: tcp-ip@sri-nic.arpa


For each type of host implementation of IP/TCP/TELNET, where may the tcp error
counters be found?  I realize that some UNIX(tm) systems and derivatives
provide a netstat command with a '-s' option that gives the following counters
for the tcp level.

tcp:
	0 bad header checksums
	0 bad header offset fields
	0 incomplete headers

The information I am looking for is a measure (either per-connection or over
the whole operation of the tcp protocol layer)

 retransmissions - count of segments resent because ack was not returned in time
 redundant receives - count of segments received more than once
 estimated round trip time (per connection) - delay to destination
 retransmission time (or algorithm from est. RT time)
 route (on UNIX() can get this from netstat -r) - gateway or interface used
 when a connection is closed, the reason for closing


For your implementation, are these sort of numbers available to me, a lowly
user, and if not, can a wizard get them using some debugging magic?

Implementations ::= { tops20, 4.*bsd, bbnos, ultrix 1.*, 2.*, vms(wolongong),
		      many others? }

I have taken a call from a user who is unable to reliably get from host A to
host B, in that the connections hang for long periods of time, and frequently
break (connection closed).  While there are 3 different kinds of gateway in
this particular path, I think the routing and traffic load are stable enough
to support useful ftp and telnet service.  I want to be able to have her call
her host wizard to find out what is failing at the end points.

	mike