[Ieprep] Re: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption scope

"Brian F. G. Bidulock" <bidulock@openss7.org> Wed, 07 June 2006 08:32 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FntSx-0003sj-IJ; Wed, 07 Jun 2006 04:32:39 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FntSw-0003sW-3N; Wed, 07 Jun 2006 04:32:38 -0400
Received: from gw.openss7.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FntSu-0007NL-LH; Wed, 07 Jun 2006 04:32:38 -0400
Received: from ns.pigworks.openss7.net (IDENT:WBM7dmV6fJm3ZaAiOmgfOad+dJI/EWVR@ns1.evil.openss7.net []) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k578WZq02313; Wed, 7 Jun 2006 02:32:35 -0600
Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k578WZW19322; Wed, 7 Jun 2006 02:32:35 -0600
Date: Wed, 7 Jun 2006 02:32:35 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Fil Dickinson <Fil.Dickinson@optus.com.au>
Message-ID: <20060607023235.B16971@openss7.org>
Mail-Followup-To: Fil Dickinson <Fil.Dickinson@optus.com.au>, "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>, tsvwg@ietf.org, ieprep@ietf.org
References: <799B0CDA650143429C5EA103965B59F80224A640@shqw2ke001.optus.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/
In-Reply-To: <799B0CDA650143429C5EA103965B59F80224A640@shqw2ke001.optus.com.au>; from Fil.Dickinson@optus.com.au on Wed, Jun 07, 2006 at 01:33:50PM +1000
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: "Francois Le Faucheur \(flefauch\)" <flefauch@cisco.com>, tsvwg@ietf.org, ieprep@ietf.org
Subject: [Ieprep] Re: [Tsvwg] <draft-lefaucheur-emergency-rsvp> : Preemption scope
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Errors-To: ieprep-bounces@ietf.org


Fil Dickinson wrote:                         (Wed, 07 Jun 2006 13:33:50)
> 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.

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

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 F. G. Bidulock

Ieprep mailing list