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

milliseconds. A 1% retransmission rate implies that one packet out of 100 is being retransmitted. An ssh

session is not necessarily going to have "fast" retransmits, and the default value for

tcp_rexmit_interval_min is 500 milliseconds. This means that the weighted average for keystroke

round-trip time (i.e. echo) is going to be:

0.99 * 10 milliseconds + 0.01 * 500 milliseconds

which works-out to 14.9 milliseconds - that 1% retransmission rate is adding nearly 50% to the average

response time.

It also means that one character out of 100, or as often as once every few lines typed, there will be a half-

second "hiccup" in the flow of characters. Whether or not this is noticed by the person typing depends on

just how good a typist they happen to be.

198929341 ack-only packets (19851063 delayed)

This is the number of segments transmitted that were "standalone" ACKs - ie ACKnowledgement segments

that were not also carrying window updates or piggy-backed on data segments. As such, they were pure

overhead - in broad hand-waving terms, especially with NIC functionality like Checksum Offload (CKO)

and copy-avoidance (eg sendfile() ) sending (or receiving) an ACK is just as expensive in terms of CPU

consumption as sending a data segment.

The numbers of "delayed" ACKs are those that were sent after the standalone ACK timer expired (related

ndd: tcp_deferred_ack_interval). There are some situations that call for an immediate standalone

ACK - for example when a SYNchronize segment is received to initiate a new connection a SYN|ACK is

sent immediately.

Another situation that requires an immediate ACK is the receipt of out-of-order data. When out-of-order

data is received, TCP is required to send an immediate ACK specifying which data it was expecting to

receive next. For example, if the remote system sent us TCP segments 1, 2, 3, 4 and 5, but segment two

was either lost or delayed, we would sent-out an immediate "ACK 2" upon receipt of segments 3, 4 and 5.

If the standalone ACK timer expired to cause the transmission of the ACK, it implied that none of the other

piggy-back or immediate ACK transmission rules were in effect. This could still be harmless – for example,

in a request/reply application with long times between transactions or long transaction processing times (ie

longer than tcp_deferred_ack_interval) standalone ACK's will be sent - either to ACKnowledge the

receipt of the response (long time between transactions) or of the request (long transaction processing time)

or both.

Another situation that leads to standalone ACK's are those applications which provide logically associated

data to the transport in separate socket calls. This is sub-optimal because if those different pieces are

smaller than the MSS (Maximum Segment Size), the application will run afoul of the Nagle algorithm

(related to the TCP_NODELAY socket option), which is in TCP to help make sure that the average segment

size is reasonably large.

10 URG only packets

This is the number of segments which contained URGent data.