HP-UX TCP/IP Performance White Paper, March 2008

44
As with the sending side, you can compute the average inbound segment size by dividing the octet count
by the segment count.
2 completely duplicate packets (2920 bytes)
A completely duplicate segment, while not fatal, does indicate a slight problem with either the network or
the remote stack. One of the likely scenarios of a completely duplicate segment is a failure in the remote
stack's Round Trip Time (RTT)/Retransmission Timeout (RTO) mechanisms. This could be because the remote
stack might set the tcp_rexmit_interval_max to too small a value. It could also be that the remote
value of tcp_rexmit_interval_min is too small for the accuracy of the stack's RTT/RTO algorithms.
Another retransmission failure is related to the “fast retransmission” algorithm and those duplicate ACKs. If
the network is reordering but not losing segments, the arrival of out-of-order data could be triggering
enough duplicate ACKs to be sent by this system to trigger the remote system’s “fast retransmission”
algorithm. The remote system then sends a retransmission for data that was not lost, simply delayed by
reordering.
59 packets with some dup. data (64111 bytes duped)
Typically, TCP will send as large a segment as it can whenever it retransmits; starting at the sequence
number at the beginning of what it perceives to be the first lost data in the sequence space. Sometimes, this
retransmitted segment will have more data than the initial transmission, and this can lead to receipt of
segments with some duplicate data. This will only happen when the initial sends were "sub-MSS" in size.
32757 out-of-order packets (34818258 bytes)
This is an indication of how badly the network is either dropping or reordering segments from the remote
systems. The higher this statistic the worse shape the network.
0 packets (0 bytes) of data after window
3422 window probes
This is the number of times remote systems have sent this system zero window probes. It is a lower bound
of the number of times a local application or applications have stopped receiving data from their end of the
connection and the socket buffers have filled.
400852116 window update packets
This is the number of segments received which contained window updates.
2758 packets received after close
Segments received after close can be caused by packet reordering and delay in the network, or by an
application handshake failure.
The handshake failure would be that an application or applications on this system called close() or
shutdown(SHUT_RDWR) before the remote system expected it and the remote system was still sending
data to this system.