tcp_ip_abort_interval algorithm

[blake_15]

Couple questions about tcp keepalive and abort intervals.

I need to change HP-UX networking kernel params
tcp_keepalive_interval, and tcp_ip_abort_interval as they are set too high based on what our application requires.

I understand how the keepalive interval works and have tested it, but I'm a bit stumped on the abort interval. I can see that it will kill the socket after 600000 milliseconds (default), but I don't know how many keepalives will be transmitted in this time, and at what interval. Also, is there a minimum interval between sending keepalives?

Just wondering as we need to set keepalive + abort_interval pretty low, probably something like two minutes or less (time is money here, literally).

Our shop is running two HP-UX 11.0 severs with serviceguard clustered environment.

[Todd Whitcher]

I think you may find Rick Jones annotated ndd guide helpful. It doesnt address your question directly but gives solid advice on hwo to set those tunables.

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt

[blake_15]

Thanks, this doc is far more helpful then ndd help. Unfortunately, as you mentioned, it doesn't discuss details of tcp_ip_abort_interval param.

[Fabio Ettore]

Hi,

you will find the best explaination by the command

ndd -h

so for example

ndd -h tcp_ip_abort_interval

Best regards,
Fabio

[Babu A]

tcp_keepalive_interval:

Interval for sending keep-alive probes.

If any activity has occurred on the connection or if there is any
unacknowledged data when the time-out period expires, the timer is
simply restarted. If the remote system has crashed and rebooted,
it will presumably know nothing about this connection, and it will
issue an RST in response to the ACK. Receipt of the RST will
terminate the connection.

If the keepalive packet is not ACK'd by the remote TCP, the normal
retransmission time-out will eventually exceed threshold R2, and
the connection will be terminated.

With this keepalive behavior, a connection can time-out and
terminate without actually receiving an RST from the remote TCP.
[10000, 10*24*3600000] Default: 2 * 3600000 (2 hours)

These keepalives for an established connection will only be enabled if
the application uses a setsockopt()/t_optmgt() call to enable
keepalives (SO_KEEPALIVE). It is not enabled otherwise. This differs
(rightfully) from the behaviour of tcp_keepalive_detached_interval. A
large number of idle connections, with keepalives enabled, could
generate more keepalive traffic than real traffic. They could also
keep on-demand/dial-up ($$$) links open unnecessarily.

tcp_ip_abort_interval:

Second threshold timer for established connections.

When it must retransmit packets because a timer has expired, TCP
first compares the total time it has waited against two
thresholds, as described in RFC 1122, 4.2.3.5. If it has waited
longer than the second threshold, TCP terminates the connection.
[500,-] Default: 600000 (10 minutes)

This setting will only terminate a connection which is actively trying
to send data to the other end. It will have no effect on a connection
which is simply sitting there waiting to receive data. This parameter
should not be set any lower than the tcp_time_wait_interval, and
really should not be set to any value lower than four minutes without
quite careful deliberation.

Aborting a TCP connection will bypass the TIME_WAIT state, which is an
integral part of TCP's correctness algorithms (the discussion of which
is best left to other documents). To be absolutely compliant with the
spirit of the RFCs, the TIME_WAIT state should last for four minutes.
Given that an aborted connection will not go through TIME_WAIT, it is
best that it too sit for at least four minutes.

This is the second of two timer thresholds for established
connections. The first threshold is tcp_ip_notify_interval - the
point at which TCP will tell IP that it thinks the current route to
the destination might not be any good.

You may also visit link for further information ndd params

http://carumba.com/talk/random/hp.annotated_ndd.txt

all the best,

Babu

[rick jones]

Blake -

To be slighly blunt, if your application needs specific response times, it suggests that the _application_ should be doing its own application-level keep alive instead of depending on the settings of tcp_keepalive_interval and the tcp_ip_abort_interval.

Remember that those settings are _global_ .

Retransmission of the keepalive probe is handled exactly like that of a regular data segment - based on the calculated Round Trip Time and thus Retransmission TimeOut, doubling the RTO each time a given keepalive probe has to be retransmitted. If no response has been received within tcp_ip_abort_interval since the initial keepalive probe (give or take) the connection will be terminated.