Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption scope

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Tue, 6 Jun 2006 14:29:41 +0200

Hello Brian, 

>> -----Original Message-----
>> From: Brian F. G. Bidulock [mailto:[email-masked]] 
>> Sent: mardi 6 juin 2006 12:37
>> To: Francois Le Faucheur (flefauch)
>> Cc: Dolly, Martin C, ALABS; [email-masked]; [email-masked]; 
>> [email-masked]
>> Subject: Re: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : 
>> Preemption scope
>> 
>> Francois,
>> 
>> Francois Le Faucheur (flefauch) wrote:             (Tue, 06 
>> Jun 2006 11:10:36)
>> > 
>> > Can anyone identify some "emergency" service which could not be
>> > implemented with the proposed extensions?
>> > What other functional capabilities would be required from 
>> the network
>> > layer?
>> 
>> In the telephone network E911 trunks are directly connected from the
>> local exchange to the E911 center (they are not routed between
>> switches).  Switch resources in the form of switching matrix junctors
>> are "dedicated" to E911 in SPC (Stored Program Control).  If 
>> there are
>> 10 trunk members in the E911 trunk group, 10 calls can be 
>> established to
>> the E911 center from subscribers attached to the switch at any time.
>> That is 10 paths through the switch matrix (from any idle sub) are
>> permanently reserved for 911 calls.  Put another way: if the 
>> switch is
>> completely occuppied with normal calls, and additional 
>> normal calls are
>> being turned away (all trunks busy, delayed dial tone), still 10 911
>> calls can still be made to the 10 trunks.
>> 
>> I don't believe that priority queueing nor preemption adequately
>> describe that.  It is a dedicated resource.  Instead of queueing
>> with priority, it is more like reserving 10 (or whatever number of)
>> queue positions only to be used by 911 calls.  It is not preemption,
>> because only the reserved positions will be used.
>> 
>> Can RSVP protect and enforce a dedicated reserved network resource,
>> only to be used in the event of a 911 call?
 
Yes.
What you describe is one of the targetted behavior (in fact this was the
one we started with in the initial draft).

One way to achieve that is:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP
	* not using Preemption in RSVP
	* activate the Maximum Allocation Model or Russian Dolls Model
on the RSVP router (which both allow to effectively set-aside capacity
just for emergency call). 
With both models some capacity is set-aside for priority sessions. With
RDM the priority sessions call also use some of the resources of
non-priority sessions. With MAM the priority sessions can not use the
resources of non-priority sessions.
The bandwidth models as well as how they can achieve the requirement you
describe above, are discussed in section 2.1.1 and 2.1.2 of
emergency-rsvp-01 (which will be moved into an Appendix A in the
upcoming -02). 

In particular, here is one of the diagrams illustrating MAM operations
and how it sets aside resources for priority sessions:

"
             -----------------------
        ^  ^  ^  |xxxxxxxxxxxxxx|  ^
        .  .  .  |xxxxxxxxxxxxxx|  .
 Total  .  .  .  |xxxxxxxxxxxxxx|  .   Bandwidth
        .  .  .  |xxxxxxxxxxxxxx|  .   Available
 Engi-  .  .  .  |xxxxxxxxxxxxxx|  .   for non-priority use
neered  .or.or.  |xxxxxxxxxxxxxx|  .
        .  .  .  |xxxxxxxxxxxxxx|  .
Capacity.  .  .  |xxxxxxxxxxxxxx|  .
        v  .  .  |xxxxxxxxxxxxxx|  v
           .  .  |--------------| ---
           v  .  |              |  ^
              .  |              |  .   Bandwidth available for 
              v  |oooooooooooooo|  v   priority use
             -------------------------
        Chart 4. Full non-priority load 
                 & partial load of priority calls

	x represents a non-priority session
	o represents a priority session
"

Let us know if you still see part of the requirements not beeing met
properly?
(or if the description is not clear enough)

I am realising that it may be a good idea to add an Appendix which
captures some of this thread by identifying examples of "emergency"
services requirements and which combination of functionality should be
used to achieve those. Similar to the last part of my previous email,
but adding the case above.
Do you think that would be useful?

Thanks

Francois

>> Well, I suppose RSVP could, because it is just a protocol: perhaps a
>> better question would be: Is network equipment capable of performing
>> dedicated reservation of resources?
>> 
>> This reminds me of a discussion some time ago about performing best
>> effort over a reserved minimum (the best effort being normal 
>> calls and
>> the reserved minimum being 911 calls).  See the tsvwg thread
>> "[NSIS] interoperability problems between end-to-end ECN and 
>> edge-to-edge ECN"
>> from around 17 November 2005.
>> 
>> --brian
>> 
>> -- 
>> Brian F. G. Bidulock
>> [email-masked]
>> http://www.openss7.org/
>>

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Wed, 7 Jun 2006 11:13:39 +0200

Hello James, Lars, Magnus,

I would like to get some guidance from the WG chairs here.

The working assumptions behind emergency-rsvp Internet-Draft have been:

	1) the document focuses on technical capabilities required from
"network layer" control plane (when the signaling/reservation protocol
in use is RSVP) for support of emergency services

	2) the document should cover all the capabilities that are
required by the various known/desired "flavors" of emergency services

	3) recommending (let alone mandating) which "flavor" of
emergency services should be deployed where/when/why is completely out
of the scope of this document

	4) discussing which flavor is legal/illegal where/when/why is
completely out of the scope of the document

Can you confirm these are appropriate working assumptions?

If not, what do you feel those should be?
If yes, to facilitate progressing of the TSVWG deliverables, may I
suggest that we refocus the discussion on the list on "does the current
spec allows to support the various known/desired flavors?" and maybe
stay away from "which flavor is best?" and from "which flavor is
legal/illegal here or there?" (although those are certainly interesting
topics)

Thanks in advance for your recommandations

Francois

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Wed, 7 Jun 2006 12:11:10 +0200

Hello Janet, 

>> From: Janet P Gunn [mailto:[email-masked]] 
>> Sent: mardi 6 juin 2006 17:42
>> To: Janet P Gunn
>> Cc: [email-masked]; [email-masked]; Francois Le 
>> Faucheur (flefauch); [email-masked]; [email-masked]
>> Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : 
>> Preemption scope
>> 
>> 
>> 
>> 
>> 
>> I said
>> 
>>  If I remember correctly, one of Joseph  Babiarz IDs hinted at this
>> behavior, with a variant on RSVP as the mechanism.
>> 
>> I take it back.
>> I was thinking of draft-ietf-tsvwg-rsvp-bw-reduction-00.txt,
>> A Resource Reservation Extension for the Reduction of
>>                   Bandwidth of a Reservation Flow
>> 
>>                         February 10th, 2005
>> 
>>  James Polk
>>  Subha Dhesikan
>>   Cisco Systems
>> 
>>  but it doesn't seem to have survived on line.

It is alive and kicking: It is now RFC4495. 

Yes, I believe the mechanisms defined in RFC4495 could be used in
conjunction with those of <emergency-rsvp> to achieve the preemption
flavor you described in your other message ie where some "non-emergency"
sessions could have their reservation reduced to make room (if needed)
for emergency sessions. As mentioned in RFC4495, RSVP will ensure that
the end systems get notified of the reservation reduction. This allows
end-systems to react appropriately (for example fall back to a lower
bandwidth codec). This is to make sure that the bandwidth reduction does
not simply translate in huge QoS degradation on the corresponding calls.

The current version of <emergency-rsvp> allows (along with RFC4495) to
implement such a flavor of emergency, should one decide to want that.

We could add this "flavor" of emergency to the list of flavor examples
(and associated mechanisms) in the new Appendix.

Cheers

Francois

>> Janet
>> 
>> 
>> -------------------------------------------------------------
------------------------------------------------------------------------
-------------------------------------------
>> 
>> This is a PRIVATE message. If you are not the intended 
>> recipient, please
>> delete without copying and kindly advise us by e-mail of the 
>> mistake in
>> delivery. NOTE: Regardless of content, this e-mail shall not 
>> operate to
>> bind CSC to any order or other contract unless pursuant to 
>> explicit written
>> agreement or government initiative expressly permitting the 
>> use of e-mail
>> for such purpose.
>> -------------------------------------------------------------
------------------------------------------------------------------------
-------------------------------------------

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Wed, 7 Jun 2006 12:25:31 +0200

Fair enough. I've argued myself we should focus on mechanisms and stay
clear from recommendations. That means we should also stay clear from
guesses about what may or may not happen.
It will be removed unless we hear other opinion against it.

>> Sent: mercredi 7 juin 2006 12:06
>> Cc: Fil Dickinson; [email-masked]
>> Francois Le Faucheur (flefauch) wrote:       (Wed, 07 Jun 
>> 2006 11:48:01)
>> >  
>> > OK. Tweaked the text to say "This is not expacted to occur 
>> frequently".
>> > 
>> 
>> I think you should simply remove the statement altogether and wait
>> for operational experience within a theatre to determine what occurs
>> frequently or not.
>> 
>> --brian
>> 
>> -- 
>> Brian F. G. Bidulock
>> [email-masked]
>> http://www.openss7.org/
>>

---

From: "Fil Dickinson" <[email-masked]>
Date: Thu, 8 Jun 2006 12:19:18 +1000

Thanks for the cty" in SIP
	* using Admission-Priority in RSVP
	* not using Preemption in RSVP
This will not involve any preemption of session.
Different bandwidth allocation models can be used to offer different
"prioritised access to network resources". Just as examples, this
includes strict setting aside of capacity for emergency sessions as well
as simple bypass of admission limits for emergency sessions.

If one wants to implement an emergency service based on Call Queueing,
on "prioritised access to network resources", and ensures that (say)
"Emergency1" sessions can preempt "Emergency2" sessions but
non-emergency sessions are not affected by preemption, one can do that
by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP with
"Reduced_Preemption_Scope" flag
	* using Preemption in RSVP (with higher preemption priority for
Emergency1 than Emergency 2)

If one wants to implement an emergency service based on Call Queueing,
on "prioritised access to network resources", and ensure that
"emergency" sessions can preempt regular sessions, one could do that by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP without
"Reduced_Preemption_Scope" flag
	* using Preemption in RSVP (with high preemption priority for
Emergency sessions)

If one wants to implement an emergency service based on Call Queueing,
on "prioritised access to network resources", and ensure that
"emergency" sessions can partially preempt regular sessions (ie reduce
their reservation size), one could do that by:
	* using "Resource-Priority" in SIP
	* using Admission-Priority in RSVP without
"Reduced_Preemption_Scope" flag
	* using Preemption in RSVP (with high preemption priority for
Emergency sessions)
	* activate RFC4495 RSVP Bandwidth Reduction mechanisms

---

From: "Fil Dickinson" <[email-masked]>
Date: Thu, 8 Jun 2006 12:19:18 +1000

Thanks for the clarification.

Yes the document supports the model I am interested in.

Thanks for the ALRP.

The tweak in text to "This is not expacted to occur frequently" doesn't
address my concern. My problem is not to do with probable frequency over
the life of a network, but rather probable frequency under disaster
scenario's that will trigger many flavours of ETS type calls. But if no
one else thinks it is a problem, please leave it as it is. It may just
be that I am a little paranoid about wombats chewing through my fibre
and taking away half my capacity during a crisis ;-).

I support your endeavours to put together a simple flavours appendix. I
think it will be good for everyone to understand how folks around the
world do things according to the needs of their palette.
Cheers

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
Sent: Wednesday, 7 June 2006 7:48 PM
To: Fil Dickinson
Cc: [email-masked]
Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption
scope

Hello Fil, 

>> From: Fil Dickinson [mailto:[email-masked]]
>> Sent: mercredi 7 juin 2006 05:34
>> To: Francois Le Faucheur (flefauch); [email-masked]
>> Hi Francois.
>> I have read the draft and most of the discussion that has taken place

>> over the last few days. Forgive my niaivity (I don't have a telephony

>> background), but I don't think having the proposed pre-emption model 
>> for ETS calls over RSVP IP networks is the right approach. I agree 
>> with admission priority and the reservation of bandwidth for ETS, but

>> don't understand how preemption of ETS will work without placing 
>> lives at risk during an emergency.
>> For this to work, we would be depending on the setting of 
>> application-level bits to determine our priority so that the network 
>> can perform some sort of triage and take away resources from one 
>> crisis to allocate to another.
>> I think the commonsense approach is if preemption is required 
>> (because the reserved bandwidth is consumed by exisitng ETS calls) 
>> shouldn't the ETS traffic preempt the non-emergency sessions? That 
>> way all ETS is given preference to the network.

Just to be clear:
	* The current document does not recommend a particular
preemption model.
	* It allows one to NOT have any preemption at all. 
	* It allows one to have preemption localised to emergency calls
(ie no-spilling on non-emergency calls). 
	* It allows one to have preemption across both emergency and
non-emergency calls. 
	* And it also allows emergency calls to preempt non-emergency
calls only like you are suggesting above (which I would need to add to
the list of examples that I proposed to add in an Appeendix)

Based on this, do you feel the document supports the model(s) that you
are interested in?

>> In the draft under the section 2.1.1 and 2.1.2 (the MAM and RDM 
>> models) you use the phrase "...This is not expected to occur (or to 
>> occur extremely rarely)". I agree with this when we are talking about

>> networks in a normal operational state, but dissagree when the 
>> network has elements that have failed. As we are talking about ETS 
>> here I think it is risky to assume that the network is operating 
>> normally, because it is possible that the event that has resulted in 
>> ETS calls being made has damaged the network and limitted it's 
>> capacity whilst at the same time placed further demands on it from 
>> people desperate for information.
 
OK. Tweaked the text to say "This is not expacted to occur frequently".

>> In the draft under section 3.2, I think using ARP as the acronym for 
>> "Application-Level Resource Priority" may create confusion that can 
>> be avoided if at all possible.
 
OK. Turned it into ALRP.

>> With respect to a comment from Janet about the pro's and con's of a 
>> concept in the "Priority Bypass Model". I think it is better (if 
>> preemption must be used) tolarification.

Yes the document supports the model I am interested in.

Thanks for the ALRP.

The tweak in text to "This is not expacted to occur frequently" doesn't
address my concern. My problem is not to do with probable frequency over
the life of a network, but rather probable frequency under disaster
scenario's that will trigger many flavours of ETS type calls. But if no
one else thinks it is a problem, please leave it as it is. It may just
be that I am a little paranoid about wombats chewing through my fibre
and taking away half my capacity during a crisis ;-).

I support your endeavours to put together a simple flavours appendix. I
think it will be good for everyone to understand how folks around the
world do things according to the needs of their palette.
Cheers

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
Sent: Wednesday, 7 June 2006 7:48 PM
To: Fil Dickinson
Cc: [email-masked]
Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption
scope

Hello Fil, 

>> From: Fil Dickinson [mailto:[email-masked]]
>> Sent: mercredi 7 juin 2006 05:34
>> To: Francois Le Faucheur (flefauch); [email-masked]
>> Hi Francois.
>> I have read the draft and most of the discussion that has taken place

>> over the last few days. Forgive my niaivity (I don't have a telephony

>> background), but I don't think having the proposed pre-emption model 
>> for ETS calls over RSVP IP networks is the right approach. I agree 
>> with admission priority and the reservation of bandwidth for ETS, but

>> don't understand how preemption of ETS will work without placing 
>> lives at risk during an emergency.
>> For this to work, we would be depending on the setting of 
>> application-level bits to determine our priority so that the network 
>> can perform some sort of triage and take away resources from one 
>> crisis to allocate to another.
>> I think the commonsense approach is if preemption is required 
>> (because the reserved bandwidth is consumed by exisitng ETS calls) 
>> shouldn't the ETS traffic preempt the non-emergency sessions? That 
>> way all ETS is given preference to the network.

Just to be clear:
	* The current document does not recommend a particular
preemption model.
	* It allows one to NOT have any preemption at all. 
	* It allows one to have preemption localised to emergency calls
(ie no-spilling on non-emergency calls). 
	* It allows one to have preemption across both emergency and
non-emergency calls. 
	* And it also allows emergency calls to preempt non-emergency
calls only like you are suggesting above (which I would need to add to
the list of examples that I proposed to add in an Appeendix)

Based on this, do you feel the document supports the model(s) that you
are interested in?

>> In the draft under the section 2.1.1 and 2.1.2 (the MAM and RDM 
>> models) you use the phrase "...This is not expected to occur (or to 
>> occur extremely rarely)". I agree with this when we are talking about

>> networks in a normal operational state, but dissagree when the 
>> network has elements that have failed. As we are talking about ETS 
>> here I think it is risky to assume that the network is operating 
>> normally, because it is possible that the event that has resulted in 
>> ETS calls being made has damaged the network and limitted it's 
>> capacity whilst at the same time placed further demands on it from 
>> people desperate for information.
 
OK. Tweaked the text to say "This is not expacted to occur frequently".

>> In the draft under section 3.2, I think using ARP as the acronym for 
>> "Application-Level Resource Priority" may create confusion that can 
>> be avoided if at all possible.
 
OK. Turned it into ALRP.

>> With respect to a comment from Janet about the pro's and con's of a 
>> concept in the "Priority Bypass Model". I think it is better (if 
>> preemption must be used) to take all the resources required for one 
>> "call" away from another "call" (or better yet a BE flow) rather than

>> "...take 5% of the bandwidth away from each of 20 existing "calls"". 
>> If we take resources from 20 "calls" or "flows" don't we potentially 
>> degrade 20 "calls" to the point where they are useless, rather than 
>> impacting a single call. The benefit of doing this is it is cleaner 
>> and less likely to produce large numbers of fault calls from users 
>> whose service degraded.
>> 
>> One other observation I have is that ETS may mean different things to

>> different people and that the Laws surrounding preemption may need to

>> be investigated in a lot of theatres as it does not seem consistent.

I very much agree. This is why I am proposing we remain focused on the
question of "does the document support all the flavors that different
people may be interested in" and stay away from arguing about which
flavor is best.

Thanks

Francois

>> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
>> Sent: Tuesday, 6 June 2006 2:40 AM
>> To: [email-masked]
>> Subject: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption scope
>> 
>> Hello,
>> 
>> <draft-lefaucheur-emergency-rsvp-01.txt> identified two open items. 
>> This is to sollicit feed-back on resolution of the first one: 
>> Preemption Scope.
>> Thanks
>> 
>> Francois, Ken, James
>> 
>> 
>> Requirement:
>> ============
>> Quoting from <emergency-rsvp-01>:
>> "
>> It has been identified that some ETS emergency type sessions would 
>> need:
>>    - to benefit from elevated admission priority
>>    - to be able to preempt other ETS emergency type sessions (the 
>> ones with lower preemption priorities)
>>    - to not be able to preempt non-emergency sessions.
>> One approach to address this requirement is to add a new Flag in the 
>> Preemption Priority Policy Element in order to reduce the scope of 
>> the RSVP preemption mechanism to emergency sessions. Feedback is 
>> sought on this requirement and potential solution. This will be 
>> addressed further in next revisions of this document.
>> "
>> 
>> Proposed Resolution:
>> ====================
>> After more discussions, we propose to include the flag inside the 
>> "Admission Priority" Policy Element.
>> The "Admission Priority" description would be changed to something 
>> like:
>> 
>> "
>> The format of Admission Priority policy element is as follows:
>> 
>>       +-------------+-------------+-------------+-------------+
>>       |     Length                | P-Type = ADMISSION_PRI    |
>>       +-------------+-------------+-------------+-------------+
>>       | Flags       | M. Strategy | Error Code  | Reserved    |
>>       +-------------+-------------+-------------+-------------+
>>       | Rvd    | Pri|            Reserved                     |
>>       +---------------------------+---------------------------+
>> 
>> ...<clip>
>> 
>> Flags: 8 bits
>> 
>>        0x01 = Reduced_Preemption_Scope
>> 		 * When the Reduced_Preemption_Scope flag is on, in case
a 
>> Preemption policy element is signaled for this reservation, the 
>> preemption MUST be enforced ONLY against other reservations which 
>> have an elevated admission priority (i.e. which have also been 
>> signaled with an Admission Priority policy element). The preemption 
>> MUST NOT be enforced against other reservations which do not have an 
>> elevated admission priority (i.e. which have been signaled without an

>> Admission Priority policy element). As an example, this flag can be 
>> used to realize a policy where some "emergency" sessions need to be 
>> able to preempt some other "emergency" sessions but where 
>> non-emergency sessions must not be subject to preemption.
>> 		* When the Reduced_Preemption_Scope flag is off, in case
a 
>> Preemption policy element is signaled for this reservation, the 
>> preemption MUST be en take all the resources required for one 
>> "call" away from another "call" (or better yet a BE flow) rather than

>> "...take 5% of the bandwidth away from each of 20 existing "calls"". 
>> If we take resources from 20 "calls" or "flows" don't we potentially 
>> degrade 20 "calls" to the point where they are useless, rather than 
>> impacting a single call. The benefit of doing this is it is cleaner 
>> and less likely to produce large numbers of fault calls from users 
>> whose service degraded.
>> 
>> One other observation I have is that ETS may mean different things to

>> different people and that the Laws surrounding preemption may need to

>> be investigated in a lot of theatres as it does not seem consistent.

I very much agree. This is why I am proposing we remain focused on the
question of "does the document support all the flavors that different
people may be interested in" and stay away from arguing about which
flavor is best.

Thanks

Francois

>> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
>> Sent: Tuesday, 6 June 2006 2:40 AM
>> To: [email-masked]
>> Subject: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption scope
>> 
>> Hello,
>> 
>> <draft-lefaucheur-emergency-rsvp-01.txt> identified two open items. 
>> This is to sollicit feed-back on resolution of the first one: 
>> Preemption Scope.
>> Thanks
>> 
>> Francois, Ken, James
>> 
>> 
>> Requirement:
>> ============
>> Quoting from <emergency-rsvp-01>:
>> "
>> It has been identified that some ETS emergency type sessions would 
>> need:
>>    - to benefit from elevated admission priority
>>    - to be able to preempt other ETS emergency type sessions (the 
>> ones with lower preemption priorities)
>>    - to not be able to preempt non-emergency sessions.
>> One approach to address this requirement is to add a new Flag in the 
>> Preemption Priority Policy Element in order to reduce the scope of 
>> the RSVP preemption mechanism to emergency sessions. Feedback is 
>> sought on this requirement and potential solution. This will be 
>> addressed further in next revisions of this document.
>> "
>> 
>> Proposed Resolution:
>> ====================
>> After more discussions, we propose to include the flag inside the 
>> "Admission Priority" Policy Element.
>> The "Admission Priority" description would be changed to something 
>> like:
>> 
>> "
>> The format of Admission Priority policy element is as follows:
>> 
>>       +-------------+-------------+-------------+-------------+
>>       |     Length                | P-Type = ADMISSION_PRI    |
>>       +-------------+-------------+-------------+-------------+
>>       | Flags       | M. Strategy | Error Code  | Reserved    |
>>       +-------------+-------------+-------------+-------------+
>>       | Rvd    | Pri|            Reserved                     |
>>       +---------------------------+---------------------------+
>> 
>> ...<clip>
>> 
>> Flags: 8 bits
>> 
>>        0x01 = Reduced_Preemption_Scope
>> 		 * When the Reduced_Preemption_Scope flag is on, in case
a 
>> Preemption policy element is signaled for this reservation, the 
>> preemption MUST be enforced ONLY against other reservations which 
>> have an elevated admission priority (i.e. which have also been 
>> signaled with an Admission Priority policy element). The preemption 
>> MUST NOT be enforced against other reservations which do not have an 
>> elevated admission priority (i.e. which have been signaled without an

>> Admission Priority policy element). As an example, this flag can be 
>> used to realize a policy where some "emergency" sessions need to be 
>> able to preempt some other "emergency" sessions but where 
>> non-emergency sessions must not be subject to preemption.
>> 		* When the Reduced_Preemption_Scope flag is off, in case
a 
>> Preemption policy element is signaled for this reservation, the 
>> preemption MUST be enforced against any other reservation regardless 
>> of its admission priority.
>> 		* Note that when a Preemption policy element is not
signaled for 
>> this reservation, the Reduced_Preemption_Scope flag is irrelevant and

>> this session MUST NOT preempt any other session regardless of its 
>> admission priority.
>> 
>>        Other flags: Reserved (MUST be set to zero on transmit and 
>> ignored on receive)
>> 
>> ...<clip>
>> 
>> "
>> 

forced against any other reservation regardless 
>> of its admission priority.
>> 		* Note that when a Preemption policy element is not
signaled for 
>> this reservation, the Reduced_Preemption_Scope flag is irrelevant and

>> this session MUST NOT preempt any other session regardless of its 
>> admission priority.
>> 
>>        Other flags: Reserved (MUST be set to zero on transmit and 
>> ignored on receive)
>> 
>> ...<clip>
>> 
>> "
>>

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Thu, 8 Jun 2006 09:41:48 +0200

Fil,

>> address my concern. 

We'll go with your's and Brian's recommendation and remove these
statements about "expectations" of what situation may or may not occur,
and stick to description of how things work when we are in each
situation.
Thanks
Francois