HPlogo NS 3000/iX NMMGR Screens Reference Manual > Chapter 4 Network Transport Configuration Screens

Transmission Control Protocol (TCP) Configuration

MPE documents

Complete PDF
Table of Contents
Glossary
Index

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

[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:
  1. The value you configure in the Retransmission interval lower bound field.

  2. 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.

Default value: 4

Range: 0-999




Packet Exchange Protocol (PXP) Configuration


User Datagram Protocol (UDP) Configuration