Re: [Atoca] Requirement D2: "Large Audience"

"DALY, BRIAN K (ATTCINW)" <BD2985@att.com> Tue, 18 January 2011 15:42 UTC

Return-Path: <BD2985@att.com>
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 A505C28C1BE for <earlywarning@core3.amsl.com>; Tue, 18 Jan 2011 07:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.18
X-Spam-Level:
X-Spam-Status: No, score=-106.18 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
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 two2ATzG3iWM for <earlywarning@core3.amsl.com>; Tue, 18 Jan 2011 07:42:43 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 063C728C1BD for <earlywarning@ietf.org>; Tue, 18 Jan 2011 07:42:42 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: BD2985@att.com
X-Msg-Ref: server-3.tower-119.messagelabs.com!1295365519!2777691!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [144.160.112.25]
Received: (qmail 11355 invoked from network); 18 Jan 2011 15:45:19 -0000
Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jan 2011 15:45:19 -0000
Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0IFjIhE018372; Tue, 18 Jan 2011 09:45:19 -0600
Received: from td03xsmtp005.US.Cingular.Net (td03xsmtp005.us.cingular.net [135.179.64.44]) by tlph064.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p0IFjCAi018175; Tue, 18 Jan 2011 09:45:12 -0600
Received: from bd01xsmtp004.US.Cingular.Net ([135.163.18.45]) by td03xsmtp005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 09:45:11 -0600
Received: from BD01MSXMB016.US.Cingular.Net ([135.214.27.50]) by bd01xsmtp004.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 07:45:10 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 18 Jan 2011 07:45:09 -0800
Message-ID: <FDFC6E6B2064844FBEB9045DF1E3FBBC024A1E93@BD01MSXMB016.US.Cingular.Net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Atoca] Requirement D2: "Large Audience"
Thread-Index: AQF0pS6CAJ5dT1lIHb8TWmXb2B3iegJBN7VtAf32gfWUYrgE8IAAUY3m
From: "DALY, BRIAN K (ATTCINW)" <BD2985@att.com>
To: mark.wood@engineer.com, earlywarning@ietf.org
X-OriginalArrivalTime: 18 Jan 2011 15:45:10.0491 (UTC) FILETIME=[B050B2B0:01CBB726]
Subject: Re: [Atoca] Requirement D2: "Large Audience"
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <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: Tue, 18 Jan 2011 15:42:44 -0000

Mark - you have described the logic behind the development of CMAS and what that is the alerting mechanism that will be used in the US on CMRS networks as defined under FCC rules. I was the Chair of the Communication Technology Group under the FCCs CMSAAC which developed CMASM Globally this is the Public Warning System as defined in 3GPP standards.

SMS for any type of acknowledgment in a mass notification network will not work and will do more harm than good. This is wehy the FCC rules do not require acknowledgments. 
Brian K. Daly
   Sent to you by AT&T... 
   America's Fastest Mobile Broadband
       Network.  Rethink Possible.
   +1.425.580.6873
-------
Sent from my Blackberry

----- Original Message -----
From: earlywarning-bounces@ietf.org <earlywarning-bounces@ietf.org>
To: earlywarning@ietf.org <earlywarning@ietf.org>
Sent: Tue Jan 18 03:49:39 2011
Subject: Re: [Atoca] Requirement D2: "Large Audience"


Thanks Brian,

Brian's point is well made and correct, thanks Brian, but there are some
special issues that need to be borne in mind with some bearers.

I first came into this project with the brief from the UN  to "protect the
(Mobile) mobile networks from catastrophic overload situations during
disasters". 
When I "did the numbers" I discovered that the real problem is not what many
think. The bottleneck is in the mobility management system
(HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles
Kiriazakos  for the Greek government after the Athens earthquake and
subsequent crash of the Greek networks, confirmed this.  This is what lead
me to work on cell broadcast (which does not use the mobility management
system at all).

I agree that it is reasonable to allow that the acknowledgments may indeed
take much longer to 'traffic' than the outbound multicast message. Obviously
the scale is the same both ways, but while the latency is critical going
forward, the reverse path is not in the least bit time critical, so
relatively slower 'best effort'  bearers would be fine. The server which is
wishing to know its subscribers got a message may send the message both by
unicast and multicast (as mine do), but inevitably the acknowledgement will
have to be unicast. There is no specific problem in allowing the
acknowledgement of a multicast message by unicast means as long as we
understand that the latency is indeterminate. (However since it's not clear
when the ack may come, I send the message by both means simultaneously
without waiting for acks.) 

My concern is really for the Mobile Network, at layer 2. 
For example if a large number of terminals all receive a multicast at the
same time, then they will all want to acknowledge at the same time. This
will result is a tsunami wave of random access bursts to the cells uplink
timeslot, MSC call set up load, 'channel allocation algorithm' threads and
SDCCH allocation attempts. Then there will be huge load on the SMS gateways.
Mobiles that don't get an access grant message will obviously try again but
for a while the whole mobility management system will be significantly
loaded. This affects circuit switched voice just as much because the
mobility management system is common for voice and SMS, (but maybe not
GPRS?). Recall that in cellular network design, erlang calculations are done
such that it's the assumption that only a small fraction of terminals will
make random access burst attempts at any one time, so the mobility
management system is designed for this load only.

In other words, consider that a public warning message (such as a USA  CMAS
presidential message) will reach 100% of terminals simultaneously, rather
than the small percentage that the signaling system can cope with. This is
why both the CMAS and ETSI standards intentionally disallow embedded numbers
or URLs for large scale (Public) warnings.

So in fact the "scale" of the problem may not be as significant as the
impact on the local infrastructure (such as a cell). Maybe "scale" is a less
important factor than, let's say, penetration?  

On the other hand a smaller scale (of penetration)  message would not have
such a profound impact. So in some cases it may be reasonable to expect
acknowledgements in 'best effort'  time. Norway, for example,  likes this
approach.

I am unclear as to if IP systems have such problems because there is not a
'stateful'  mobility management system in the core and though acks are on a
large scale, they represent very small packets of less than 1K each. Maybe
the problem will go away in the future? Any comments on that?

Warm regards Mark Wood DRCF.




 


-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net] 
Sent: Monday, January 17, 2011 2:44 PM
To: <mark.wood@engineer.com>
Cc: earlywarning@ietf.org
Subject: Re: [Atoca] Requirement D2: "Large Audience"

It may be, but I'd like to explore this a bit anyway.

Millions of messages (acknowledgements) is a scale we can deal with today.
Hundreds of millions is probably beyond what we can deal with in a response
to a very large alert.

Most systems consist of several smaller subsystems.  The purpose of an
acknowledgement is to make sure everyone got the message.  If the subsystem
can determine that every one of its clients got it, it can report that up
the line.  It can save missed acks for later analysis, or if there are few
enough of them, report them up.

This means messages national scale which have small effectivity times can't
reasonably ask for message acknowledgement.  Anything smaller than that
probably can.

Since most alerts really don't involve hundreds of millions of
notifications, most alerts probably can ask for them.

If your delivery mechanism is multicast, the multicast mechanism itself
doesn't track who gets the alert in any way we can use.  That implies
something else is tracking who gets the alert, a complication that could
loom large.  Some systems do know who gets the alert (sometimes because it
knows who it is connected to, and all of them get the alert).  Certainly,
anything with a subscription has the characteristic that the sender knows
who all the recipients are.  

It's VERY valuable to know that every entity that should get the alert got
it.  The only other mechanism we have is some repeating of the sending in
the hopes that everyone got it.  In some cases you may have more than one
"path" to the same recipient.  That might be multiple devices, multiple
services, or multiple logical or physical connections.  You may try one
first, and if that doesn't get an ack, try another.  Although we often think
of this mechanism as needing no more than seconds to deploy, in fact many
alerts would be fine with a few minutes, and trying some things sequentially
may make sense.

So, yes, probably a Tsunami alert to all of East Asia can't ask for
acknowledgements.  An "Amber Alert" (possible abducted child) to a county
might very well.  Certainly, a snow emergency closing to the parents of an
elementary school could.

Brian


_______________________________________________
earlywarning mailing list
earlywarning@ietf.org
https://www.ietf.org/mailman/listinfo/earlywarning