Changing tcp_time_wait_interval ndd parameter

[manoj_pu]

Hello All,

Our application vendor suggested to change tcp_time_wait_interval parameter from 30sec (current value) to 70sec. They have made this suggestion to reduce the network traffic.

Can any one tell me is there any other ndd parameter need to be looked?

Thanks,
Manoj

[Steven E. Protter]

Shalom Manoj,

The utility as root to do this is ndd

It has an interface for you to see options and such.

Permanent boot changes are done at /etc/rc.config.d/nddconf

SEP

[manoj_pu]

Hello Steven,

Thanks for the information.
Actually I am looking for whether any other ndd parameters are dependant to tcp_time_wait_interval.

Regards,
Manoj

[Matti_Kurkela]

This document explains quite a few ndd parameters:

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

For example:
----
tcp_time_wait_interval:

Amount of time TCP endpoints persist in TCPS_TIME_WAIT state.
[1000,600000] Default: 60000 (60 seconds)

The TIME_WAIT interval is an integral part of TCP's correctness algorithms. TCP connections are "named" (uniquely identified) by the four-tuple of local and remote IP address, and local and remote TCP
port number. There is no concept of "this is the N'th connection by this name." So to prevent TCP segments from an old connection being accepted on a new connection, TCP uses the TIME_WAIT state. This preserves TCP information long enough to be statistically certain that all the segments of the old TCP connection by that name are gone.

The HP-UX TCP stack can track literally millions of TIME_WAIT connections with no particular decrease in performance and only a
slight cost in terms of memory. So, it should almost never be the case that you need to decrease this value from its default of 60 seconds.
----

So, tcp_time_wait_interval does not seem (at least, not directly) related to reducing/increasing network traffic. *Restoring* the setting to the *standard* value of 60 s should be harmless anyway.

The application can modify the behavior of the sockets it uses quite a lot by setting the appropriate socket options.

If the application is "biting off more than it can chew", i.e. accepting more incoming connections than it can really handle with an acceptable level of performance, that is completely fixable within the application: there is no need to fiddle with the OS-level settings.

MK

[rick jones]

I would go further and assert that increasing the tcp_time_wait_interval, which defaults to 60 seconds (suggesting someone has already messed with it on your system), from 30 seconds to 70 seconds would make no difference in traffic rates.

The *only* way it could would be if the attempted TCP connection rate involving your system would lead to TCP connection name reuse (local/remote ip, local/remote port) within 70 seconds that wasn't happening at 30 seconds.

If that is the case, it means you will see lower performance.

That your application vendor is suggesting this suggests to me that there is some non-trivial confustion somewhere, or the application from the vendor is quite profligate in its (ab)use of TCP connections. Neither of which is all that encouraging frankly. I would suggest you ask the application vendor to be extremely specific as to why they think changing tcp_time_wait_interval will reduce network traffic - and for that matter why network traffic needs to be reduced.

[Laurent Menase]

changing tcp_time_wait_interval will have almost no real effect like you expect.

no ndd parameter will permit to limit the network traffic.

so you'd better tell your real need.