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

43
66 window probe packets
A window probe is sent after a remote TCP has advertised a window of zero bytes for some period of time.
The intent of the window probe is to solicit a window-update from the receiving TCP.
If the receiving TCP advertised a zero window, it means that the receiving application stopped reading
data from its end of the connection. This could mean that the remote application is not receiving enough
CPU cycles and thus gives the appearance of being hung, or it could mean that the remote application is
indeed "hung" for some reason - blocked on some other resource or stuck in a tight loop.
HP-UX 11i TCP uses the calculated TCP Retransmission Timeout (RTO) values for its "persist timer" which
triggers the zero window probes.
720391 window update packets
These are the number of segments sent which contained window updates.
562952 control packets
These are segments such as SYN, FIN, or RST that are "control" segments.
624402552 packets received
This is the total number of segments received.
222995941 acks (for 3530654798 bytes)
This is how many of the received segments contained ACK's and how many octets (bytes) those ACKs were
acknowledging.
354710 duplicate acks
This is the number of duplicate ACK's we have received. If a TCP connection receives three duplicate ACKs
in a row, it will trigger a so called "fast retransmission." While this statistic gives the total number of
duplicate ACK's it does not tell us enough about their distribution to know how often there were three or
more in a row. However, one might make some educated guesses based on the "data packets
retransmitted" and "retransmission timeout" statistics.
0 acks for unsent data
This should always be zero. If the stack is receiving ACK's for data the stack did not send, it means that
something may be seriously wrong - most likely is the remote stack thinking it has received data we didn't
actually send, less likely in this stack forgetting what data it has sent. In addition to actual bugs in the
stack(s) this could also be triggered by some rogue entity spoofing packets in an attempt to hijack a TCP
connection.
When the local stack receives an ACK for data it does not believe it has sent, it is considered a serious TCP
violation and the connection is summarily aborted with a RST segment.
434810727 packets (2860544293 bytes) received in-sequence
This is the total number of segments received in order. Receiving data in order is good - it means that no
segments were reordered (on the part of the network) or lost (suggesting other network problems).