Subject: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK?

From: Kent Watsen <[email-masked]>
Date: Sun, 29 Mar 2015 20:00:15 +0000

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
2hour 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:  https://github.com/netconf-wg/server-model/issues/43

Thanks,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Sun, 29 Mar 2015 20:25:27 +0000

Related to [1] is the expense of having to setup a new crypto session as
well as reestablish any long-poll RPCs like netconf/restconf
notifications...

Thanks,
Kent

On 3/29/15, 3:00 PM, "Kent Watsen" <[email-masked]> wrote:

>[1] .../connection-type/persistent/keep-alives/interval-secs:
>[2] .../connection-type/periodic/linger-secs:
>[3] .../reconnect-strategy/interval-secs:
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Sun, 29 Mar 2015 21:35:32 +0000

s/know/knob/   - this on two separate lines in the original message.

Kent

---

From: Phil Shafer <[email-masked]>
Date: Mon, 30 Mar 2015 01:03:45 -0400

Kent Watsen writes:
>Note, this is a
>session.

Having a connection to your NMS die after 45 seconds during a network
issue, when the network _is_ having trouble, seems unwise.

Thanks,
 Phil