Re: little problem with <close-session>

[Margaret Wasserman <margaret@thingmagic.com>]

> N.B. in BEEP the initiator always initiates the transport close.  This may be
> a problem, given Margaret's concerns, but <close-session> doesn't address
> that part at all.

When the initiator initiates a BEEP-level close, does that mean that 
it will also initiate the TCP-level close (by sending the first 
<FIN>)?  If so, I think that this may cause a potentially serious 
problem with the scalability of NETCONF over BEEP for managing very 
large numbers or nodes and/or handling large numbers of 
separately-initiated transactions, as the side of the TCP connection 
that sends the first <FIN> will also be the side that ends-up with 
connections in TIME-WAIT state for a couple of minutes after each 
session is closed.

Perhaps, given the capabilities of workstations and/or some 
enhancements to the TCP protocol this is no longer a serious problem? 
I know that it was a serious problem when HTTP 1.0 was introduced -- 
in that case the TIME-WAIT connections were left on the server and 
this required very high-end servers to handle large numbers of HTTP 
connections.  I am surprised, based on that experience, that BEEP 
doesn't offer a way for the two ends of the session to 
negotiation/control who will initiate the TCP portion of the close. 
Is BEEP specifically tailored for use in cases where there will be 
many clients and few servers?  In NETCONF we have the opposite 
situation -- one (or a few) client(s) and many servers.

Anyway, maybe we should check with some transport-saavy folks to see 
if this is still an important consideration for protocol design?

Margaret

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