Re: [earlywarning] What problem is ATOCA trying to address?

["SENNETT, DEWAYNE A (ATTCINW)" <[e-mail]>]

This math does not factor into account the characteristics of the
cellular air interface.  This is a shared interface and there are no
radio resources associated with the cellular device except when the
device is in active communications (e.g., subscriber is on voice call).
Any given cell site has many more associated cellular devices than there
are radio resources to support. 

Consequently, a queuing model is required and would have to factor in at
least the following:

- How many cellular devices are registered on the cell site?

- How many cellular devices will enter or leave the coverage area of the
cell site during the time of the alert?

- What is the current utilization of air interface resources and how
many resources are available?

- What other communications from other sources including subscriber
initiated communications will also be occurring at the same time? 

- Since cellular devices have to be paged before communications can be
established, how many pages attempts will be required and how much time
is required for the paging function?

- How often is the alert message retried because of non-delivery due to
no available radio resources and what is the time interval between the
retry attempts?

REAL LIFE EXAMPLE:

The Minneapolis I-35W bridge collapse during evening rush hour on August
1st, 2007 is a good real life example of localized network congestion
for a localized environment.  The evening rush hour is one of the most
common highest network utilization times and this evening in Minneapolis
was no exception.  Immediately after the unfortunate bridge collapse all
of the cell sites for all wireless operators with coverage for the area
surrounding the bridge became congested and stayed congestion for a long
period of time.  

Network congestion conditions can occur on non-emergency events whenever
large groups of subscribers are concentrated in a small area -- e.g.,
New Years Eve at Times Square, weekend football game at your favorite
large university.

DeWayne 


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Henning Schulzrinne
Sent: Friday, March 26, 2010 1:47 PM
To: David R Oran
Cc: [e-mail]
Subject: Re: [earlywarning] What problem is ATOCA trying to address?

Agreed. The scalability issue is, in my view, overrated. We're not
talking about using SMS here, but let's do a little math, with lots of
rounding:

- The average per-month iPhone data consumption is 250-300 MB, i.e., 10
MB/day.

- This translates to roughly 100 KB/hour per user (obviously more during
daytime hours, but this is back-of-the-envelope) or 27 bytes/second.

- I'd guess that an alert would be about 1 KB, i.e., it's about 1% of
the average per-hour data consumption.

Very roughly, assuming you displaced normal data traffic for a
large-scale alert, even without any multicast, you could send the alert
to everyone within 40 seconds (1000 / 27).

Clearly, there could still be congestion if you wanted to send a message
to every user in New York within a few seconds or whatever the threshold
is, but I suspect that the threshold for that will get higher and higher
as normal data volume increases.

For what it's worth
(http://blog.twitter.com/2010/02/measuring-tweets.html), Twitter handles
600 tweets per second or 50 million a day. Thus, except for the largest
metropolitan areas, even such a centralized, non-scalable infrastructure
can probably work. (It would handle my community in about 10 seconds.)
I'm not advocating that we use Twitter, just that there are different
scales and uses and that modern systems scale surprisingly well. We're
no longer talking SMS here.

We do need massively scalable and efficient distribution for the "ICBM
incoming" alerts, but it is not clear that these are appropriate or
necessary for the more mundane "traffic accident on Elm Street" events -
or that the local police department would be able to use them for those
purposes.

Henning

On Mar 26, 2010, at 4:10 PM, David R Oran wrote:

> 
> On Mar 26, 2010, at 3:56 PM, DALY, BRIAN K (ATTCINW) wrote:
> 
>> Agree Art - Twitter is like SMS - no guarantee, unreliable, and prone
to
>> congestion. While in general it is good to try to get the message out
as
>> many ways as possible, at least one should be deemed "reliable".
>> 
> Sometimes reliability is the enemy of resilience. I would argue we're
mostly shooting for the latter, and the former is often over-rated,
especially if people start thinking it will work when needed and don't
think more broadly, like maybe the cell tower just fell down.
> 
> That's why I think it's extremely short-sighted to try to "exempt" any
particular device from the general IETF solution, and we should view the
particular L2-specific mechanisms as optimizations to reduce
load/congestion.
> 
> It also makes sense to view the cell-broadcast capability as an
"underlay" for delivery of the more general Internet-generated and
managed emergency alerts as opposed to some parallel and un-coordinated
capability. 
> 
> Cheers, DaveO.
> 
>> Brian
>> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Art Botterell
>> Sent: Friday, March 26, 2010 9:37 AM
>> To: [e-mail]
>> Subject: Re: [earlywarning] What problem is ATOCA trying to address?
>> 
>> On Mar 26, 2010, at 3/26/10 9:14 AM, Henning Schulzrinne wrote:
>>> And to bore everyone again with the same thing: In many cases,
>> notifications are routinely sent to people outside a specific area or
>> beyond a single network.
>> 
>> Which is why I thought it might be useful to reflect on WHY, after
all
>> these years, IP multicast has such limited scope, and on whether
similar
>> constraints might apply here.
>> 
>> Meanwhile, unicast approaches like Twitter rarely try to reach
everyone
>> on a particular local network, and they don't have any strict
>> constraints on latency or even reliability, so I'd be cautious about
>> assuming their suitability in emulation of a multicasting function.
>> Anyone who's ever tried to text on New Year's Eve or Mother's Day
should
>> be able to relate.
>> 
>> - Art
>> _______________________________________________
>> earlywarning mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> _______________________________________________
>> earlywarning mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> _______________________________________________
> earlywarning mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

_______________________________________________
earlywarning mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/earlywarning