TCP delayed acknowledgment timer
Data received on a TCP socket has to be acknowledged, either by piggybacking the acknowledgment (ACK) on an outbound data message, or by sending a stand-alone ACK if no outbound data exists for a period of time. The TCP delayed acknowledgment timer allows you to adjust, on a per-socket basis, how long the z/TPF system waits before sending a stand-alone ACK to acknowledge data on a TCP socket.
A stand-alone ACK is sent if two full packets worth of data arrive before the delayed ACK timer expires. This can improve end-to-end throughput when the remote application is sending large amounts of data to the z/TPF system in a short period of time.
A small delayed ACK timer value helps response time, especially when a client connects and the remote node is running slow start processing as described in the TCP architecture. For this situation, the remote node cannot send data from a second packet until the first packet is acknowledged. If the server has a large delayed ACK timer value, it could delay the time it takes for the second packet to flow from the client.
- If the delayed ACK timer value is X, raise the delayed ACK timer value when a remote application sends less than 2 full packets worth of data within X amount of time and the local application is going to respond to that data (send output data) after X time passes. The main type of application profile this fits is the single-threaded request-response model where the z/TPF system is the server. In this case, the remote end sends a request to the z/TPF system (less than 2 packets worth of data), the remote application does not send any more data on the socket until the response to this message is received, and the local (z/TPF) application sends a response N milliseconds after the request arrives. In this situation, raise the delayed ACK timer to a value larger than N to avoid an extra stand-alone ACK and allow the ACK to be piggybacked with the response data packet.
- Raise the delayed ACK timer value for sockets with data flowing into the z/TPF system and little or no outbound data, where the time it takes for 2 full packets to arrive is larger than the value of the delayed ACK timer. If the delayed ACK timer value is 10 ms and 2 or more full packets arrive within 10 ms, the z/TPF system sends the ACK when the second packet is received; the value of the delayed ACK timer is irrelevant because it will not expire. However, if the remote end is sending one-way traffic to z/TPF over a socket at a rate of 2 packets every 30 ms, set the delayed ACK timer to a value larger than 30 ms to avoid extra stand-alone ACKs. In this case, if the timer were set to 10 ms and packets arrive on average every 15 ms, the z/TPF system would send a stand-alone ACK for each packet. With a delayed ACK timer of, for example, 50 ms, the timer would never expire and the z/TPF system would send fewer stand-alone ACKs.
To change the system default value of the delayed ACK timer, use the ZNKEY command with the TCPDELAY keyword specified, or change the value of TCPDELAY in keypoint 2 (CTK2). Use the setsockopt function to change the value of the delayed ACK timer for an individual socket.
This option is valid only for TCP sockets that are using TCP/IP native stack support. The ability to change the delayed ACK timer on an individual socket basis is unique to the z/TPF system.