Some intermediate nodes (for instance, load balancers or firewalls) use data traffic as an indication that the TCP connection is still alive. If no data flows across the TCP path for a long enough period, the intermediate node might reset the connection. TCP keepalive processing periodically sends packets over the TCP connection to prevent the connection from being reset.
The rendezvous negotiations to use SMC-R communications occur over the TCP connection. After the decision to switch to SMC-R protocols is made, the TCP connection remains active, but only termination messages flow over the TCP connection as needed. The application socket data flows out of band by using RMDA protocols. Thus, a TCP connection that is using SMC-R can be viewed as using two paths:
Because the TCP connection does not use the TCP path to exchange data packets, intermediate nodes might consider the connection to be idle for long periods. For TCP connections over SMC-R, keepalive processing must ensure that both the TCP path and the SMC-R path remain operational.
For traditional TCP connections, the time interval that is used to send keepalive probes is determined by using the following sequence:
For a TCP connection that is traversing an SMC-R link, the time interval that is used to send keepalive probes on the SMC-R path is determined by using the same method because the SMC-R path is where the actual data flows. For these connections, however, use of this same method for the TCP path can generate excessive keepalive probe traffic, so a separate method is used to determine the keepalive time interval for the TCP path. This method uses the larger of the GLOBALCONFIG SMCR TCPKEEPMININTERVAL value, the TCPCONFIG INTERVAL value, and the TCP_KEEPALIVE setsockopt() value.
For example:
In this case, the time interval for both the SMC-R path and the TCP path is 120 minutes.
In this case, the time interval for the SMC-R path is 5 minutes, but the time interval for the TCP path is 15 minutes.