Subject: RE: priority and pre-emption in NSIS (was: RE: [NSIS] Plans for t he p rotocol drafts)

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 29 Mar 2004 16:52:37 +0100

Dave,

I think we (you & me) are in agreement on not wanting this stuff
in the transport, so I've snipped those bits and we can wait to 
see if someone still wants to re-open the question.

For the rest of your comments:

> > However, I'm still pretty confused about whether there is a
> > single consensus meaning of the words, and I still don't
> > think I've seen (or understood) arguments for putting such
> > handling low rather than high in the overall NSIS architecture.
> > (There are at least 4 choices: in the NTLP; in some 'common part'
> > of NSLPs if we give up the view that NSLPs should be entirely
> > independent; in each NSLP; or in the resource descriptions [QoS
> > Models] in the case of the QoS-NSLP.)
> >
> I believe I advocated putting it in a "common semantics" 
> section of the 
> NSLPs. The justification was/is threefold:
> a) what is being "prioritized" and possibly "preempted" where 
> there is 
> resource contention are those resources themselves and not 
> transport state 
> or the resources of the transport itself. This argues for 
> these functions 
> to be "above" the transport".

agree here.

> b) when resources are to be considered for preemption, those 
> resources may 
> be of different sorts and for different NSLPs (e.g. QoS classifiers, 
> firewall pinholes, NAT translation entries). Having different 
> semantics for 
> identifying and computing ordering of different resource types is 
> inconvenient at best and a recipe for incoherent preemption 
> operation at 
> worst. This argues for putting these functions below the 
> individual NSLPs.

this is a good point.

> c) the semantics and operational characteristics of preemption are 
> reasonably well understood from prior work in MPLS and RSVP. It seems 
> unlikely that there would be substantially different 
> methodologies needed 
> for different NSIS applications. I of course can't prove 
> this, but one 
> would think that by now some kind of counter-example would 
> have emerged for 
> the need for different preemption behavior for different 
> kinds of resources 
> for the same higher-level application usages.

I think there is just very little practical experience except 
from the case of the 'bandwidth' type of resource, so little
chance for a counter-example to arise. We return to this below...

> 
> 
> > My main concern is that priority/pre-emption are actually
> > complex concepts, and trying to force all applications (or even
> > QoS models) into the same structure will probably fail. For
> I think part of the problem is in fact that people try to 
> make this too 
> complicated! Often the difference among schemes is due to 
> random people 
> redesigning things that don't need to be redesigned rather 
> than from any 
> underlying difference in requirements.

OK: my concern is that once you open even a small can of worms, 
sometimes the result is that people join the discussion by 
just bringing more worms. If there was a consensus simple definition
of priority and pre-emption that everyone could agree on, most
of my worries would evaporate.

> 
> > example:
> > *) the draft-ash-... discusses [I think] two priorities, for
> > CAC (checked at admission) and restoration (after failure).
> Yes, that maps nicely onto establishment and holding 
> priorities, just like in MPLS and RSVP.

So far as I can tell, restoration priority in the ITU sense is
not the same concept as holding ("defending") priority in the 
RSVP/3181 sense: in the 3181 model, during CAC, the preemption 
priority of the new flow is compared with defending priority of
existing flows, so both priorities are CAC-related. There is no 
separate concept of restoration priority in 3181 (at least, that
I can find.)

Note I'm not asserting that you definitely need to have 3 priority
values (e.g. that restoration priority can't be derived from the
other two), only that work would need to be done to understand 
and normalise the already existing set of concepts. And I don't
know how long that would take.

> 
> > *) RFC3181 [I think] decomposes the CAC priority into one
> > value checked when the call is admitted, and another value
> > describing how strongly to defend a call after it has been
> > admitted.
> If these are different I must be failing to see the subtleties...

see above (I may be finding subtleties where there are none).

> 
> > *) In the mobile environment, a distinction is made between the
> > priority for an entirely new call, compared to one where new
> > resources are needed because of a handover. (In NSIS terms:
> > does the concept of priority apply to flows or sessions?)
> >
> Ditto for establishment versus holding priorities.

Again, I think this is a separate concept: essentially, there
are two different reasons why you might need new resources on
an interface:
1. because there is a new session ("call") in the network, or
2. because there an existing session which is starting to use
   a new interface (e.g. because of a mobile node having moved),
   which is then higher priority than case (1).
This seems like the same reasoning behing preemption and defending
priorities (the ordering typically assumed is the same); however,
in case (2), you would be using the defending priority of the
handed-over flow to decide whether to admit it at the new node. 
So it is at least a different algorithm.

> 
> > In addition, while these concepts may be well understood for
> > QoS, and the *concept* of priority may be well understood for
> > NATs (i.e. contention for the address pool), do we really have
> > any confidence that the actual definitions derived from a QoS
> > perspective carry over to the NAT world?
> No, but do we have a counter-example? Sometimes it's best to 
> be guided by 
> intuition based on experience with existing resource 
> preemption schemes 
> that have or have not worked in the past.
> 
> > Is restoration at the
> > per-flow level meaningful to describe?
> Is this rhetorical? It's like asking if per-flow QoS makes sense when 
> resources are only allocated in aggregates. Pre-emption 
> behavior is (I 
> think) well defined in these cases. What gets complicated are 
> the policy 
> issues around choosing the state to preempt when the choice is 
> non-deterministic (as are many interesting cases). However, 
> these issues to 
> not affect the protocol - they are local algorithms.

It's sort of rhetorical: the analogue of restoration in the QoS sense
would presumably be that a NAT has some public address space, which
it then loses, and attempts to restore. If it gets the same addresses
back (or some of them) it would just allow them to continue to be used;
if the new public addresses are different, it would surely be up to
endpoints to reestablish sessions anyway. The fundamental difference
from QoS is that the QoS resource - once allocated - is not structurally
bound to that flow, it's only bound inside the node doing the allocation,
and that node can swap resources between flows while only causing a 
performance change. NATs have much less freedom about re-allocating
already allocated resources.

(Of course, you could solve this particular issue by saying 'NATs ignore
restoration priority' - if the generic object has such a thing in 
the first place. But it's just an example of where different resource
structures lead to different priority processing.)

> 
> Note: what does affect the protocol is the need to 
> communicate fate-sharing 
> and some possible intermediate states for resources which are 
> fate-shared. 
> I have a talk on this subject which I've been giving the last 
> couple of 
> months and have some suggestions for how to handle this. I 
> briefly alluded 
> to this in the NSIS meeting where I proposed that we need 
> both explicit 
> "resource sharing" identifiers and "fate-sharing" identifiers for 
> resources. I would claim that these two things are also elements that 
> belong in some commmon layer above the transport and below 
> the individual 
> NSLPs.
> 
> > Do we even want to think
> > about a protocol which implies the ability to pre-empt an address?
> >
> Yes, why not? It already happens when translation entries get 
> reused - all 
> we're doing is explicitly signaling and hence making the 
> system work better!

I just imagine certain security concerns...

[snip]

> > either we have to go through a *long* activity to define a fully
> > functional MLPP object, or we have a simple one but accept that
> > MLPP objects will appear at multiples layers (yuk).
> First, I don't see why this has to be long and complicated. 
> We have good 
> existing work to guide us. Second, I suspect that if we have 
> something well 
> designed there will not in fact be a need for custom stuff in 
> individual 
> NSLPs. The benefit of consistent preemption behavior across 
> resource types 
> should (in my mind anyway) outweigh the per-application optimizations 
> people always seem to want for dubious reasons.

This would be nice (could be a persuasive argument, in the right
hands...)

[snip]

> > So far as the QoS NSLP is concerned, I think the current approach
> > of attacking the problem via the QoS models is a good one. (One
> > implication of this is that it should consider 3181 as one of the
> > inputs.)
> You lost me on this one. I don't see how QoS models help or 
> hinder the 
> ability to do preemption. Try again?

2nd try: brain-work is under way inside the QoS-Model 'team'
to understand the problem better and to establish what the common
features are (at least for the QoS application). When we see the
results of that work we will have made some progress. (We don't
have people working on the cross-NSLP aspects, though.)

> 
> > However, even here, I don't see what are the real arguments
> > for making the MLPP aspects part of the base protocol - is 
> it because
> > there are strong interactions with the other parts of the protocol?
> No, it's because a single end-to-end application doing NSIS 
> signaling may 
> have multiple resource types from multiple NSLPs allocated 
> and it needs to 
> be able to communicate the preemption properties it wants for 
> those things 
> in a consistent way. This becomes even more critical once we 
> peel the onion 
> one more layer and look at fate sharing, where the resource 
> identifiers and 
> their preemption-properties need to be communicated in application 
> protocols as well as in NSIS.

Good point (again).

robert h.

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