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

David R Oran <oran@cisco.com> Fri, 26 March 2010 22:30 UTC

Return-Path: <oran@cisco.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 C21473A6A1E for <earlywarning@core3.amsl.com>; Fri, 26 Mar 2010 15:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.819
X-Spam-Level:
X-Spam-Status: No, score=-104.819 tagged_above=-999 required=5 tests=[AWL=4.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, 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 eBl5fxMuQDpC for <earlywarning@core3.amsl.com>; Fri, 26 Mar 2010 15:30:44 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9DBC33A6A04 for <earlywarning@ietf.org>; Fri, 26 Mar 2010 15:30:43 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtQAAPvSrEuQ/uCWe2dsb2JhbACbKhUBAQsLJAYcpimZFoR+BA
X-IronPort-AV: E=Sophos;i="4.51,316,1267401600"; d="scan'208";a="58622761"
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2010 22:31:04 +0000
Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2QMV2A2024014; Fri, 26 Mar 2010 22:31:03 GMT
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: David R Oran <oran@cisco.com>
In-Reply-To: <FDFC6E6B2064844FBEB9045DF1E3FBBC093CC0@BD01MSXMB016.US.Cingular.Net>
Date: Fri, 26 Mar 2010 18:31:00 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B817408-EB38-4B9D-8A37-E6D10EB82CA7@cisco.com>
References: <FDFC6E6B2064844FBEB9045DF1E3FBBC093CC0@BD01MSXMB016.US.Cingular.Net>
To: "DALY, BRIAN K (ATTCINW)" <BD2985@att.com>
X-Mailer: Apple Mail (2.1077)
Cc: earlywarning@ietf.org
Subject: Re: [earlywarning] What problem is ATOCA trying to address?
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: Fri, 26 Mar 2010 22:30:46 -0000

On Mar 26, 2010, at 5:16 PM, DALY, BRIAN K (ATTCINW) wrote:

> Disagree - we have designed an optimized system for commercial mobile devices that will deliver alerts to devices on those networks in an efficient manner. Regardless of what IETF does CMAS will continue to be the method operators will use for delivering alerts to any device connected to the network where the operator supports CMAS. That is fact.
And TDM voice is provably a WHOLE lot more efficient than VoIP. That's a fact too. 

Nobody s arguing against using an optimized multicast/broadcast transport/underlay where such exists. We're arguing about the undesirability depending on it being there, exempting devices from requirements to handle the more general case, and limiting the architecture based on its limitations.

Imagine if we had started with SMS or Twitter instead of email as the transport architecture for applications? We'd have ATM with 140 byte cells instead of 53 byte cells.

DaveO.

(belated sarcasm alert)

> Brian K. Daly
> -------
> Sent from my Blackberry
> 
> ----- Original Message -----
> From: David R Oran <oran@cisco.com>
> To: DALY, BRIAN K (ATTCINW)
> Cc: Art Botterell <acb@incident.com>; earlywarning@ietf.org <earlywarning@ietf.org>
> Sent: Fri Mar 26 13:10:11 2010
> Subject: Re: [earlywarning] What problem is ATOCA trying to address?
> 
> 
> 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: earlywarning-bounces@ietf.org
>> [mailto:earlywarning-bounces@ietf.org] On Behalf Of Art Botterell
>> Sent: Friday, March 26, 2010 9:37 AM
>> To: earlywarning@ietf.org
>> 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
>> earlywarning@ietf.org
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> _______________________________________________
>> earlywarning mailing list
>> earlywarning@ietf.org
>> https://www.ietf.org/mailman/listinfo/earlywarning
>