Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

PROBE_TIMER default

 
SOLVED
Go to solution
Wolfgang Kobarg-Sachsse
Occasional Contributor

PROBE_TIMER default

From a system with pre 5.4 TCPIP:

SET
PROTOCOL
/PROBE_TIMER
/PROBE_TIMER=n
Optional. Default: 75 seconds.

UCX> show proto tcp /para
TCP
MTU size segment: disabled
Delay ACK: enabled
Loopback: disabled
Window scale: enabled
Drop timer: 600
Probe timer: 75

From a system with post 5.4 TCPIP:

SET
PROTOCOL
/PROBE_TIMER
/PROBE_TIMER=n
Optional. Default: 75 seconds.

TCPIP> show prot tcp /para
TCP
Delay ACK: enabled
Window scale: enabled
Drop count: 8
Probe timer: 7200

The online documentation (probe timer 75 seconds) differs from the reality (probe timer 7200 seconds).

I found the following in the web:

http://tech.groups.yahoo.com/group/OpenVMS_Friends/message/1818 :

"there was a change to connection timeouts in 5.3, where the default
was changed from 75 seconds to 2 hours to make it RFC compliant."

Does that come from here:

From RFC 1537: http://graphcomp.com/info/rfc/rfc1537.html

For top level domain servers I would recommend the following values:

86400 ; Refresh 24 hours
7200 ; Retry 2 hours
2592000 ; Expire 30 days
345600 ; Minimum TTL 4 days

For other servers I would suggest:

28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800 ; Expire 7 days
86400 ; Minimum TTL 1 day

This change is not reflected in any TCPIP manual. There is some description about the KEEPALIVE values in the “HP TCP/IP Services for OpenVMS Sockets API and System Services Programming“ manual. But even there they are saying that TCP_KEEPIDLE is 75 seconds (150 half-seconds), whereas each OpenVMS machine in our clusters are showing that

TCPIP> sysconfig -q inet

returns

tcp_keepidle = 14400

(Again, half-seconds, so these are 7200 seconds).

Am I misunderstanding here anything? Or is this a TCPIP on OpenVMS documentation bug?

Wolfgang
5 REPLIES 5
Hoff
Honored Contributor
Solution

Re: PROBE_TIMER default

It does appear that the doc doesn't match reality.

Do forward this along to HP to answer and to sort out.

If you don't have a support contract, there's a documentation comments and feedback path available at the HP documentation web site.
Wim Van den Wyngaert
Honored Contributor

Re: PROBE_TIMER default

The RFC says :

This memo provides information for the Internet community. It does not specify an Internet standard.

So, HP decided that some part was a good idea and implemented it. But forgot to modify the online help.

fwiw

Wim
Wim
Richard Brodie_1
Honored Contributor

Re: PROBE_TIMER default

RFC 1122 'Host Requirements', as it often is. Although it's nearly 20 years old, there's a load of condensed implementation experience in there.

"4.2.3.6 TCP Keep-Alives

...Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. This interval MUST be configurable and MUST default to no less than two hours."
Wim Van den Wyngaert
Honored Contributor

Re: PROBE_TIMER default

http://www.networksorcery.com/enp/default0501.htm overrules your rfc.

We have the timeout in minutes to get alarms in time when things go wrong. Note that some protocols allow overrule of the default within the program (via logicals : ftp , ftpd, telnetsym, ... ).

Wim
Wim
Wolfgang Kobarg-Sachsse
Occasional Contributor

Re: PROBE_TIMER default

Thank you all for your replies.

I used the feedback button for reporting documentation issues to HP, as suggested. If I receive a response in the near future I'll post it here.

Wolfgang