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

The other events that control the ACK generation are the following:

• Arrival of out of order segment

• Time to send a window update as the application consumed enough data.

Using delayed ACKs has very little impact on transmission reliability since ACKs are cumulative.

Furthermore, delayed ACKs conserve resources by decreasing the load on the network and the cpu that

must generate and process these ACK segments. Delayed ACKs have been found to have a positive impact

on the performance of bulk transfer.

tcp_delay_final_twh_ack:

Piggyback the final ACK of the three way TCP connection

establishment with the data by delaying the final ack by

10ms.

0: Send the final ACK as soon as the SYN+ACK packet

arrives from the remote host.

1: Delay the sending of the final ACK by 10ms. If

there is data available to be sent with in the

next 10ms, piggyback the ACK for the SYN.

[0-1] Default: 1

tcp_early_conn_ind:

If set to 1, a T_CONN_IND message is sent upstream as soon as a

SYN packet is received from a remote host which is on the TCP's

'good guy' list. A remote host goes on the 'good guy' list if it

is known to have completed the 3-way handshake earlier.

If set to 0, the T_CONN_IND message is not sent upstream until

the 3-way handshake is complete, even if the remote host is

on the 'good guy' list. [0,1] Default: 1

tcp_fin_wait_2_timeout:

Determines how long a TCP connection will be in FIN_WAIT_2.

Normally one end of a connection initiates the close of its end

of the connection (indicates that it has no more data to send) by

sending a FIN. When the remote TCP acknowledges the FIN, TCP

goes to the FIN_WAIT_2 state and will remain in that state until

the remote TCP sends a FIN.

If the FIN_WAIT_2 timer is used, TCP will close the connection

when it has remained in the FIN_WAIT_2 state for the length of

the timer value.

The FIN_WAIT_2 timer must be used with caution because when TCP

is in the FIN_WAIT_2 state the remote is still allowed to send

data. In addition, if the remote TCP would terminate normally

(it is not hung nor terminating abnormally) and the connection is

closed because of the FIN_WAIT_2 timer, the connection may be

closed prematurely. Data may be lost if the remote sends a

window update or FIN after the local TCP has closed the

connection. In this situation, the local TCP will send a RESET.