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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 14 May 2003 16:14:09 +0100

dear colleagues,

What direction[s] are we heading in this discussion?

First, a general point. What I believe we are trying to achieve in this
NSIS work is to develop tools which are generally useful for path-associated
signalling in the Internet; one of the mechanisms to do this is to put 
functionality which we generally believe to be generic to all such situations
into a common lower layer. In the absence of *any* discussion so far of the 
general characteristics of signalling applications - beyond the fact that they 
need to transfer data between instances of themselves - the only safe 
functionality to put in the lower layer is that of data transfer. (There 
have been plenty of requests for such a discussion, but no one seem to want to 
open that Pandora's box at the moment.)

Putting functionality into the NTLP, which happens to match nicely
with what is needed by one rather specific signalling application, without 
analysing (in detail) how it affects NTLP usefulness more generally, strikes
me as being a stunningly bad idea.

To specifics:
We have a proposal that the framework should define how the NSLP should be
able to 'use' refresh functionality within the NTLP layer, essentially in the
interests of efficiency and reduced network load.

Taken most literally, this would imply defining a soft-state refresh machine
which the NTLP operated for its own purposes but whose state was exposed to
signalling applications. This would be possible but it strikes me as a 
dangerously high degree of interlayer coupling. Even if it was useful for
a single-application world, we would have to decide what it meant when 
multiple applications were operating between the same pair of NTLP neighbours,
or some NTLP nodes didn't understand all of the applications. I have no idea how
to do this.

It seems much easier to me to have conceptually independent refresh mechanisms,
in particular neither layer needs to know that the other is even using soft-state
as a liveness mechanism. A complaint is that independent refresh mechanisms 
would double the message rate and network load. This is just plain wrong. A 
single message can refresh state at more than one level, and any decent
NTLP implementation should be able to schedule its own operation so that 
this gain is achieved (there is plenty of experience from other protocols in 
how to do this sort of thing). In fact, our biggest gain comes from being able
to handle multiple signalling applications and sessions in a single NTLP message
(2961 bundling-style), and this is made easy specifically by minimising the
inter-layer state coupling.

Of course, it also depends on what the NSLP is using this NTLP state-management
capability for. *If* the only way it is used is to find out "something failed"
then this is quite a different case. We are already (I think) assuming that the
NTLP does some sort of 'peer liveness' monitoring (detecting route changes,
restarts and so on), and it can report failures in this to signalling 
applications. But that is nothing about sharing a refresh mechanism, and
(nicely) makes no restrictions on how the NTLP should actually be designed.

Cheers,

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 14 May 2003 18:45:22 +0200

Hi Robert

>> would double the message rate and network load. This is just plain wrong.
>> A single message can refresh state at more than one level, and any decent
>> how to do this sort of thing).

Please note that the above described proposal is actually in favour of
interlayer
coupling and it is actually similar to what I was proposing :-)
I was proposing that the NTLP refresh messages are used to refresh the NTLP
and NSLP states!
In order to do this the NTLP instance has to generate a trigger in certain
situations.
A NSLP instance can then use this trigger for its soft state management.

If we consider that the types and ways of NTLP triggers are part of APIs,
then we
probably do not have to specify, in the NSIS framework,
how and when the NTLP triggers are generated.

Best regards,
Georgios