Subject: RE: [NSIS] state management question

From: [email-masked]
Date: Tue, 1 Apr 2003 12:45:43 +0300

HI Melinda,

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

There was no object at the meeting - however, I'll send
a mail, to confirm the consensus.

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

---

From: [email-masked]
Date: Tue, 1 Apr 2003 16:15:37 +0300

Hi Georgios,

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

2961 was a response to issues found in RSVP deployment.  I think
that if we ignore them, it would be unwise.  At present, I think
we should include them into the design of NTLP - however, they
functionality may be considered as something which needs to be
supported but not mandatory to use.

If you have issues with parts of 2961, it would be interesting to
know what are the technical issues, etc. that you have.

John

---

From: [email-masked]
Date: Tue, 1 Apr 2003 16:16:48 +0300

Roland,

> > RFC2961 describes an optimization procedure!
> 
> IMO it describes a number of operational problems
> and solutions for them due to feedback of implementers
> and operators. RFC 2961 won't be there if it was pure 
> optimization. However, there may be some environments 
> in which these extensions are not necessarily required.
> But I got the impression from several discussions that
> most people think that RFC 2205 alone is not sufficient for
> most cases.

I agree & paraphrasing, the extensions are probably mandatory
to implement - optional to use.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 1 Apr 2003 17:14:04 +0200

Hi John

I agree with your proposal!

Best Regards,
georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 1 april 2003 15:16
To: Georgios Karagiannis (ELN); [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] state management question 

Hi Georgios,

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 1 Apr 2003 17:26:43 +0200

Hi Robert 

I think that we should anyway decouple the lower and upper layer state 
management procedures. 
However, I am in favor of using NTLP refresh messages to 
refresh the NSLP states. 
The NSLP refresh procedure can be based on the NTLP refresh procedure
in the following way:
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 node is not refreshed on time then the
NTLP functionality at this node informs the NSLP state that
the refresh procedure is unsuccessful. The NSLP state can then be 
tear down.

Best Regards,
Georgios
PS. I will be out of office until the 9th of April

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: maandag 31 maart 2003 17:36
To: [email-masked]
Subject: RE: [NSIS] state management question

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.

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 31 March 2003 16:16
> To: Hancock, Robert; [email-masked]
> 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
> 
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: maandag 31 maart 2003 17:13
> To: Georgios Karagiannis (ELN); [email-masked]
> 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: Georgios Karagiannis (ELN)
> > [mailto:[email-masked]]
> > Sent: 31 March 2003 16:04
> > To: Hancock, Robert; [email-masked]
> > 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
> > 
> > From: Hancock, Robert [mailto:[email-masked]]
> > Sent: maandag 31 maart 2003 16:42
> > To: Georgios Karagiannis (ELN); [email-masked]
> > 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
> > > 
> > > From: Geib, Ruediger [mailto:[email-masked]]
> > > Sent: donderdag 27 maart 2003 9:51
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > 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: Michael Thomas <[email-masked]>
Date: Tue, 1 Apr 2003 10:41:07 -0800 (PST)

Hancock, Robert writes:
 > 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.

  Ok I'm probably clueless here, but isn't that a function
  of application layer logic? That is, the really interesting
  state installed for which might want to make that kind of decision
  is (almost?) always at the application layer? Is there any
  kind of transport state which would benefit which is *divorced*
  from the need to reinstall the application layer state too?

	   Mike

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 2 Apr 2003 09:18:38 +0100

hi tom,

>   One question is whether the same NTLP path will serve more 
> than one NSLP 
> application (e.g. resource reservation, firewall control) at once.

Topologically, it seems certain that this situation will arise (see also framework section 3.2.1).

For example, you could have a flow between two widely separated networks, with signalling between the firewalls for those networks; you could have resource reservation signalling (for the same flow) aimed at the network between those firewalls. So, there will be NSIS-aware nodes which see the signalling for more than one NSLP at the same time. And the firewall nodes might process both applications.

How much the different NSLPs interact with each other is another question - there are several options. One case would be for any two NSLP peers to communicate directly over a dedicated NTLP 'thing' (this would imply some sort of explicit discovery); another would be that messages from all NSLPs are bundled together in a single NTLP 'thing' and processed by every NSIS-aware node at least to some extent (practically unavoidable if you use PATH-like addressing). There are exceptionally strong views on each side.

My preference would be that the NTLP should not in any case be aware of interdependencies between signalling applications. This becomes easier to ensure, the thinner the NTLP becomes, and gives the NTLP more freedom to do clever transport-related things without suffering from the law of unintended consequences.

cheers,

robert h.

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 2 Apr 2003 09:38:32 +0100

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

I'd be honoured to be clueless along with you, but I can't quite parse your sentences.

a) If you are saying 'only the application can decide how interesting its state is' I agree. What I'm trying to determine is if there is any actual real meaningful non-trivial content in the various comments to the effect that "the NTLP should do something about signalling application state management", like provide different classes of something which the application could choose between, or whether the NTLP should just move bits (my increasing preference).

b) If you are saying that there is no NTLP state which needs to be managed anything other than softly (and hence that there is no need for ACK/NACK functions at the NTLP layer), I would say that depends on some details of required NTLP functionality, in particular what events it needs to signal up to applications. For example, we are currently assuming that the NTLP handles route change detection and mobility events; you might not want to rely only on soft-state refreshing to ensure you didn't miss these. This is an NTLP design question (but largely independent of what the supported signalling applications are).

c) If you are saying that if there is a need for ACK/NACK functions to support signalling applications then they might as well be in the signalling application, I think I probably disagree. Retransmission is actually a very hard problem with subtle interactions with congestion control, round trip timing, it's hard to do well on individual low rate message flows, and so on. If it's needed at all I'd rather see it done properly, once and for all, in the NTLP. (The discussion of whether it is needed is still to come, of course. I'd rather bottom out the state management stuff first.)

cheers,

robert h.

---

From: [email-masked]
Date: Wed, 2 Apr 2003 12:04:56 +0300

Hi Tom & Robert,

> > than one NSLP application (e.g. resource reservation, firewall control) 
> > at once.
> 
> Topologically, it seems certain that this situation will 
> arise (see also framework section 3.2.1).

Agreed.

[text clipped]

> My preference would be that the NTLP should not in any case 
> be aware of interdependencies between signalling 
> applications. This becomes easier to ensure, the thinner the 
> NTLP becomes, and gives the NTLP more freedom to do clever 
> transport-related things without suffering from the law of 
> unintended consequences.

I agree with Robert.  We discussed this at the interim meeting, and
(I think) decided was a can of worms that we did not want to open
(yet).

John