tcp_sack_permitted
| Description | If set to 2, TCP always
sends SYN segment with the selective acknowledgment (SACK) permitted option.
If TCP receives a SYN segment with a SACK-permitted option and this parameter
is set to 1, TCP responds with a SACK-permitted option. If the parameter is
set to 0, TCP does not send a SACK-permitted option, regardless of whether
the incoming segment contains the SACK permitted option or not.
Refer to RFC 2018 for information on the SACK option.
| | Default | 2 (active enabled)
| | Range | 0 (disabled), 1 (passive enabled),
2 (active enabled)
| | Dynamic? | Yes
| | When to Change | SACK processing can
improve TCP retransmission performance so it should be actively enabled. If,
in some circumstances, the other side can be confused with the SACK option
actively enabled, set the value to 1 so that SACK processing is enabled only
when incoming connections allow SACK processing.
| | Commitment Level | Unstable
|
tcp_rev_src_routes
| Description | If set to 0, TCP does
not reverse the IP source routing option for incoming connections for security
reasons. If set to 1, TCP does the normal reverse source routing.
| | Default | 0 (disabled)
| | Range | 0 (disabled), 1 (enabled)
| | Dynamic? | Yes
| | When to Change | If IP source routing
is needed for diagnostic purposes, enable it.
| | Commitment Level | Unstable
|
tcp_time_wait_interval
| Description | The time in milliseconds
a TCP connection stays in TIME-WAIT state.
For more information, refer to RFC 1122, 4.2.2.13.
| | Default | 60,000 (60 seconds)
| | Range | 1 second to 10 minutes
| | Dynamic? | Yes
| | When to Change | Do not set the value
lower than 60 seconds.
For more information, refer to RFC 1122, 4.2.2.13.
| | Commitment Level | Unstable
|
tcp_ecn_permitted
| Description | Controls Explicit Congestion
Notification (ECN) support.
If this parameter is set to 0, TCP does not negotiate with a peer that
TCP supports the ECN mechanism.
If this parameter is set to 1 when initiating a connection, TCP does
not tell a peer that TCP supports the ECN mechanism.
However, TCP tells a peer that it supports the ECN mechanism when accepting
a new incoming connection request, if the peer indicates that the peer supports
the ECN mechanism in the SYN segment.
If this parameter is set to 2, in addition to negotiating with a peer
on the ECN mechanism when accepting connections, TCP indicates in the outgoing
SYN segment that it supports the ECN mechanism when TCP makes active outgoing
connections.
Refer to RFC 3168 for information on ECN.
| | Default | 1 (passive enabled)
| | Range | 0 (disabled), 1 (passive enabled),
2 (active enabled)
| | Dynamic? | Yes
| | When to Change | ECN can help TCP
in handling congestion control better. However, there are existing TCP implementations,
firewalls, NATs, and other network devices that are confused by this mechanism.
These devices do not comply to the IETF standard.
Because of these devices, the default value of this parameter is set
to 1. In rare cases, passive enabling can still cause problems. Set the
parameter to 0 only if absolutely necessary.
| | Commitment Level | Unstable
|
tcp_conn_req_max_q
| Description | The default maximum
number of pending TCP connections for a TCP listener waiting to be accepted
by accept(3SOCKET).
See also tcp_conn_req_max_q0.
| | Default | 128
| | Range | 1 to 4,294,967,296
| | Dynamic? | Yes
| | When to Change | For applications
such as web servers that might receive several connection requests, the default
value might be increased to match the incoming rate.
Do not increase the parameter to a very large value. The pending TCP
connections can consume excessive memory. And if an application is not fast
enough to handle that many connection requests in a timely fashion because
the number of pending TCP connections is too large, new incoming requests
might be denied.
Note that increasing tcp_conn_req_max_q does not
mean that applications can have that many pending TCP connections. Applications
can use listen(3SOCKET)
to change the maximum number of pending TCP connections for each socket. This
parameter is the maximum an application can use listen()
to set the number to. This means that even if this parameter is set to a very
large value, the actual maximum number for a socket might be much less than tcp_conn_req_max_q, depending on the value used in listen().
| | Commitment Level | Unstable
|
tcp_conn_req_max_q0
| Description | The default maximum
number of incomplete (three-way handshake not yet finished) pending TCP connections
for a TCP listener.
For more information on TCP three-way handshake, refer to RFC 793. See
also tcp_conn_req_max_q.
| | Default | 1024
| | Range | 0 to 4,294,967,296
| | Dynamic? | Yes
| | When to Change | For applications,
such as web servers that might receive excessive connection requests, you
can increase the default value to match the incoming rate.
The following explains the relationship between tcp_conn_req_max_q0 and the maximum number of pending connections for each socket.
When a connection request is received, TCP first checks if the number
of pending TCP connections (three-way handshake is done) waiting to be accepted
exceeds the maximum (N) for the listener. If the
connections are excessive, the request is denied. If the number of connections
is allowable, then TCP checks if the number of incomplete pending TCP connections
exceeds the sum of N and tcp_conn_req_max_q0. If it does not, the request is accepted. Otherwise, the oldest
incomplete pending TCP request is dropped.
| | Commitment Level | Unstable
| | Changes From Previous Release | For
information, see tcp_conn_req_max_q0.
|
|
Previous