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

From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Date: Thu, 25 Mar 2010 18:18:34 -0700

It is not clear exactly what problem ATOCA is trying to solve.

The first item needed for alerting is a common alerting message. This has been defined as the CAP protocol which has been adopted by ITU. The current version is CAP 1.1 and version 1.2 is expected soon.

The second item needed is transport of CAP messages. Various techniques already exist and Brian Rosen has already introduced a draft into ECRIT to define how to deliver CAP via SIP.

The third item is distribution of the alert information. Various techniques already exist such as multicast, cell broadcast, MBMS, EAS, CMAS etc..

The fourth item is authentication and authorization of the alert origination. The functionality is country specific and these countries also have defined methods and procedures to address this.

So what item remains to be addressed by ATOCA?

<--------------------------->
DeWayne Sennett, AT&T Services, Inc.
Sent from my BlackBerry

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 21:20:23 -0400

> So what item remains to be addressed by ATOCA?

Opt-in/opt-out mechanisms, for example.

---

From: Marc Linsner <[email-masked]>
Date: Fri, 26 Mar 2010 09:42:59 -0400

> So what item remains to be addressed by ATOCA?

Any IP device, any IP network, any message (not just Fed. Gov't), all under
end-user control (opt-in, opt-out, additional locations, etc.).

-Marc-

---

From: ken carlberg <[email-masked]>
Date: Fri, 26 Mar 2010 09:53:01 -0400

+1

On Mar 26, 2010, at 9:42 AM, Marc Linsner wrote:

> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

---

From: [email-masked]
Date: Fri, 26 Mar 2010 11:15:38 -0400 (EDT)

Apologies for the slight digression. Not to be contentious, but CAP is
only part of the application payload solution. Other countries are using
other encodings instead of CAP (such as SMS) or are using additional
application solutions in addition to CAP (such as GeoRSS or GeoSMS).

Something also to be aware of WRT CAP. The OASIS EM TC has defined a set
of requirements for an enhanced OASIS "where" model (geographic) that will
be encoded as a GML application schema. The plan is to be consistent with
the PIDF-LO geodetic GML schema as well as GeoRSS GML. This work adds
additional geometries and other elements such as multipoints. These
requirements were provided by the CAP implementation community and will be
incorporated (perhaps by extension) in CAP 2.0 and future revisions of
EDXL.

Cheers

Carl

> The first item needed for alerting is a common alerting message. This has
> been defined as the CAP protocol which has been adopted by ITU. The
> current version is CAP 1.1 and version 1.2 is expected soon.
>
> The second item needed is transport of CAP messages. Various techniques
> already exist and Brian Rosen has already introduced a draft into ECRIT to
> define how to deliver CAP via SIP.
>
> The third item is distribution of the alert information. Various
> techniques already exist such as multicast, cell broadcast, MBMS, EAS,
> CMAS etc..
>
> The fourth item is authentication and authorization of the alert
> origination. The functionality is country specific and these countries
> also have defined methods and procedures to address this.
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 26 Mar 2010 11:25:11 -0400

'course CAP should just borrow PIDF-LO and thus be able to send an alert
about the hospital at 123 Main (that is, a civic "where").

Thanks for the info, should be a useful update of CAP/EDXL.

Brian

---

From: Art Botterell <[email-masked]>
Date: Fri, 26 Mar 2010 08:34:52 -0700

> end-user control (opt-in, opt-out, additional locations, etc.).

So is it possible we're really just revisiting IP multicast?

- Art

---

From: Brian Rosen <[email-masked]>
Date: Fri, 26 Mar 2010 11:44:44 -0400

We're not at the mechanism state yet.  While I imagine that the mechanisms
may include something that is "if you have multicast, use it", I don't think
that would be enough because multicast is not enabled in way too many
networks.  Sites like Twitter show us that we can get enough messages sent
out in reasonable periods of time without multicast.

Brian

---

From: Marc Linsner <[email-masked]>
Date: Fri, 26 Mar 2010 11:50:22 -0400

> So is it possible we're really just revisiting IP multicast?

I wouldn't draw that conclusion.

I would desire/expect more application around it such that an 'aggregator'
of messages from various entities might provide a service to my
specification.  IP multicast may or may not have a play.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Mar 2010 12:14:37 -0400

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. Simple example: The WiFi network in Panera Bread is unlikely to be reachable by single multicast along with the 3GPP network covering that same region, and may even be logically run from some corporate HQ.

Henning

---

From: Art Botterell <[email-masked]>
Date: Fri, 26 Mar 2010 09:26:15 -0700

On Mar 26, 2010, at 3/26/10 8:44 AM, Brian Rosen wrote:
> We're not at the mechanism state yet.

True, and that's not really what I meant.  My point was that the shapes of the problem and the constraints seem similar to the more general problem of multicasting, on which there's been a lot of prior work.

So perhaps it would be useful to enumerate the particular ways in which this problem ISN'T just an instance of multicasting.

- Art

---

From: Art Botterell <[email-masked]>
Date: Fri, 26 Mar 2010 09:36:32 -0700

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

---

From: ken carlberg <[email-masked]>
Date: Fri, 26 Mar 2010 12:45:38 -0400

so right off the top of the head, one could envision the following distribution models:

a) end-to-end unicast -- worst case scenario in terms of load concentration at a single source
b) overlay unicast segments -- retaining the the unicast only model, but pushing the distribution to a collection of nodes operating as an overlay.  Headaches include management of the overlay, but potentially higher resiliency
c) unicast/multicast servers -- can be considered an extension of (b), but in this case, include a set of nodes that take the unicast traffic and forwards it downstream via multicast to the end nodes.  There is a fair amount of work that has been done with this model, and it leverages the efficiency of multicast, where multicast is likely to only reside in access/enterprise networks

-ken

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Mar 2010 13:22:40 -0400

As it happens, our local police department uses Twitter for alerts: see

http://twitter.com/leoniapd

Works quite well.

---

From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Fri, 26 Mar 2010 12:56:08 -0700

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".

Brian

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Art Botterell
Sent: Friday, March 26, 2010 9:37 AM
To: [email-masked]
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

---

From: David R Oran <[email-masked]>
Date: Fri, 26 Mar 2010 16:10:11 -0400

> 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.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 26 Mar 2010 16:47:29 -0400

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

---

From: Art Botterell <[email-masked]>
Date: Fri, 26 Mar 2010 14:15:54 -0700

On Mar 26, 2010, at 3/26/10 1:47 PM, Henning Schulzrinne wrote:
> Agreed. The scalability issue is, in my view, overrated. 

Whether we think scale issues are real or not isn't the point.  The point is that many network operators do.  Do we want their support in this effort or not?

- Art

---

From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Date: Fri, 26 Mar 2010 15:05:00 -0700

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Friday, March 26, 2010 1:47 PM
To: David R Oran
Cc: [email-masked]
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:

> 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.