Subject: RE: [NSIS] state management and the nsis framework

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 9 May 2003 17:58:32 +0100

hi,

[snip]

> ok. NSLP will use the message and control all of the state of 
> signaling
> application. It means that if
> NSLP want to send a message refresh, it must asks NTLP to do 
> it. But I think
> that NTLP can support something automatic and repeated (as 
> the soft-state
> management toolbox)  (3) , eg : NSLP ask NTLP : during T1(ms) 
> please send
> the refresh message every K(ms), if there is an error, send a 
> notification.

my view is that this is an implementation issue, and hence not relevant to the specification of the NTLP. (i am trying to keep the framework focussed on protocol rather than service definitions.) if the software implementing specifically the NSLP generates these things internally, nothing is changed in protocol operation.
 
> > 4. It may be helpful for signalling applications to receive
> state-management related 'triggers' from the NTLP, that a 
> peer has failed or
> become available ("down/up notifications"). These triggers 
> would be about
> adjacent NTLP peers, rather than signalling application peers. We can
> consider this as another case of route change 
> detection/notification (which
> the NTLP is also supposed to do anyway).
> >
> 
> ok, Can we call them common triggers for all NSLPs ?  eg : if 
> NTLP see that
> the routing table is changed, it will notify its NSLP and 
> adjacent NTLP.

there is still some openness here about who gets to see the triggers (are they sent to adjacent nodes or not). but this is the basic idea.

> > 4a. It is an open issue (i.e. we need to think more about) how
> sophisticated to make the definition of what triggers the 
> NSLP would like;
> for example, should 'down' mean 'any loss of contact' or 
> 'loss of contact
> for more than X seconds' and so on. Probably, we should err 
> on the side of
> simplicity, and also require that the meaning of the trigger 
> should not
> depend on how the NTLP generates it (which could be some lower layer
> connection reset, or loss of some number of NTLP-internal 
> refreshes, or some
> other external source).
> >
> 
> ok, I think it depends on each particular signaling 
> application. For exemple
> : 'down' should mean
>     + any loss of contact
>     + loss of contact for more than X seconds or after 
> resending X times a
> message.
>     + receive a notification of error from NTLP or from some other
> application, other entities...

i would prefer to think of these as independent of signalling application. (this is at least partly also an implementation issue anyway.)

> 
> > 5. The existence of these triggers doesn't replace NSLP 
> refreshes as the
> mechanism for maintaining liveness at the signalling 
> application level. In
> this sense, up/down notifications are advisories which allow 
> faster reaction
> to events in the network, but shouldn't be built into NSLP 
> semantics. (This
> is essentially the same distinction - with the same rationale 
> - as SNMP
> makes between traps and normal messages.)
> >
> 
> I think something are not clear. You mean the error triggers 
> and the normal
> operation  of soft-state management. I don't understand the 
> reason why you
> talk about the replacement of error triggers and normal operation.

OK: the point I am trying to make is that an NSLP should not be written saying (for example) "Install state with a xxx-Create message and then you know it is always present unless you receive a notification from the lower (NTLP) layer." Another way of saying this: we don't ask the NTLP to provide the environment in which it is trivial to provide a hard-state NSLP (i.e. by guaranteeing to detect and report remote error conditions). I'm well open to better text explaining this if anyone has some.

> 
> Nary Tra
> 
> PhD student
> ENST, Paris
> Tel: (0033) (0) 1 45 81 71 06.
> 

hope this helps,

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

---

From: [email-masked]
Date: Mon, 12 May 2003 09:46:41 +0200

Hi Robert,

See inline.

Regards.
Maarten

"Hancock, Robert" <[email-masked]>@ietf.org on 09/05/2003
18:58:32

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    RE: [NSIS] state management and the nsis framework

hi,

[snip]

> talk about the replacement of error triggers and normal operation.

OK: the point I am trying to make is that an NSLP should not be written
saying (for example) "Install state with a xxx-Create message and then you
know it is always present unless you receive a notification from the lower
(NTLP) layer." Another way of saying this: we don't ask the NTLP to provide
the environment in which it is trivial to provide a hard-state NSLP (i.e.
by guaranteeing to detect and report remote error conditions). I'm well
open to better text explaining this if anyone has some.

[MB] How does this relate to the softstate toolbox that you've mentioned?
That toolbox may be more closely associated with the NTLP such that the
soft state management does not have to be implemented in each application.
In that case the softstate of both layers can be combined and the NTLP will
trigger the NSLP in case the of a timeout of the refresh timer. Hence, in
that case the NSLP can rely on triggers (one of the triggers being 'soft
state timeout') from the NTLP only.

So, this would allow for a hard state NSLP specification but will require
the NTLP to manage soft state. Since the soft state management is a generic
functionality it seems to make sense to include it in the NTLP.

What do you think?

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 May 2003 09:37:54 +0100

hi maarten,

> functionality it seems to make sense to include it in the NTLP.

I don't disagree with any of this as an engineering approach. However, there is a separate question about what needs to be fixed in a standard:

1. If we believe that the 'soft state management service' should be a universal thing, then we need to define exactly what it is. This seems to be a hard thing to do for two reasons:
a. we can't anticipate the varied needs of all the possible future signalling applications, and we might end up with something needlessly complex;
b. the state management visible to signalling applications will be the joint result of several NTLP hops, so its behaviour is even harder to define.

2. In any case, apart from saying 'state management within a node could be common to all applications or specific to each', there doesn't seem to be any need to standardise anything concrete about it - the necessary implementation freedom isn't ruled out by making the NTLP 'thin', because there doesn't seem any need to have common implementation approaches between two signalling application-aware peers.
[Basically, all the comments I have seen about this are about how functionality should be arranged inside a node, not about what functionality is needed in the 'NTLP-on-the-wire' to support it.]

Cheers,

r.

---

From: [email-masked]
Date: Mon, 12 May 2003 14:51:38 +0300

Hi Robert & Maarten,

> 2. In any case, apart from saying 'state management within a 
> node could be common to all applications or specific to 
> each', there doesn't seem to be any need to standardise 
> anything concrete about it - the necessary implementation 
> freedom isn't ruled out by making the NTLP 'thin', because 
> there doesn't seem any need to have common implementation 
> approaches between two signalling application-aware peers.
> [Basically, all the comments I have seen about this are about 
> how functionality should be arranged inside a node, not about 
> what functionality is needed in the 'NTLP-on-the-wire' to support it.]

Thinking more about this, how state is stored in a node seems
to be implementation specific.  I am not sure that we can 
standardize this, nor am I sure we want to.

What might be a larger question is, do we specify a basic state machine
in the NTLP document?  If we do, how does it relate to any state machines
or state needed by the protocols running on top of NTLP? 

Is it sufficient for NTLP to specify the grammer but not the management
of the state machine?

JOhn

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 May 2003 13:46:26 +0100

john,

> standardize this, nor am I sure we want to.

I'm sure we could try to standardise it, but I think the end 
result would be meaningless. I'm pretty certain it would be a 
very bad idea to try.

> or state needed by the protocols running on top of NTLP? 

I would say that is a matter of protocol specification taste, and
the answers may be different for different protocols (NTLP and NSLPs).

My taste is that state machines or equivalent are good ways at least
to describe protocols, and possibly also to define them, especially 
for non-trivial protocols (and I would claim the existence of 2209
in parallel with 2205 in support).

I think non-trivial interactions between state machine descriptions
of different protocols should be avoided at all costs, however. It should
be possible to read and understand an NSLP spec knowing nothing about
NSIS beyond the framework. 

> Is it sufficient for NTLP to specify the grammer but not the 

please clarify.

r.

---

From: [email-masked]
Date: Tue, 13 May 2003 12:22:59 +0300

> > Is it sufficient for NTLP to specify the grammer but not the  management

Messages between the boxes vs. what the boxes do.  My question is, then, is
NTLP more about the messages & parameters between entities as opposed to the
internal states of the boxes?

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 13 May 2003 11:49:49 +0100

georgios,

in terms of what is being discussed below, could you clarify if you see
any difference in overall NSIS functionality between our two descriptions
(and what this difference is).

if there is no overall difference, could you explain why you prefer your
split of responsibility between NSLP/NTLP. what you propose seems to me
to assume a closer customisation of NTLP functionality to support one specific
signalling application that I feel we should be aiming for.

cheers,

r.

> ------------------------------------------------------------
> [GK]
> > Okay, but will then the following functionality will also 
> be possible:
> > The NSLP refresh procedure can be a pure NTLP refresh procedure,
> > meaning that a refresh NTLP message is periodically sent
> > through all the NTLP stateful nodes located between NI (sender) and
> > NR (receiver).  If a NTLP state in a NTLP stateful is not refreshed
> > on time then the NTLP functionality at this node informs 
> the NSLP state
> that
> > the refresh procedure is unsuccessful.
> 
> >> [reh] I think you are describing a case for a particular 
> NSLP, where an
> NSLP-aware node
> >> just wants to know that it's NSLP peer is alive and 
> kicking. In that
> case, I would rather think of this
> >> as the NSLP generating a rather small, content-free 
> keepalive which it
> sends via the NTLP to
> >> its peer. An implementation would be free to piggyback 
> this information
> on whatever is going on
> >> inside the NTLP, so the end result is identical (in
> performance/functionality terms) to what you
> >> describe. However, I prefer my way of thinking about it 
> for at least 2
> reasons:
> >> a. looser coupling between NSLP/NTLP specification
> >> b. cleaner support from multiple NSLPs
> 
> [GK] No, I am describing a situation where the NTLP state 
> management is
> performed by the
> NTLP protocol. If needed the NSLP protocol can use this NTLP 
> procedure to
> realise the
> NSLP soft state management.

---

From: [email-masked]
Date: Tue, 13 May 2003 15:18:42 +0300

Hi all,

> One thing that's struck me about some of the recent state
> discussions is that in some of the comments it's not clear
> what the real implications are for the protocol, and it
> would be helpful to me if people could be more explicit
> about what they think it means for the protocol when they
> make comments about state retention, etc.

Yup, that would be a good idea.  Also, several folks have
already asked me about some NSLPs & I suggested they submit
individual drafts on them, which could be used as possible
examples during the NTLP design.

thanks,
John

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 14 May 2003 13:43:08 +0200

Hi Georgios

| If a NTLP state is not refreshed in time the NSLP instance 
| is informed about it. Otherwise the NSLP instance 
| assumes that the NTLP state is alive.

   +---C---+
  /         \
 A-----------B

Assume A, B, C to support NTLP, whereas the NSLP of interest is only 
supported by A and B. Once the link A-B is broken, the NTLP A-B
isn't refreshed while the NSLP A-B could easily maintain state 
via A-C-B communication.

How does your system react in this case? It is of no importance to 
the NSLP B that NTLP B lost connectivity to NTLP A.

Regards, Rüdiger

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 May 2003 10:13:44 +0200

Hi Ruediger

Okay, thus you are assuming that a re-routing takes place!

But if (A) and (B) are not end nodes, and the following network
configuration is used:
Before re-routing:
(D = end node) <->(E)<->(F)<->(A)<->(B)<->(G)<->(H)<->(Z= end node)

After rerouting (due to failure of link (A)<->(B)) the following network
configuration can be chosen
by the applied dynamic routing protocol:

(D = end node) <->(E)<->(F)<->(A)<->(C)<->(I)<->(H)<->(Z= end node)

Consider that  the nodes (D), (E), (F), (A), (B), (G), (H), (Z) and (I) can
support both NTLP and
NSLP protocols. Node (C) as you already proposed supports only the NTLP
protocol and not
the NSLP protocol.
Due to failure of the link (A)<->(B) a re-routing takes place.
When the path coupled signaling is used, the new re-routed forwarding path
will be (mainly)
chosen by the applied dynamic routing protocol.
It may happen that the new re-routed path is not at all passing through node
(B).
This means that the old NSLP state stored  in node (B) before re-routing
will remain
there for "ever" (if of course no other soft state management solution is
applied).

Therefore, I think that in many situations, if a re-routing takes place it
will
affect both the NTLP and NSLP state management procedures.
Thus not only the NTLP state management.

Best Regards,
Georgios

----- Original Message -----
From: "Geib, Ruediger" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 15, 2003 8:29 AM
Subject: RE: [NSIS] state management and the nsis framework

> Hi Georgios,
>
> I'm assuming it to be standard Internet architecture.
> There's a best route between A and B. A broken link
> results in a new best route bewteen A and B.
>
> Regards, Rüdiger
>
> | I do not completely understand the depicted scenario.
> | Are you trying to say that there are two paths between A and
> | B that are used
> | simultaneously:
> | One is the direct path A-B and the other is the path A-C-B.
> | Considering that this is not a load sharing solution,
> | is this scenario realistic?
> |
> | Best Regards,
> | Georgios
> |
> |
> | ----- Original Message -----
> | From: "Geib, Ruediger" <[email-masked]>
> | To: <[email-masked]>
> | Cc: <[email-masked]>
> | Sent: Wednesday, May 14, 2003 1:43 PM
> | Subject: RE: [NSIS] state management and the nsis framework
> |
> |
> | > Hi Georgios
> | >
> | > | If a NTLP state is not refreshed in time the NSLP instance
> | > | is informed about it. Otherwise the NSLP instance
> | > | assumes that the NTLP state is alive.
> | >
> | >    +---C---+
> | >   /         \
> | >  A-----------B
> | >
> | > Assume A, B, C to support NTLP, whereas the NSLP of interest is only
> | > supported by A and B. Once the link A-B is broken, the NTLP A-B
> | > isn't refreshed while the NSLP A-B could easily maintain state
> | > via A-C-B communication.
> | >
> | > How does your system react in this case? It is of no importance to
> | > the NSLP B that NTLP B lost connectivity to NTLP A.
> | >
> | > Regards, Rüdiger
> | >
> | >
> |
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 23 May 2003 11:01:38 +0100

dear all,

I sense this conversation is drawing towards a conclusion.

1. In terms of what happens when rerouting happens, i think our current working
assumption is that
*) NTLP 'healing' means: it ensures that signalling messages follow the new
correct path, and should tell the NSLP that something has changed;
*) NSLP 'healing' means: do anything special that the signalling application
wants to account for the fact that the path has changed. 
I'd rather not express this requirement in terms of refresh timers
but in this more abstract way.

2. There could be a significant open issue: what if the interested NSLP instance 
isn't at the same node where the NTLP node recognises the re-routing event.
Should 're-routing has happened' messages get sent around as some people
are assuming? Note that, unless the NTLP retains knowledge of every NSLP that
is interested in each flow, there is no way for it to decide when to stop
propagating such messages (which could lead to some interesting signalling
storms). OTOH, since I regard these as sematically optimisations, from a 
framework perspective this can probably be regarded as an
NTLP design question, at least to a large extent.

3. I'd strongly object to describing things in terms of 'NTLP refresh refreshing
NSLP state' (or indeed vice versa), since it assumes a mechansism in each layer
and then ties them together, not an ideal architectural approach. In any case,
that is not fundamentally what is wanted: what is wanted is that the NSIS 
protocol suite implementation at a node may schedule and combine messages even
at different layers to reduce load on the network, but any protocol state machines
are logically independent at each layer.

I'll try to post a revised proposal for the framework state management section
in a few days, assuming this message doesn't provoke another storm...

r.