Subject: [NSIS] RE: GIST MA Keep-alive/Liveliness

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 31 Oct 2006 17:55:59 -0000

Hi Roland,

I think the basic problem here is that the state machine
is over prescriptive about the Connected -> Idle transition.

The intention has always been

Connected: I want it; I don't care if my peer wants it, but
           I will send MA-Hellos if necessary to stop my
           peer from dropping it

Idle: I no longer want it, but so long as my peer keeps 
      sending me MA-Hellos I will not drop it

So the distinction between Connected and Idle is one of
whether I want the MA or not, and that has to be mainly
a question of local policy. Indeed, that is what the
text in 4.4.3 says. The current 6.4 implies that this
transition is purely timer driven, which then raises all
sorts of extra questions about what if the timer-driven
transitions do something stupid (like put the MA into a
state where it may be torn down even though there are 
still NSLP states using it).

Therefore, my proposed resolution is to be open that the
Connected -> Idle transition is triggered by policy, and
that the policy may be timer driven but could also (clearly)
take anything else into account. In particular, the
NoActivity timer disappears, and there is just a tg_MAIdle
event.

I think that should answer most of the questions below.
It does so at the cost of providing some more implementation
freedom; however, I think that freedom was always necessary
anyway (and I don't believe the change affects interoperability).
The discussion and proposed text is in the tracker at
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue131

cheers & happy reading ;-)

robert h.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 20 October 2006 15:10
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: GIST MA Keep-alive/Liveliness
> 
> 
> Hi Robert,
> 
> After trying to understand the exact semantics of the 
> mechanism described in section 6.4 I found it somewhat 
> confusing with all the different timers (NoActivity/NoHello) 
> and trying to match what should be actually achieved by the 
> state machine in Fig. 8. I guess that this needs more 
> motivation and clarification. Some statements are confusing 
> and IMHO a short paragraph about the overall goals of this 
> concept is missing. What are we trying to achieve with this 
> mechanism? Is it just a keep-alive or is it failure 
> detection, or both? However, just in order to keep the 
> connection open after the last message was sent or received, 
> MA-Hellos are not necessary (see below).
> 
> Let me try to summarize:
> Each peer has an MA-Hold-Time which is exchanged at session 
> setup. So I would expect that the other side keeps the 
> connection at least until this period has passed after the 
> last message was exchanged. Thus if I want to keep the 
> connection beyond the other side's MA-Hold-Time but have 
> nothing else to send, I should sent an MA-Hello to the other 
> side. So far so good, that is pretty clear.
> 
> Now the situation is like this:
> Instead of using the maximum of both hold-times and then
> both going to death, the peer with an internal NoActivity
> timer period greater than the other peers MA-Hold-Time
> has to send MA-Hellos to the other peer in order to keep
> the connection open. Thus, the real internal timeout policy
> is actually determined by the NoActivity timer period
> (and which must be >= own-MA-Hold-Time (=NoHello Timer 
> period)). Let's say we choose NoHello=NoActivity=own-MA-Hold-Time.
> Then each side will keep sending MA-Hellos until the 
> own-MA-Hold-Time expired. Then both go to IDLE and after a 
> further NoHello timeout to death. Thus each side will really 
> close down after NoActivity+own-MA-Hold-Time (so this is the 
> _real_ MA-Hold-Time).
> 
> So now the questions (maybe I'm puzzled, because both
> functions are mixed together right now):
> 1.) if we only want to keep the connection open, it
>     would probably be sufficient to use the minimum
>     proposed MA-Hold-Time as timeout without sending
>     any MA-Hellos around. If the connection broke due
>     to a failure of the peer, this would have been
>     probably noticed and indicated by the transport
>     layer. If not, we need a liveliness test.
> 
> 2.) if this is meant to be also a liveliness check
>     mechanism, I would appreciate more reasoning
>     for having a NoActivity timeout which may be different
>     than NoHello. The statement:
>     "The period of this timer is implementation-specific but
>     is likely to be related to the period of the NoHello timer."
>     is too fuzzy. Why isn't NoActivity==NoHello reasonable?
>     If not we probably should rename MA-Hold-Time and NoActivity...
>     The current use of MA-Hold-Time in the initial handshake
>     is more or less the notification when the
>     MA-Hellos should be send and not how long the
>     connection is really available. This is confusing...
> 
> However, I'm missing a rationale and a clear description
> of the objectives that this should achieve.
> 
> One more thing:
> A default time of 30s for an MA-Hold-Time would probably 
> require to send refreshing RESERVEs by QoS NSLP before that 
> time in order to avoid close down and re-setup of the connection.
> 
> Regards,
>  Roland
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis