[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.
- [atoca] The future of atoca Martin Thomson
- [atoca] ATOCA certainly still needed. 'Mark Wood'
- Re: [atoca] The future of atoca DRAGE, Keith (Keith)
- Re: [atoca] The future of atoca 'Mark Wood'
- Re: [atoca] The future of atoca Peter Saint-Andre
- Re: [atoca] The future of atoca Art Botterell
- Re: [atoca] The future of atoca Tony Rutkowski
- Re: [atoca] The future of atoca Art Botterell
- [atoca] what needs to be done yet. Mark
- Re: [atoca] The future of atoca DRAGE, Keith (Keith)
- Re: [atoca] The future of atoca Brian Rosen
- Re: [atoca] The future of atoca Hannes Tschofenig
- Re: [atoca] The future of atoca Brian Rosen
- Re: [atoca] The future of atoca Henning Schulzrinne
- Re: [atoca] The future of atoca Bradner, Scott
- Re: [atoca] The future of atoca Hannes Tschofenig
- Re: [atoca] The future of atoca Richard L. Barnes
- Re: [atoca] The future of atoca Randall Gellens