Subject: Re: W-7 CAP Auto-logout Timer

From: [email-masked]
Date: Wed, 18 Aug 1999 14:18:00 -0400

Doug wrote:

> W-7 CAP Auto-logout Timer issues               U
>
>Do we need one?

If you want your C&S system to be robust then yes.  Does this explictly 
need to be in the OTW protocol?  Probably not.  Does a mechanism for how 
the CS notifies the CUA in a nice way need to be there?  Mostly likely 
yes.  It makes the CUAs job of deciding how to notify the CU much easier! 
If the CS just drops the link; how is the CUA to know it was because it 
was idle too long and not because someone powered an intermediate router 
down!?!?

>If so, how long?

I dont think it must be fixed in length.  This may vary by policy, etc. 
(ie: ISP1 is very very busy so they want short timeouts; ISP2 is new and 
has fewer users so they allow longer timesouts). 

>Can the server decide not to do this? As in mandatory in protocol,
>optional to implement?

Depending on how the "You've timed out so see ya" is handled in the spec, 
it should be fairly trivial for a CS to say "Ill never time a CUA out" as 
part of the policy.

A never time out CS policy could be the default for a vendors 
implementation if they desire.  Im beind on my draft reading so take this 
next bit w/a grain of eSalt: If the protocol specifies that the CS convey 
the timeout info to the CS up front (ie: via CAPABILITY, etc) then its 
pretty trivial to define, say "0" as "Never times out".

However, since there is a need to have the CS be able to convey "'Gotta go 
now.  Bye." to the CUA in some structured manner (ie: the server going 
down for maintenance, backups, etc) the "You've timed out" notification 
mechanism could use the same basic message design (ie: "S: 15.2;Timed 
out;You have not been active for xx minutes so bye.").

>I propose that we DROP this as a requirement.

Its not an architectural issue to worry about if we define the proper 
mechanism in the spec for allowing CS to "spontaneously" send msgs to the 
CUAs.  I think it can stay w/o virtually any discomfort to those "connect 
forever" types out there.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Thu, 19 Aug 1999 09:21:08 -0400

[email-masked] wrote:

> If you want your C&S system to be robust then yes.  Does this
> explictly need to be in the OTW protocol?  Probably not.  Does a
> mechanism for how the CS notifies the CUA in a nice way need to be
> there?  Mostly likely yes.  It makes the CUAs job of deciding how to
> notify the CU much easier!  If the CS just drops the link; how is the
> CUA to know it was because it was idle too long and not because
> someone powered an intermediate router down!?!?

I'm not sure it cares.  If you power down a router, the connection does
not get closed (it's maintained by the endpoints), unless you try to
send data over the connection (in which case your TCP stack will get a
Network Unreachable packet, and drop the connection).  So, if you're
idle, and the connection gets dropped, it's because of something at one
of the endpoints.  Either the CS was shut down (or crashed) or the CUA
hit a timeout.  In either case, the appropriate reaction is to reopen
the connection the next time you need to talk to the CS.

Of course, it might be useful for the *user* to know why the connection
was dropped, so the CUA can say something like "Connection to CS timed
out; reconnecting" or "Connection to CS unexpectedly dropped;
reconnecting".

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/