Jeff Kell ([log in to unmask]) wrote:
: In a more general sense, does NS/VT use keepalives?  It seems not since
 
 - Everything that runs over tcp/ip on MPE/iX uses TCP keepalive.  It is not
   up to the application level to do anything about this (i.e. VT nor any
   other OSI level 6/7 stuff) - there's not even an option for it.
 
   It's all in TCP's hands and NMMGR screen NETXPORT.GPROT.TCP has two
   parameters for TCP keepalive (or TCP Connection Assurance or CA) with
   the following default values:
 
   [600  ]   Connection Assurance Interval (Secs)
   [4  ]     Maximum Connection Assurance Retransmissions
 
   What this means is that every 600 seconds the timer will pop and a CA
   keepalive packet will be sent (yes,  _every_ 10 minutes regardless of
   whether there has been traffic or noti).  I was under the impression (and
   have requested a change that never happened) that it would only get sent
   if there had been no traffic since last keepalive timer pop.
 
   As to lenghty timeout, yes - I agree.  It should not be doing what it
   does...  Currently, (according to TCP lab) TCP will send a CA packet
   whenever the timer expires and if no response,  it'll be retried
   configured number of times.  The stupid thing about retrying is that
   it will not use the standard retry algorithm so that once sent,
   retries would come at 4s, 8s, 16s... intervals after the CA (with
   default config).  Nope.  It'll retransmit __EVERY_TEN_MINUTES__(!!) -
   four times,  i.e. worst case will be initial CA + 4 retries, 10 minutes
   wait on each - i.e. 50 minutes to detect a dead peer.  Sigh.
 
   IMHO a much better algorithm would be to store our TCP's last ACK number
   in, say, LAST_CA_TIME_ACK_VALUE.  When the CA timer pops next time,
   compare current ack value to LAST_CA_TIME_ACK_VALUE and if different,
   that means there has been data from peer since last CA time - i.e. there's
   no need to send a CA-packet, just update the LAST_CA_TIME_ACK_VALUE.
 
   If the ack value matched LAST_CA_TIME_ACK_VALUE, there has been no data.
   Send TCP CA packet and queue it to retransmission queue and do the normal
   retry sequence, i.e. time out in ~1..2 minutes if the remote is not
   responding.
 
   It makes absolutely no sense to keep retrying CA packet for 50 minutes,
   once every 10 minutes...  The only good thing about this is that at least
   those values are configurable.  In case someone feels like tweaking these
   numbers,  keep in mind that X.25 (in case you have X.25 link) uses
   IDLE TIMER which defaults to 300(?) seconds (guessing, check in NMMGR)
   and this timer should be longer than TCP's CA since the X.25 IDLE TIMER
   is used to close X.25 Virtual Circuits if no traffic during idle timer
   period of time.
 
   Given that we'll have to live with this behaviour at least for the
   time being and if you'd like to do something about it, maybe I should
   recommend some new values to try.  For example a value of 180secs
   (3 minutes) for TCP CA timer and 240secs(4min) for X.25 idle timer.
   This should detect and  kill TCP connection halves (with dead peer)
   in about 15 minutes,  yet still maintaining X.25 connections for
   helthy TCP-connections as CA-packets will flow within X.25 idle
   timer limits.  Since X.25 makes you pay for every packet, one doesn't
   want to set CA-timer too low...
 
Hope this helps,
Eero - HP CSY Networking lab, NS services.