HP 3000 Manuals HP 3000 Manuals
Transmission Control Protocol (TCP) Configuration The Transmission Control Protocol (TCP) Configuration screen (#94) in figure 4-6 is displayed when you press the [Go To TCP] function key at the General Protocol Configuration screen (figure 4-4). 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) Config 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 algorithmwhich 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 Checksummingis 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 This is a sizing parameter that allows you to connections 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 The retransmission interval is the smallest lower bound (Secs) 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 This is the total time allowed for remote response (sec) 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 This field sets the initial amount of time that interval (secs) 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 This is the maximum number of times that TCP per packet 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 This timer allows you to adjust the time you interval (secs) 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 This is the maximum number of times that TCP assurance will transmit a connection assurance packet to retransmissions 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 MAXCARTXis the maximum connection assurance retransmissions. Default value: 4 Range: 0-999
![[]](../../pic3k/M013437/FFN203c50.gif)