Re: [earlywarning] Finishing the Charter Text Discussions

ken carlberg <carlberg@g11.org.uk> Thu, 08 April 2010 12:18 UTC

Return-Path: <carlberg@g11.org.uk>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3513A6A55; Thu, 8 Apr 2010 05:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.092
X-Spam-Level:
X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO3TXWmNx9vt; Thu, 8 Apr 2010 05:18:17 -0700 (PDT)
Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 489C33A6A4E; Thu, 8 Apr 2010 05:18:16 -0700 (PDT)
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:49944 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1NzqgP-0003sH-QX; Thu, 08 Apr 2010 12:18:06 +0000
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE211CCD939@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Date: Thu, 8 Apr 2010 08:18:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB0EC36F-6C97-4AD2-829C-15DB162D7747@g11.org.uk>
References: <20100406111818.284140@gmx.net><BE16D422273834438B43B6F7D730220F0D1A2FDB@BD01MSXMB015.US.Cingular.Net> <C99FF8B7-61F4-4A05-8389-4F90E43F12F4@g11.org.uk> <BE16D422273834438B43B6F7D730220F0D1A338C@BD01MSXMB015.US.Cingular.Net> <OF177516DE.0905AA2A-ON852576FE.00785208-852576FE.00792751@csc.com> <EDC0A1AE77C57744B664A310A0B23AE211CCD939@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1078)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
Cc: Hannes@core3.amsl.com, "SENNETT, DEWAYNE A \(ATTCINW\)" <DS2225@att.com>, "earlywarning-bounces@ietf.org" <earlywarning-bounces@ietf.org>, Tschofenig <Hannes.Tschofenig@gmx.net>, "earlywarning@ietf.org" <earlywarning@ietf.org>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 12:18:21 -0000

Keith,

first, thanks for the well thought out comments.  I agree with a number of specific points you made (which are snipped out), but other things I find some disagreement with...

> However this usage is only good for broadcasting to all users within the cell that have turned on that type of alert (with varying degrees of optionality - the US government may not allow you to opt out of a presidential alert except by turning your phone off).

ouch, the part in parenthesis is quite speculative, at best.

> Note that cell broadcast is not the same as IP multicast - it happens at the levels below IP. IP multicast in cellphone networks will normally result in multiple point-to-point communications. Potentially MBMS could be used if deployed to support IP multicast, but that still uses the same traffic channels as other voice users.

agreed, but lets not constrain our view to just the UE->tower.  Parts of the backhaul can be prone to congestion as well, and in a direction of LTE, more components will be IP based and thus taking advantage of a layer-3 tree distribution structure.

> I believe Janet is correct that emergency alerts happen at times of network stress. Even if the incident to which they relate is not generating traffic in its own right, I suspect the first response to receiving a flood alert is to pick the phone up and call the remainder of your family to check what precautions they are taking, thus resulting in additional network traffic.

I would disagree with the above assertion.  From what I've gathered, its only a small subset of alerts that happen at times of network stress.  Clearly the 9/11 attack and the London bombings are the most acute instances of an event that grabs a lot of attention and subsequent load on networks.  However, existing systems send alerts quite often that are localized and do not automatically correlate to network stress.  

A few years ago, I spoke with several local county emergency management directors along the I-95 corridor in the North East U.S., and their day-to-day concern isn't focused on terrorism or natural disasters, but rather on hazardous materials on the highways.  Their interest is in using mechanisms like inverse-911 and localizing the alerts.

As a different example, a friend of mine in DC received an alert on his cell phone yesterday of brush fire warnings -- not that a brush fire existed, but that the conditions were favorable for one to occur.  And there certainly wasn't any corresponding stress on the cell network. 

> Therefore it is likely that 3GPP network operators have to shed traffic when major alerts are being given. Certain traffic is tagged as having special handling on the wireless part (emergency calls and authority to citizen / authority). There are two aspects to this:
> 
> -	Can they identify non-essential traffic and discard a larger proportion of this as opposed to essential traffic.
> 
> -	Can they ensure that traffic is not duplicated in the first place.
> 
> In regard to the ATOCA proposal given above, neither of these are dealt with in the charter.

My concern about the above position is that it places a requirement on ATOCA to assume that something in layer 2, or some walled garden, exists and is *deployed*.  I think all of us are in agreement with the point that Dave Oran made a while back that its ideal to take advantage of mechanisms that can optimize ATOCA solutions.  But we need to be careful in assuming that the specification of other mechanisms does not guarantee their deployment.

-ken