The Transmission Control Protocol (TCP) Configuration screen (#94) in
Figure 4-6 "Transmission Control Protocol (TCP)
Configuration Sxreen" is displayed when you press the [Go To TCP]
function key at the General Protocol Configuration screen
(Figure 4-4 "General Protocol Configuration
Screen"). It is also displayed when you type the path name:
@NETXPORT.GPROT.TCP
in the command window of any screen and press the [Enter] key.
Figure 4-6 Transmission Control Protocol (TCP) Configuration Sxreen
This screen lets you enter the information necessary to configure transmission
control protocol (TCP) for the node. TCP is required in order for the network
transport to function. Press the [Save Data] function key to transfer
the data displayed on the screen to the configuration file you are creating or
modifying. Verify that the data record has been created by checking that the
Data flag is set to Y.
This screen provides the necessary information for the operation of the TCP
protocol. The information configured falls into three categories:
Reliability (checksum field).
Sizing parameters (maximum connections fields).
Performance parameters (retransmission fields).
The algorithm used for congestion and flow control is based on the Van
Jacobson algorithm which uses the initial retransmission timeout for
most calculations. The initial retransmission timeout is the greater of the
following two values:
The value you configure in the Retransmission interval lower bound
field.
The calculated smooth round trip (SRT) time which is automatically
calculated based on the average round trip time from the last few
send and acknowledgement packet timestamps.
The TCP retransmission algorithm works as follows:
Once a packet is sent, the local node waits for a response from
the remote node. If a response is not received before the initial
retransmission timeout, the packet is transmitted again.
The algorithm uses a multiplier of 2. For each time that a packet
is retransmitted, the multiplier is doubled, thus exponentially
increasing the wait time. Given an initial retransmission timeout of
X seconds, the sequence of timeout values would be X, 2X, 4X, 8X
seconds and so on.
Retransmission is stopped when either one of the following
happens:
The time configured in maximum time to wait for remote
response is reached. This happens when the total time of all
retransmission intervals would exceed the maximum time to wait
for remote response.
The number of retransmissions configured in maximum
retransmissions per packet is reached.
Let us take an example using the default values. Assume that the calculated
smooth round trip is 1 second. Since the retransmission interval lower bound
(4 secs) is the greater of the two, its value is used as the initial
retransmission timeout. If the node does not get an acknowledgement after 4
seconds, the packet is retransmitted. If there is still no acknowledgement, the
retransmission of the outstanding packet would be at intervals of 4, 8, 16, and
30 seconds. The connection would be broken after 30 seconds because a maximum
of 4 retries is allowed.
Needless retransmissions may occur if you set retransmission interval lower
bound low and you set maximum time to wait for remote response and maximum
retransmissions per packet high. If the retransmission interval lower bound is
set too high, an unnecessarily long delay occurs when a packet is lost, and a
retransmission will be necessary.
Connections may be prematurely aborted if you set retransmission interval lower
bound low and you set maximum time to wait for remote response or maximum
retransmissions per packet low. All of these retransmission fields are
configurable to optimize connection performance. Values to be entered for the
retransmission fields should, in general, reflect the average load on system
resources at the local node, the remote node, and the intervening network(s),
if any. The optimal values for these fields can be determined only by
experience for each node.
Fields
Checksum enabled
Checksumming is a method of error checking used for reliability. TCP
checksumming causes a very slight overhead. It is not normally needed
over most reliable link types. Also, error checking is provided for at
the link level. For these reasons, HP recommends the default value
(N) for this field so that checksumming will be disabled for
this protocol.
The checksum decision for a given connection is determined from several
sources:
The destination path report in the network directory or
probe.
The local configuration (as specified in this screen).
The values specified in the NetIPC intrinsics,
IPCCONNECT and IPCRECVCN.
Should any of these sources indicate checksumming enabled, the connection
will be checksummed.
The effect of disabling checksum in the configuration is not to prohibit
checksumming, but simply to allow each connection to choose for itself.
The Network Services specify checksumming disabled in their NetIPC calls
thereby allowing control to be taken through the configuration and
network directory. Therefore, TCP checksumming for Network Services must
be specified in the TCP Configuration screen (via the checksum enabled
field), or within the network directory.
Default value: N
Range: Y or N
Maximum number of connections
This is a sizing parameter that allows you to configure the number of
connections based on the size of your network (how many users there are).
Each connection functions as a separate entity in regard to destination,
flow control and retransmissions. TCP connections and NetIPC have a
one-to-one correspondence for calls to IPCCONNECT, and therefore
between each Network Service invoked by each user. There is no
multiplexing of user or Network Services data over TCP connections.
The number of connections configured should reflect an estimation of the
number of Network Services and NetIPC users that will be active
simultaneously. This includes both outbound and inbound connections. The
value configured should be relatively large to accommodate expansion.
Note that the allocation of buffers is related to the number of TCP
connections. If this field is modified, the NI screens controlling buffer
allocation (NETXPORT.NI.NIname for outbound buffers, and
NETXPORT.NI.NIname.PROTOCOL.IP for store and forward buffers)
must be updated.
Default value: 128
Range: 1-20000
Retransmission interval lower bound (Secs)
The retransmission interval is the smallest interval (in seconds) that
a TCP connection waits for a reply from a remote node before
retransmitting a packet. If the calculated SRT time is greater than this
value, then the SRT time is used for retransmission. Increase the value
if connections are being dropped prematurely or if there is too much
traffic due to packet retransmission.
Default value: 4
Range: 1-999
Maximum time to wait for remote response (sec)
This is the total time allowed for retransmissions. Increase this
value if connections are being dropped prematurely. Decrease this value
if there is too much traffic due to packet retransmission.
Default value: 180
Range: 10-32767
Initial retransmission interval (secs)
This field sets the initial amount of time that TCP will wait for a
reply from a remote node before attempting to retransmit a packet. This
value is used for connection setup when the retransmission interval has
not yet been calculated. It should be greater than the retransmission
interval lower bound.
Default value: 5
Range: 2-999
Maximum retransmissions per packet
This is the maximum number of times that TCP will retransmit a packet
before aborting the connection. Increase the value if connections are
being dropped prematurely. Decrease the value if there is too much
traffic due to packet retransmission.
Default value: 4
Range: 1-100
Connection assurance interval (secs)
This timer allows you to adjust the time you wait for resources to be
released after an idle disconnect. If the remote connection is abruptly
interrupted, TCP waits for the amount of time calculated by the following
algorithm:
CAinterval + (CAinterval * MAXCARTX)
where CAinterval is the connection assurance interval and
MAXCARTX is the maximum connection assurance retransmissions.
TCP drops the connection thus freeing all resources held by that
connection. Increase this value if you are experiencing too much overhead
for retries due to idle disconnects. Decrease this value if you are
waiting too long for resources to be freed due to idle disconnects.
Default value: 600
Range: 10-32767
Maximum connection assurance retransmissions
This is the maximum number of times that TCP will transmit a
connection assurance packet to a non-responding remote system. Together
with the connection assurance interval, this value defines the time it
will take for an idle connection to abort if the remote TCP fails to
respond. Unlike the retransmission timer, a backoff algorithm is not
used. Therefore, the timeout period is calculated as follows:
CAinterval + (CAinterval * MAXCARTX)
where CAinterval is the connection assurance interval and
MAXCARTX is the maximum connection assurance retransmissions.