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

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

Hello Fil, 

>> -----Original Message-----
>> From: Fil Dickinson [mailto:[email-masked]] 
>> Sent: mercredi 7 juin 2006 05:34
>> To: Francois Le Faucheur (flefauch); [email-masked]
>> Subject: RE: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : 
>> Preemption scope
>> 
>> 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

>> Cheers
>> 
>> -----Original Message-----
>> 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>
>> 
>> "
>>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Jun 2006 04:05:49 -0600

Francois,

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/