[atoca] what needs to be done yet.

"Mark" <mark.wood@engineer.com> Sat, 21 July 2012 21:06 UTC

Return-Path: <mark.wood@engineer.com>
X-Original-To: atoca@ietfa.amsl.com
Delivered-To: atoca@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4078B21F8530 for <atoca@ietfa.amsl.com>; Sat, 21 Jul 2012 14:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level:
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3JrNoJX9kzr for <atoca@ietfa.amsl.com>; Sat, 21 Jul 2012 14:06:11 -0700 (PDT)
Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2929121F852D for <atoca@ietf.org>; Sat, 21 Jul 2012 14:06:11 -0700 (PDT)
X-Trace: 602275040/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ON_NET_AUTH_ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@engineer.com
X-SBRS: None
X-RemoteIP: 81.86.43.86
X-IP-MAIL-FROM: mark.wood@engineer.com
X-SMTP-AUTH:
X-Originating-Country: GB/UNITED KINGDOM
X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjoaAAgZC1BRVitW/2dsb2JhbABEqWsBj26BCIIGAQEfCDIcEQsHDQUGJD4aBh4BAQQBHYdyAROZYoNAllAHmzcCgQUDjXGNIIhrgVqCYA
X-IronPort-AV: E=Sophos;i="4.77,630,1336345200"; d="scan'208";a="602275040"
X-IP-Direction: IN
Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 21 Jul 2012 22:07:03 +0100
From: Mark <mark.wood@engineer.com>
To: trutkowski@netmagic.com, 'Art Botterell' <acb@incident.com>
In-Reply-To: <500B114B.4090209@netmagic.com>
Date: Sat, 21 Jul 2012 22:07:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Ac1nf6FmF0mraYlzTdm+zbTLkbK4LQAAcn0Q
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609
Message-Id: <20120721210611.2929121F852D@ietfa.amsl.com>
Cc: atoca@ietf.org, kathleen.moriarty@emc.com
Subject: [atoca] what needs to be done yet.
X-BeenThere: atoca@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <atoca.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atoca>, <mailto:atoca-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/atoca>
List-Post: <mailto:atoca@ietf.org>
List-Help: <mailto:atoca-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atoca>, <mailto:atoca-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Jul 2012 21:06:12 -0000

Hi Guys,

The features that make an emergency Public Warning Messaging special are; 

1 the super-massive scale of the broadcast 
(Maybe to 10s of millions of hosts)
 
2 in a handful of seconds 
(CMAS takes only 7 seconds to deliver them all),
 
3 during extreme overload, 
(CMAS uses out of band signalling)
 
4 without any foreknowledge of their addresses, 
(No data base needed by CMAS)
 
5 and in a completely stateless passive way, 
(No TCP session exhaustion possible)
 
6 which is geo specific, 
(CMAS is selective down to one cell, about 1 mile)
 
7 Must be highly resistant to Slashdot or DOS events. 
(Disasters are always without exception accompanies by Tsunami waves of
load). 

Very extensive studies carried out by both government and industry showed
that the most appropriate way of dealing with these very extreme events is
to use passive point-to-multipoint bearer services. For example in the
cellular networks, Cell Broadcast and multi media Broadcast multicast are
such bearers. This is why they had to be deployed for this special
situation. The studies were very thorough, and completely conclusive.

The closest equivalent to cell broadcast in IP is IPMulticast.  

These situations are not at all the same as the situation where CAP messages
are being signalled between relatively small numbers of well known systems
which are in a trusted relationship with each other, and there is 'stateful'
handshake relationship between hosts. This is why IMHO a completely
different philosophy is needed, and one which I don't think ATOCA have
looked at in depth yet. 

However the title of the WG clearly indicates that we should, and so as Art
says, the reality on the ground has only just this year caught up with the
subject. Well we WERE ahead of the subject, but not now!

IMHO there is work to do and we have not done it yet :-)

Mark Wood DRCF.