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

From: "Fil Dickinson" <[email-masked]>
Date: Wed, 7 Jun 2006 13:33:50 +1000

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.

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.

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. 

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.
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 02:32:35 -0600

Fil,

Fil Dickinson wrote:                         (Wed, 07 Jun 2006 13:33:50)
> placed further demands on it from people desperate for information.

I agree that the authors should not comment on the probability of a given
scenario in the proposed solution for the lack of engineering guidelines
and operational experience necessary to assess the likelihood.

Operational experience from the telephone network shows the opposite of
what you might expect for several reasons:

- disasters/emergencies are not likely to occur during the high day busy
  hour. (e.g. 9:00 am on Mother's Day).

- normal traffic (and the reasons for it) tend to be suspended during
  the disaster/emergency.

- operational network capacity (bandwidth) of common equipment tends to
  reduce as result of the disaster and damaged equipment (calls are
  simply not able to be established at the session level).

OTOH at the session level, experience shows that the increase in call
attempts to specific destinations increases dramatically and can be
viewed as one or more mass calling event.

1. The call attempt (and, worse, reattempt) rate by individuals within
   the affected area to E911 or well known numbers of other official
   agencies (fire, police, etc) can rise dramatically.

2. The call attempt (and, worse, reattempt) rate by individuals outside
   the affected area attempting to call into the affected area rises
   dramatically (those, as you say, desperate for information, usually
   about loved ones in the affected area).

(2), above, can be (and normally is) handled through the proper
application of network controls in an orderly response remote from the
affected area.

(1), above, is very problematic to agencies local to the affected area
in attempting to deal with the situtation.  For example, although E911
trunks are dedicated from each local exchange, if 30,000 subscribers go
off-hook and dial 911, anyone picking up the phone is lucky if they even
get dial-tone.  This makes it difficult, for example, for a fire-station
in the area to call the Mayor's office.

Nevertheless, the draft addresses only the network level, and it is up
to the session level (such as described in the ieprep RFCs) to deal with
that situation.  Also, it is the responsibility of higher layer systems
to alter network allocations in accordance with prevailing conditions.

Again, after describing all possible scenarios, I agree that the draft
authors should not then have commented on the likelihood of one or
another without sufficient operational experience to support those
statements.

Telephone network operational experience might not be very applicable to
Internet telephony as each system will likely perform differently when
pushed to their breaking points.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/