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 Screen
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
or
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-4096
- 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.
Default value: 4
Range: 0-999