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

From: Roland Bless <[email-masked]>
Date: Fri, 20 Oct 2006 16:09:31 +0200

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 20 Oct 2006 16:51:03 +0200

Hi Robert,

[I pressed send too early...]

> that time in order to avoid close down and re-setup

...so, the real Hold-time (noActivity) may be longer (but we
don't know) and we may have luck, or the recommended
MA-Hold-Time depends much on the application...

Another one:
Currently, requesting a reply to an MA-Hello has
the effect of getting an MA-Hello back (hopefully).
However, there is no action taken if that MA-Hello
response is missing. The Draft currently says:

                                               The R flag MAY be set
   (R=1); if so, the peer MUST send another message back along the
   messaging association.  This allows a node to test the liveness of
   the peer.

If the latter statement was true, then some action would be taken
if such a response is missing. Currently, receiving MA-Hellos (or not)
has no effect in the "Connected" state (for R=0), so we really
don't care about getting an answer. Probably it makes sense
to do the following:
Introduce another NULL-message called MA-Hello-Response (with R=0)
which must be send as response to an MA-Hello with R=1. We then
could start a timer and go to "Death" if the solicited
MA-Hello-Response is still missing after that period.
Currently, we cannot decide whether we got a response
or whether it was just a regularly emitted MA-Hello that arrived;
maybe we don't care, because we heard something from the other side,
but on the other hand if only our sending direction went down we
would not notice.
If all of the above doesn't make sense, I would like to remove
the R=1 feature for MA-Hellos, because it has no real usefull
effect anyway.

Regards,
 Roland