Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree?

From: Kent Watsen <[email-masked]>
Date: Fri, 5 Jun 2015 00:48:19 +0000

No response on this issue yet, but in reviewing some comments posted before, I noticed Martin wrote:

    o  call-home / application / connection-type / persistent-connection

      By default, if we configure a call-home "application", we have a
      persistent-connention with keep-alives being sent on the transport
      layer ever 15 seconds.  But we also have the idle-timeout that works
      on the messages layer default to 3600 seconds.

      So it seems to me that unless there is NETCONF traffic, the
      persistent connection will be closed by the idle-timeout after 3600
      seconds.  But since the connection was persistent, the device will
      immediately re-establish the connection, and so on.

This is what I meant by "unhelpful" below.

It's tempting to move keep-alives from the SSH/TLS layer to the NETCONF/RESTCONF layer, but :
1. Neither NETCONF nor RESTCONF support server-initiated RPCs
2. Using notifications (push/pull) would require the client subscribes to notifications *and* that the notification includes a correlation identifier for the NETCONF/RESTCONF "session" (can't really call it that for RESTCONF) the server is trying to solicit a response for.

Kent

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 1, 2015 at 8:38 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree?

[This is a new issue]

Currently, "idle-timeout" is configured in the global "session-options" tree, which applies to all connections, both listen and call-home. But it's unclear if idle-timeout makes sense for call home connections, and hence should be moved to being only under the listen tree.  Keep in mind that there are two types of call home connections: persistent and periodic.  The following describes the effect of idle-timeout on each.

For persistent connections, it doesn't makes sense to me that the server would ever idle-timeout a connection. This perspective is bolstered by persistent connections having keep-alives, so the server can detect when a client connection has been lost and it needs to initiate a new one. An idle-timeout here would be unhelpful.

For periodic connections, the idle-timeout is way too course (default 1 hour). We use to have a "linger-timeout" for this purpose (default 30 secs), but a side meeting in Dallas concluded that it was unneeded, as the client would close the connection as and when it was ready. Still, the intent is that the connection wouldn't stay open anywhere close to the periodic interval (default 5 mins). An idle-timeout here is nearly useless.

So, if unhelpful for persistent connections and nearly useless for periodic connections, perhaps we should just move idle-timeout to the listen tree?  What do you think?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 Jun 2015 19:01:52 -0700

Hi,

Your solution to move the idle-timeout to the 'listen' tree is OK.

BTW,

I am not a fan of the 1-use groupings in the server-model draft.
They are not written to be reusable.  The granularity is too coarse.
E.g., the entire listen tree or entire callhome tree do not seem reusable.

Andy

On Thu, Jun 4, 2015 at 5:48 PM, Kent Watsen <[email-masked]> wrote:
> 2. Using notifications (push/pull) would require the client subscribes to
> notifications *and* that the notification includes a correlation identifier
> for the NETCONF/RESTCONF "session" (can't really call it that for RESTCONF)
> the server is trying to solicit a response for.
>
> Kent
>
>
> From: Kent Watsen <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Currently, "idle-timeout" is configured in the global "session-options"
> tree, which applies to all connections, both listen and call-home. But it's
> unclear if idle-timeout makes sense for call home connections, and hence
> should be moved to being only under the listen tree.  Keep in mind that
> there are two types of call home connections: persistent and periodic.  The
> following describes the effect of idle-timeout on each.
>
> For persistent connections, it doesn't makes sense to me that the server
> would ever idle-timeout a connection. This perspective is bolstered by
> persistent connections having keep-alives, so the server can detect when a
> client connection has been lost and it needs to initiate a new one. An
> idle-timeout here would be unhelpful.
>
> For periodic connections, the idle-timeout is way too course (default 1
> hour). We use to have a "linger-timeout" for this purpose (default 30 secs),
> but a side meeting in Dallas concluded that it was unneeded, as the client
> would close the connection as and when it was ready. Still, the intent is
> that the connection wouldn't stay open anywhere close to the periodic
> interval (default 5 mins). An idle-timeout here is nearly useless.
>
> So, if unhelpful for persistent connections and nearly useless for periodic
> connections, perhaps we should just move idle-timeout to the listen tree?
> What do you think?
>
> Thanks,
> Kent
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 5 Jun 2015 18:31:05 +0000

>Your solution to move the idle-timeout to the 'listen' tree is OK.

Thanks Andy.

If no objections are raised, this solution will be considered verified on
June 9th. 

>E.g., the entire listen tree or entire callhome tree do not seem reusable.

Indeed, there has been more than one comment on this:

   https://github.com/netconf-wg/server-model/issues/37

All the single-use groupings are removed in the upcoming -07

Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 25 Jun 2015 23:25:11 +0000

Regarding moving "idle-timeout" node to the "listen" tree, I'm still a fan
of that, but what I think would be even better is to also have an
idle-timeout in the call-home/periodic and the call-home/persistent
sub-trees.   

An idle-timeout is always useful, but its value needs to be different for
the various cases.  How about this:

                                          Default
                                          -------
   listen/idle-timeout                    1 hour
   call-home/periodic/idle-timeout        5 min

   call-home/persistent/idle-timeout      1 day

What do you think?  - makes sense?

Kent