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

[Henning Schulzrinne <[e-mail]>]

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
>