[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 [127.0.0.1] (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 [10.91.34.44] (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 ([142.179.199.224]) 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 [192.168.9.1]) 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, 07 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/1.2.5.1i
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, 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 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 bidulock@openss7.org http://www.openss7.org/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] Re: [Tsvwg] <draft-lefaucheur-emergency-… Brian F. G. Bidulock
- [Ieprep] Re: [Tsvwg] <draft-lefaucheur-emergency-… Brian F. G. Bidulock
- [Ieprep] Re: [Tsvwg] <draft-lefaucheur-emergency-… Janet P Gunn