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

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 29 Mar 2004 10:53:45 +0100

dear all,

[trying to structure this rather long thread a little:]

I think we could probably say that there is general agreement
that 'priority and preemption should not be ignored' (which
I think was the force of Dave's original comment).

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

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 
example:
*) the draft-ash-... discusses [I think] two priorities, for
CAC (checked at admission) and restoration (after failure).
*) 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.
*) 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?)

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? Is restoration at the
per-flow level meaningful to describe? Do we even want to think
about a protocol which implies the ability to pre-empt an address?

For these reasons, I would say that putting priority and 
pre-emption concepts in the NTLP is (politely) not a good idea:
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). And all this
for something which as far as I can tell has no interactions with
the other functionality inside the NTLP.

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.) 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?
- or to make implementations easier? - or to make interactions with
SIP well defined? (But 3312 AFAIK puts the priority aspects inside
SDP with the other session parameters, and this would also tend to 
correlate with putting priority aspects in the QM, at least to me.)
More discussion is needed here.

r.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 29, 2004 05:26
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] Plans for the protocol drafts
> 
> 
> Hi Percy,
> 
> > Here is another reason why reservation priority should be 
> given strong
> > consideration for inclusion in the QoS NSLP. Suppose an emergency
> > service session is being initiated through SIP. Currently, 
> SIP does not
> > support the prioritization of session initiation and hence, 
> some work
> > needs to be done in SIP to permit this (e.g., inclusion of resource
> > priority headers). Once this is defined, the interaction 
> between SIP and
> > other protocols such as RSVP-TE will need to transfer the 
> priority level
> > of the initiated session. Having reservation priority as an integral
> > part of QoS NSLP will greatly facilitate such interactions.
> 
> At the TSVWG WG in Seoul, Fred Baker presented issues on Multi-Level 
> Preemption and Precedence:
> 
> http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-tha
t-works-01.txt

I think we may like to consider similar functionality in the NTLP, as
this seems to be relevant to many applicaitons NSIS may serve.

John

_______________________________________________
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: "David R. Oran" <[email-masked]>
Date: Mon, 29 Mar 2004 09:33:21 -0500

> I think was the force of Dave's original comment).
Fair assessment.

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

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

> CAC (checked at admission) and restoration (after failure).
Yes, that maps nicely onto establishment and holding priorities, just like 
in MPLS and RSVP.

> describing how strongly to defend a call after it has been
If these are different I must be failing to see the subtleties...

> does the concept of priority apply to flows or sessions?)
Ditto for establishment versus holding priorities.

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

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

> pre-emption concepts in the NTLP is (politely) not a good idea:
I agree that it does not belong in the transport itself, for the reasons I 
outlined above.

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

> And all this
Also agree on this.

> inputs.)
You lost me on this one. I don't see how QoS models help or hinder the 
ability to do preemption. Try again?

> However, even here, I don't see what are the real arguments
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.

> More discussion is needed here.
Certainly don't disagree that more discussion is useful.

Dave.

> this seems to be relevant to many applications NSIS may serve.
>
> John
>