Subject: [NSIS] MA-Hello request/response processing (was: RE: GIST MA Keep-alive/Liveliness)

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

Hi roland,

Some good questions. I think the facility is useful (see below)
and so we need to keep it, but a small protocol change is 
needed to make it work properly. I've implemented a version
of this change for the next version of the draft, but since
it is a protocol change, other people might like to review it
as well.

[snipped stuff that will be answered in another thread]

> 
> 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. 

Basically I think that since it is up to the originating node
to decide whether to make such a liveness test, we don't need
to be totally prescriptive about how to go about it. After all,
a conformant node can just decide never to do such a test in
the first place. What I think does need to be stated is that
you can use the MA-Hello to test liveness and Die if the test
fails. Text is added in 6.4 to say just that.

> 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. 

This is the crucial point. I've proposed adding a Hello-ID
to the MA-Hello message. It is set to a non-zero value in
request (R=1) messages, and echoed in any reply; otherwise
it is set to zero. Note that replies must have R=0. No-one
ever has to generate R=1 messages, but if you get one you 
have to send a response with R=0 including the Hello-ID.
(I think this meets the matching requirement safely.)

> 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.

I think of it as a diagnostic. You don't have to invoke it,
but it is useful to define normatively how peers will respond
to it. At the moment, it's a simple way to check that the
GIST layer at the peer is still functioning without having
to send some made-up data (which might interact with an 
NSLP). It might even be used mainly by user tools (a GIST
ping). It can also be used to test the whether outstanding 
messages have been delivered to the other end of an MA, which
can be useful in some circumstances.

The currently proposed text is in the issue tracker at
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue157

cheers,

robert h.

> Regards,
>  Roland

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