Subject: RE: [NSIS] state management question

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 1 Apr 2003 13:25:12 +0100

Tom,

thanks (especially for the "totally").

At the NTLP level, we are (probably) talking about state variables including next/previous NTLP peer, time since message last sent/received, and maybe a bit more information about those peers (e.g. what security association to use to talk to them, retransmission timers and so on). *However* 
a) how much such state there is depends on the details of NTLP functionality
b) how that state is managed is in principle invisible unless you are looking inside the NTLP design itself (which I am trying not to do here).

At the NSLP level, the state variables depend on the signalling application. For a soft-state resource management application, one could imagine them including a resource description, time since last update sent/received, time until expiration, maybe some status information for reservations in the process of being installed/torn down (2209 has plenty of detail of the sort of thing one might want). Other signalling applications might have rather different state requirements (including none at all). Each signalling application would clearly have its own set.

The question for us is: should the NTLP have the functionality to manage some aspects of the NSLP state variables (e.g. generating refresh messages for a resource). At the moment, my assumption is 'no', and I'm finding difficulty getting disagreement except about aspects which can be handled inside an NSLP/NTLP implementation without visible protocol impact. This does have some implications for other aspects of NTLP functionality, however.

Hoping this is not totally obscure,

Robert H.

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: 31 March 2003 17:27
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: [NSIS] state management question
> 
> 
> I've seen enough of this dialogue now to decide that this is 
> not a totally stupid 
> question.  Could we possibly get a bit more concrete and 
> indicate what sort of state 
> variables we are talking about at the NTLP level?  Is it 
> next-NTLP-hop for a given 
> NTLP session, and what else?
> 
> Hancock, Robert wrote:
> > Georgios,
> > 
> > That is one aspect of the question.
> > 
> > another way to put it:
> > Should there be a single state management procedure which 
> all signalling applications (and indeed all NSIS entities) 
> have to use?
> > OR
> > Should we decouple the lower and upper layers and allow a 
> clever implementor to integrate them for efficiency for 
> particular signalling applications?
> > 
> > (i prefer the second.)
> > 
> > another way to put it:
> > Should the NTLP internal design be determined by the state 
> management service it offers externally to signalling applications ?
> > 
> > (sounds like a bad idea to me, though i admit i am more 
> influenced by philosophical considerations in holding that view.)
> > 
> > cheers,
> > 
> > robert h.
> > 
> > 
> >>-----Original Message-----
> >>From: Georgios Karagiannis (ELN)
> >>[mailto:[email-masked]]
> >>Sent: 31 March 2003 16:16
> >>To: Hancock, Robert; [email-masked]
> >>Subject: RE: [NSIS] state management question
> >>
> >>
> >>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,
> >>
> >>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.
> >>
> >>
> >>>-----Original Message-----
> >>>From: Georgios Karagiannis (ELN)
> >>>[mailto:[email-masked]]
> >>>Sent: 31 March 2003 16:04
> >>>To: Hancock, Robert; [email-masked]
> >>>Subject: RE: [NSIS] state management question
> >>>
> >>>
> >>>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:
> >>>*) 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.
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Georgios Karagiannis (ELN)
> >>>>[mailto:[email-masked]]
> >>>>Sent: 31 March 2003 14:49
> >>>>To: [email-masked]
> >>>>Subject: RE: [NSIS] state management question
> >>>>
> >>>>
> >>>>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
> >>>>
> >>>>-----Original Message-----
> >>>>From: Geib, Ruediger [mailto:[email-masked]]
> >>>>Sent: donderdag 27 maart 2003 9:51
> >>>>To: [email-masked]
> >>>>Cc: [email-masked]
> >>>>Subject: RE: [NSIS] state management question
> >>>>
> >>>>
> >>>>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.
> >>>>
> >>>>_______________________________________________
> >>>>nsis mailing list
> >>>>[email-masked]
> >>>>https://www1.ietf.org/mailman/listinfo/nsis
> >>>>_______________________________________________
> >>>>nsis mailing list
> >>>>[email-masked]
> >>>>https://www1.ietf.org/mailman/listinfo/nsis
> >>>>
> >>>
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Tom Taylor <[email-masked]>
Date: Tue, 01 Apr 2003 09:08:14 -0500

And thank you.  This makes total sense.  I started to give a quick answer on the 
separation of NTLP and NSLP states but found I need to think a little more about it. 
  One question is whether the same NTLP path will serve more than one NSLP 
application (e.g. resource reservation, firewall control) at once.