Subject: RE: [NSIS] state management question

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 21 Mar 2003 00:02:49 -0000

hi marcus,

> --On Dienstag, 18. März 2003 23:29 +0000 "Hancock, Robert" 
> <[email-masked]> wrote:
> 
> > Dear all,
> >
> > As discussed in today's session, there may or may not be an 
> open issue
> > about how much the NTLP should 'know' or 'do' about 
> providing a state
> > management service to signalling applications, or being aware that
> > signalling applications are using the NTLP to do state 
> management. (Note
> > that this is entirely not about state that the NTLP uses 
> internally, e.g.
> > to route messages correctly.)
> >
> 
> The actual problem is that signaling is not only about state 
> management as 
> some people think. It involved also the triggering of 
> functionality on the 
> nodes using the state as argument.

true. however, the triggering of the functionality is certainly not part of the
NTLP, and technically not part of the NSLP either - it's something that the signalling application does in an implementation-specific way.

> 
> If state management is not part of NTLP I do not see what 
> NTLP is doing 
> more than only forwarding signaling messages.

i would be quite happy to see the NTLP doing no more than forwarding signalling messages.

> 
> > The pure question of whether the NTLP treats a refresh message
> > differently from a 'new' message could be considered a node-internal
> > implementation issue - provided you only expect this 
> treatment to take
> > place at nodes processing that signalling application and not
> > intermediate ones. Consider a possible example: 1. The NTLP 
> design is
> > such that downstream (sender-->receiver) messages will be sent in
> > end-to-end addressed router-alerting PATH-like packets. 2. 
> An signalling
> > application which generates a downstream message which is 
> basically a
> > refresh will have that message seen at every downstream 
> node. 3. Any node
> > which doesn't support that signalling application (i.e. not 
> including the
> > message sender) will have no choice but to forward that message
> > immediately. Network desynchronisation actions can only be 
> taken at the
> > signalling application aware nodes.
> >
> > Are we worried about this sort of thing? I'd be very happy 
> with the 'NTLP
> > is 100% ignorant of signalling application state 
> management' approach.
> > However, some people might see it as a departure from 'typical' RSVP
> > behaviour. It's also clearly different from the original 
> CSTP proposal
> > (e.g. section 2.2 of Bob's 2 level draft).
> >
> 
> In RSVP it is just fully integrated. IMHO state management 
> should be in the 
> core of NTLP. I also understand the problem with the more 
> complex interface 
> to signaling application. But I assume this heavily depends 
> on how you 
> implement it.
> 
> > I'd invite people who think that the NTLP should contain 
> standardised
> > (i.e. non-implementation specific) functionality to do 
> something related
> > to state management to say what that functionality should be.
> 
> The functionality should include refreshing, removing state 
> in case of 
> failure (timeout).

OK, the big question: why? why can't the signalling application do this? it can generate refreshes (which are just messages for the NTLP to send); it can put time values in its data objects (which are opaque to the NTLP) and use them to set timeout failures. Why make this explicit in the NTLP behaviour?

> In the perspective of "context transfer" having 
> generalized state management makes a lot of sense to have 
> generic state 
> transfer.

ok, but this would be a seamoby question. i suppose you can see a CT protocol as a counterpart of the NTLP which moves context sideways rather than longitudinally. however, so far as i am aware, the current seamoby proposal just moves data blocks  and doesn't do any actual 'management' (since it's essentially a single shot process, there isn't much call for it to do so).

> 
> What I currently cannot judge is what variety of state 
> management is needed 
> for the different signaling application.

exactly. and the fact that this is a hard question implies to me that building assumptions about this into the NTLP would be a bad idea.

> 
> Marcus
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> Phone: +49 (0) 6221 905 11 29
> personal home page: http://www.brubers.org/marcus
> 
> 
> 
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Wed, 26 Mar 2003 11:28:29 +0200

Robert,

> open issue about how much the NTLP should 'know' or 'do' 
> about providing a state management service to signalling 
> applications, or being aware that signalling applications are 
> using the NTLP to do state management. (Note that this is 
> entirely not about state that the NTLP uses internally, e.g. 

So, I've been scratching my head about this question.  In my opinion
(not as WG chair), my thoughts have been that NTLP would transport
the application state between NSIS entities.  NTLP could/should be
responsible for handling refreshes, expiration of the state; teardown 
of the NTLP sessions.

However, your question to the list is a bit too abstract for me
to fully 'get' at what you are asking.  Could you try to rephrase
it, maybe with concrete examples?

Thanks,
John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 26 Mar 2003 11:15:08 +0100

Hi John

>> In my opinion

Regarding NTLP state management, 
I have the same opinion as you have!
However, there might be situations where 
the NTLP will not have to install and maintain 
a NTLP state into a node.
Please see:
http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-01.txt

Best Regards,
Georgios

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 27 Mar 2003 07:27:26 -0000

john,

let's see what i can do.

> the application state between NSIS entities.

First alert: it's clear that the NTLP would transport signalling application 
data between NEs. Some of that information may or may not sometimes be state 
related (does sending ResvConf count as 'transporting state'?);
in fact, whether or not it's state related depends on what the receiving 
application does with it. The question is whether the NTLP contains special
functions (message types, sequences) to deal with state refreshing and so on.

> NTLP could/should be

So, many signalling applications may periodically send the same information
(semantically but not necessarily bitwise identical). You don't need to know this
in the NTLP for it to work, the signalling application just invokes
it periodically.

There is nothing to stop you developing an NTLP implementation which includes
code to repeat messages, and to filter the repetitions it receives. It would do
this as a service to local signalling applications (they get less interrupt load,
simpler timer management and so on). However, it would interoperate perfectly
with a simpler implementation which left all this up to the signalling
application. A clever implementation could even do message jittering, and time
the messages to coincide with any NTLP-internal refresh messages.

In the simple case where the signalling application peers are also NTLP peers
(i.e. no intermediate NTLP-only nodes) this may be all we need. In other words,
all this state management stuff is just implementation stuff.

I think this is the point Mike raised in SF, and Henning in New York. In that
case, there's no need to contaminate the protocol discussion with it (so far as 
I can tell), and it probably hurts more than helps to do so.

When you do have intermediate NTLP-only nodes, the question arises whether they
should do something clever by knowing the state management semantics of the
messages carried (e.g. jitter them, generate them at different rates). If we 
think they should (and this is quite unclear to me), we should define what those
functions are and what information is needed at the NTLP to make them possible.

To make it concrete in this case:
- should the NTLP contain fields which are refresh times? always? sometimes?
- should the NTLP have a bit in its header which distinguishes between state refreshing and other messages?
- should the NTLP make up its own mind whether to acknowledge state creation or deletion messages?
... and so on.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 27 Mar 2003 09:51:14 +0100

Robert,

my answers on your final questions in line. I've 
added some text on the message sequence number 
mechanism, which I think is another issue 
raising concerns.

Regards, Rüdiger

| To make it concrete in this case:
| - should the NTLP contain fields which are refresh times? 
|   always? sometimes?

Don't think so. Local time information should be used to 
maintain state only. Also a refresh reduction mechanism 
shouldn't require timestamps to be transmitted. If possible.

| - should the NTLP have a bit in its header which 
|  distinguishes between state refreshing and other messages?

As the refresh message initiates completely new state in the 
case of a route change in new routers, the refreshes 
shouldn't be "marked". Your idea is to distinguish between a 
refresh of state and a modification of this state?  
Valid Point. It may be more useful to have 
"state set up & modification" messages instead of 
"state set up & refresh" messages. The NLTP 
receiving a "state set up" with an already existing session 
ID knows that this is a refresh and acts accordingly. 

| - should the NTLP make up its own mind whether to acknowledge 
|   state creation or deletion messages?

The fast answer is: no, that's an issue of NSLP. It gets 
tricky should NTLP maintain state also for services without 
local NSLP support (the NTLP relay case). I think we should 
clarify what these NTLP relay nodes are supposed to do with 
messages they have no NSLP support for. Or whether we 
allow such a NTLP relay function at all. My personal 
feeling is:
- NTLP relay may be useful.
- NTLP service state maintenance only if NSLP is present.
In this case, each NTLP node must interpret the NSLP field 
of a "state set up" message first and then check the 
session ID.

A concern I have is whether to maintain sequence numbers in 
NTLP or NSLP only or whether to maintain them on both 
layers. If refreshes are handled by NTLP only, NTLP must 
be aware of the sequence numbers. It must maintain the 
service specific sequence numbering mechanism too. In the 
case of an NTLP relay, there's no service specific state, 
hence there's no sequence number maintenance (for relayed 
messages). It might be advantageous to let the sequence 
number mechanism count messages between adjacent NTLP 
peers only.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 31 Mar 2003 15:42:09 +0100

hi Rüdiger,

i think i (personally) sympathise with more than 50% of your answers, which i summarise as:
*) NTLP messages don't have visible timing information
*) the NTLP doesn't make up its own mind about whether to acknowledge messages.

on the 'special treatment for refresh' this seems to be the most interesting case, but where you say '... knows this is a refresh and acts accordingly' what does 'accordingly' mean? how can the NTLP know it is allowed to do something special other than treating the message with less urgency (which then implies knowing about timing information...)

you are right to emphasise the difference in the cases where there is/isn't an NTLP-only relay in the picture. my interpretation of what you say is that where there is a relay, it shouldn't do state management (which is yet another reason why the NTLP itself shouldn't do state management).

your comments on sequence numbering are interesting but I think closer to protocol design than [I want|I am allowed|it is sensible to get] in this discussion.

cheers,

robert h.

> -----Original Message-----
> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 27 March 2003 08:51
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: RE: [NSIS] state management question
> 
> 
> Robert,
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 31 Mar 2003 15:42:14 +0100

georgios,

two questions:
*) regardless of whether the general idea of soft stateness is good and how well it works in RSVP, why support it explicitly in the NTLP - why isn't this a signalling application issue? if something is needed in the NTLP, why isn't it an implementation issue?
*) assuming the answer is still 'it is meaningfully part of the NTLP', what kind of detectable impact on the actual protocol would you expect it to have?

what i'm trying to make progress from is the generalised view 'let's put soft state in the NTLP' and turn that into a concrete statement whose impact on the framework can be evaluated. at the moment, it seems to be a matter of opinion whether the question has no meaning or very deep meaning (at least to me).

robert h.

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 31 March 2003 14:49
> To: [email-masked]
> Hi all
> Since the RSVPv1 (RFC2205) refresh procedure and the 
> management of refresh 
> timers work quite well I think that it should be reasonable 
> to try and 
> reuse them in NTLP.
> 
> Best Regards,
> Georgios
> 
> Sent: donderdag 27 maart 2003 9:51
> To: [email-masked]
> Cc: [email-masked]

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 31 Mar 2003 16:45:44 +0200

Hi Melinda

I am not against on combining RFC2205 and RFC2961 for providing 
state management, but in my opinion
RFC2961 is used as an optimization solution and therefore,
it should not be stated as a mandatory solution, but as an
optional solution!

Best Regards,
Georgios

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: maandag 31 maart 2003 16:36
To: Roland Bless
Cc: Georgios Karagiannis (ELN); [email-masked]
Subject: Re: [NSIS] state management question 

> Sorry, I disagree here if you do not include RFC 2961 as well.
> If I remember correctly, there was a consensus to use at least
> both 2205+2961 as a starting point.

That is correct, although that decision should probably be
confirmed on the mailing list.  I don't recall anybody
voicing objection to it at the meeting.

Melinda

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 31 Mar 2003 16:00:05 +0100

i support this consensus view. 

i.e. some functionality like that of 2961 should be part of our overall solution, and some parts of 2961 should be replicated in the NTLP. (whether they should be mandatory/optional to implement/use is a question we'll get on to.)

my reading of 2961 is that it doesn't change the underlying concepts of soft state maintenance *within* nodes, but it provides some 'lower layer' functions which make it possible to issue refreshes more efficiently. (i believe a mandatory NACK and optional ACK; in general I think you need one and then the other is an optimisation.)

one facet of the question before us is therefore: should the NTLP do the equivalent of decision making between summary and full refreshes (knowing when each is appropriate and sending the appropriate messages to make it happen); or, should it just provide transport-like functions (ACK and/or NACK) to enable a soft-state-based signalling application to reduce the refresh load it generates; or, should it do neither.

(my preference at the moment is the second, certainly not the first.)

cheers,

robert h.

> Sent: 31 March 2003 15:36
> To: Roland Bless

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 31 Mar 2003 17:04:05 +0200

Hi Robert

The NTLP states are in my opinion different than the 
NSLP states.
The NTLP states are more associated with forwarding behavior and 
the NSLP application states are reservation states.
One can use the NTLP state management procedure to maintain the 
NSLP (reservation) states, but this cannot be done the other way around!
This is for example valid when not all NSIS nodes support NSLP functionality
(but they support NTLP functionality).

Best Regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: maandag 31 maart 2003 16:42
To: Georgios Karagiannis (ELN); [email-masked]
Subject: RE: [NSIS] state management question

georgios,

two questions:

robert h.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 31 Mar 2003 16:12:48 +0100

hi georgios,

you are right to point out this difference.
(in the email at the start of the thread: "(Note that this is entirely not about state that the NTLP uses internally, e.g. to route messages correctly.)")

so, my question is about the assertion:
"One can use the NTLP state management procedure to maintain the NSLP reservation) states"

(can one really? is it a good idea? is it more than an implementation issue?)

especially, if it is more than an implementation issue, ***what is the actual impact on the protocol?*** (in broad terms, or giving an example)

cheers,

r.

> Sent: 31 March 2003 16:04
> To: Hancock, Robert; [email-masked]
> *) regardless of whether the general idea of soft stateness 
> is good and how well it works in RSVP, why support it 
> explicitly in the NTLP - why isn't this a signalling 
> application issue? if something is needed in the NTLP, why 
> isn't it an implementation issue?
> *) assuming the answer is still 'it is meaningfully part of 
> the NTLP', what kind of detectable impact on the actual 
> protocol would you expect it to have?
> 
> what i'm trying to make progress from is the generalised view 
> 'let's put soft state in the NTLP' and turn that into a 
> concrete statement whose impact on the framework can be 
> evaluated. at the moment, it seems to be a matter of opinion 
> whether the question has no meaning or very deep meaning (at 
> least to me).
> 
> robert h.
>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 31 Mar 2003 17:16:25 +0200

Hi Robert

I do not understand your question.
Are you saying that we need to have two
refresh management procedures?
One for NTLP states and one for NSLP states!

Best Regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: maandag 31 maart 2003 17:13
To: Georgios Karagiannis (ELN); [email-masked]
Subject: RE: [NSIS] state management question

hi georgios,

cheers,

r.

---

From: [email-masked]
Date: Mon, 31 Mar 2003 16:32:23 +0100

if you do: 

"One can use the NTLP state management procedure to maintain the NSLP
reservation) states"

Then are you running the risk of losing the benefits of separating out the
two protocols in the first place?

Louise

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: 31 March 2003 16:13
To: 'Georgios Karagiannis (ELN)'; [email-masked]
Subject: RE: [NSIS] state management question

hi georgios,

you are right to point out this difference.
(in the email at the start of the thread: "(Note that this is entirely not
about state that the NTLP uses internally, e.g. to route messages
correctly.)")

so, my question is about the assertion:
"One can use the NTLP state management procedure to maintain the NSLP
reservation) states"

(can one really? is it a good idea? is it more than an implementation
issue?)

especially, if it is more than an implementation issue, ***what is the
actual impact on the protocol?*** (in broad terms, or giving an example)

cheers,

r.

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 31 Mar 2003 16:39:26 +0100

Louise,

I agree 100% (and that doesn't happen often).

Keep the split (architecturally) clean or don't do it at all. In the meantime, we should get some implementation experience (or at least thought experiments) to see how much harder it really makes our lives.

Cheers,

Robert H.

> From: [email-masked] [mailto:[email-masked]]
> Sent: 31 March 2003 16:32
> To: Hancock, Robert; [email-masked]; 
> [email-masked]