Subject: Re: little problem with <close-session>

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Sep 2004 11:46:40 +0200

Hi,

I'd like to put a new draft out, but I can't right now because I'm 
blocked on <close-session>.  As it stands right now, we are blocked 
because Margaret is concerned about CLOSE_WAIT state consuming resources 
on the manager.  This concern arises from the case where one will want 
to make a change across a large number of devices in a short period of 
time.  The concern is mitigated by <close-session> because this forces 
the CLOSE_WAIT state to the agent.

On the other hand, <close-session> cannot currently be used by the agent 
because the agent doesn't send commands.  So, what's a poor agent to do 
when it wants to gracefully shutdown the connection?

Our options are as follows:

  - simply close the connection.  There's no pretty symmetry there but it
    will do the job.  However, it poses a problem for BEEP in as much as
    I would have to violate the BEEP->TCP transport mapping.

  - Remove <close-session> from the base protocol and deal with this
    level of signaling in the mapping below.

  - Retain <close-session> *AND* do something in the mapping below to
    allow the agent to close the connection.  Not pretty because we're
    actually now beyond MAPPING.  If we did this we should have some
    text in the base protocol about this possibility such as the
    following:

	"The agent may initiate session termination in a way specified
          by the appropriate application mapping."

Comments?

Eliot

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Sep 2004 15:35:13 +0200

> when it wants to gracefully shutdown the connection?

[...]
 
> Comments?

I am still not sure how serious the problem is we are trying to cure.
How many TCP connections do you have to close per second in order to 
run into problems on today's operating systems? Do operators have any 
insights to share whether this is a problem with existing CLI scripts? 
How many TCP connections do they close per second these days?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 2 Sep 2004 21:34:03 -0400

Hi Juergen,

>How many TCP connections do they close per second these days?

These are all interesting questions, and I would like to know the 
answers (but I don't).  I do know that there were real-life problems 
with this in the mid-1990s, but I have no more recent data.

The other reason that I cited for wanting a <close-session> command 
is that it removes any ambiguity about when the session has been 
cleanly closed on both sides, so that all resources and state can be 
freed.  This is really a question of whether we want any concept of a 
session to exist at the NETCONF layer, or whether we want NETCONF to 
assume that the graceful close of a lower layer session indicates 
that the NETCONF session completed successfully.

I don't have religion about this, so if no one else sees any 
advantages to having a <close-session> command, please just remove 
it.  If that is the choice of the WG, I will put a caveat in the SSH 
mapping about connections being left in TIME-WAIT state on the 
manger, and we can move on...

Margaret

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Sep 2004 11:21:14 +0200

Hi,

> with this in the mid-1990s, but I have no more recent data.

Fair enough, but I would like the transport concern to be handled in the 
mapping document.

> 
> The other reason that I cited for wanting a <close-session> command is 
> that it removes any ambiguity about when the session has been cleanly 
> closed on both sides, so that all resources and state can be freed.  
> This is really a question of whether we want any concept of a session to 
> exist at the NETCONF layer, or whether we want NETCONF to assume that 
> the graceful close of a lower layer session indicates that the NETCONF 
> session completed successfully.

The state of a session is something that needs to be determined in the 
mapping document.  In some cases it will need to be explicit and in 
other cases explicit.  Nothing prevents the ends from communicating 
session state - in a combined L4/L5 view of the world that happens all 
the time with TCP.

> 
> I don't have religion about this, so if no one else sees any advantages 
> to having a <close-session> command, please just remove it.  If that is 
> the choice of the WG, I will put a caveat in the SSH mapping about 
> connections being left in TIME-WAIT state on the manger, and we can move 
> on...

Again, I'm not suggesting that it be removed entirely but that it be 
moved into the mappings (of the alternative that's my favorite).

One way or the other, you need to update your draft.

Eliot