keep-alive, linger, reconnect interval defaults OK?

[kwatsen]

Juergen:

• is there a motivation for the 15 seconds default for the call home
  keep alive timer?
• is there a motivation for 30 seconds default linger time and 5
  minutes default reconnect time?

Kent

For all of these, I just figured they were sensible choices. Do they
seem OK to you?

[kwatsen]

This issue was discussed during and after the Dallas meeting with the
following status:

[1] .../connection-type/persistent/keep-alives/interval-secs:
This issue is still open - please reply on it if so inclined. Some felt that a keep-alive every 15 seconds was too often, and suggested that a 2­ hour value would be better. Searching on this for awhile, it seems that many use 300 seconds and many others use 15 seconds, Note, this is a keep-alive message being sent every 15 to 300 seconds, with a default count-max of '3', results in a new connection after 45 to 900 seconds - that's 3/4 of a minute to 15 minutes to proactively bring up a failed session. Some of the issue surrounds how the TCP-level timeout is set. The introduction in RFC5482 says:

In the absence of an application-specified user timeout, the TCP
specification [RFC0793] defines a default user timeout of 5 minutes.
The Host Requirements RFC [RFC1122] refines this definition by
introducing two thresholds, R1 and R2 (R2 > R1), that control the
number of retransmission attempts for a single segment. It suggests
that TCP should notify applications when R1 is reached for a segment,
and close the connection when R2 is reached. [RFC1122] also defines
the recommended values for R1 (3 retransmissions) and R2 (100
seconds), noting that R2 for SYN segments should be at least 3
minutes. Instead of a single user timeout, some TCP implementations
offer finer-grained policies. For example, Solaris supports
different timeouts depending on whether a TCP connection is in the
SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS].

I wonder if we should add configuration know for a tcp timeout as well?

[2] .../connection-type/periodic/linger-secs:
This leaf is to be removed as it is best to let the NETCONF/RESTCONF client decide when to close the session ­ the server should leave the session open, up until the /session-options/idle-timeout limit.

[3] .../reconnect-strategy/interval-secs:
This leaf is to be removed. It doesn't have enough value to leave exposed as a configurable know.

Due to [1] being still open, this issue only moves to the OPEN state - not the VERIFY state.

Reference: #43

Thanks,
Kent

[kwatsen]

Hi Phil,

This timer is to test the aliveness of the connection. Sure, if the NMS
doesn't respond in time, the device tears down that connection in hope to
find a connection the works better.

45 seconds seems too short to you, and 15 minutes seems too long to me.
How about 5 minutes for the default? Anyone else have an opinion?

Thanks,
Kent

[kwatsen]

For the original issue, we now have:

[1] .../connection-type/persistent/keep-alives/interval-secs:

Set default to 5 minutes

[2] .../connection-type/periodic/linger-secs:

Remove this node.

[3] .../reconnect-strategy/interval-secs:

Remove this node.

This solution will be considered verified on May 23 if no objections are
raised before then.

Thanks,
Kent

[kwatsen]

Modified connection-type/persistent/keep-alives/interval-secs default value, removed the connection-type/periodic/linger-secs node, and also removed the reconnect-strategy/interval-secs node

[kwatsen]

Closing - no objection received to change made in -07