Re: [Atoca] Requirement D2: "Large Audience"

"Richard L. Barnes" <rbarnes@bbn.com> Mon, 17 January 2011 15:39 UTC

Return-Path: <rbarnes@bbn.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 42D733A6F42 for <earlywarning@core3.amsl.com>; Mon, 17 Jan 2011 07:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.332
X-Spam-Level:
X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 Bn0Qo13TVPmB for <earlywarning@core3.amsl.com>; Mon, 17 Jan 2011 07:38:57 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 09B563A6F43 for <earlywarning@ietf.org>; Mon, 17 Jan 2011 07:38:57 -0800 (PST)
Received: from [128.89.253.241] (port=65384 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1PerD0-000F2O-6k; Mon, 17 Jan 2011 10:41:30 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net>
Date: Mon, 17 Jan 2011 10:41:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEB331D2-4696-4522-B8F3-79CA63A0EA41@bbn.com>
References: <FDFC6E6B2064844FBEB9045DF1E3FBBC024A1E59@BD01MSXMB016.US.Cingular.Net> <002201cbb636$27cdf790$7769e6b0$@engineer.com> <5A054107-A965-433E-AAB4-D0C79FAF843E@brianrosen.net>
To: Brian Rosen <br@brianrosen.net>
X-Mailer: Apple Mail (2.1082)
Cc: earlywarning@ietf.org
Subject: Re: [Atoca] Requirement D2: "Large Audience"
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <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: Mon, 17 Jan 2011 15:39:20 -0000

Just one brief comment: Mark's statement that "it's only possible to have any kind of delivery reports regarding specific terminals on a one-to-one kind of unicast delivery" is not necessarily true.  The availability of delivery reports depends entirely on the capabilities of the terminals, and not the intervening access network.  In particular, terminals can send back delivery reports regardless of whether they are sending or receiving over broadcast or unicast.   

This pattern could actually be quite efficient in certain layer-2 networks that have broadcast downstream, unicast upstream (e.g., PON, DSL, maybe Cable IIRC).  A notification to an entire subnet takes one message, and all acknowledgements can be received in parallel.

--Richard



On Jan 17, 2011, at 9:44 AM, Brian Rosen wrote:

> It may be, but I'd like to explore this a bit anyway.
> 
> Millions of messages (acknowledgements) is a scale we can deal with today.  Hundreds of millions is probably beyond what we can deal with in a response to a very large alert.
> 
> Most systems consist of several smaller subsystems.  The purpose of an acknowledgement is to make sure everyone got the message.  If the subsystem can determine that every one of its clients got it, it can report that up the line.  It can save missed acks for later analysis, or if there are few enough of them, report them up.
> 
> This means messages national scale which have small effectivity times can't reasonably ask for message acknowledgement.  Anything smaller than that probably can.
> 
> Since most alerts really don't involve hundreds of millions of notifications, most alerts probably can ask for them.
> 
> If your delivery mechanism is multicast, the multicast mechanism itself doesn't track who gets the alert in any way we can use.  That implies something else is tracking who gets the alert, a complication that could loom large.  Some systems do know who gets the alert (sometimes because it knows who it is connected to, and all of them get the alert).  Certainly, anything with a subscription has the characteristic that the sender knows who all the recipients are.  
> 
> It's VERY valuable to know that every entity that should get the alert got it.  The only other mechanism we have is some repeating of the sending in the hopes that everyone got it.  In some cases you may have more than one "path" to the same recipient.  That might be multiple devices, multiple services, or multiple logical or physical connections.  You may try one first, and if that doesn't get an ack, try another.  Although we often think of this mechanism as needing no more than seconds to deploy, in fact many alerts would be fine with a few minutes, and trying some things sequentially may make sense.
> 
> So, yes, probably a Tsunami alert to all of East Asia can't ask for acknowledgements.  An "Amber Alert" (possible abducted child) to a county might very well.  Certainly, a snow emergency closing to the parents of an elementary school could.
> 
> Brian
> 
> 
> On Jan 17, 2011, at 6:03 AM, <mark.wood@engineer.com>; <mark.wood@engineer.com>; wrote:
> 
>> Hello chaps,
>> 
>> Yes, it's only possible to have any kind of delivery reports regarding
>> specific terminals on a one-to-one kind of unicast delivery. The Australians
>> were not considering Cell Broadcast or any other kind of multicast
>> technology as they have selected a SMS based delivery system, so this is
>> probably what they had in mind. I noticed that atoca language about this is
>> reserved mostly for the 'subscription push' kind of distribution.  We need
>> to take care not to make it look like a mandated requirement for
>> broadcast/multicast bearers. 
>> 
>> IMHO, the other special problems with multicast,  mean that it needs
>> different and special requirements and cannot be generalized with other
>> 'push' or 'pull'  technologies quite so easily, tempting though that is. I
>> think this problem happens because most IT professionals are familiar with
>> TCP and UDP but rarely use multicast so are unfamiliar with its very
>> different attributes.
>> 
>> Many vendors offer systems which do have a positive indication of who got
>> what,  and this is a good thing for applications of up to about 10,000
>> receivers. Netherlands studies showed that by the time you scale up to
>> millions,  the mass scale of all this becomes a problem, so large scale
>> systems will have to reluctantly abandon the notion of  individual
>> confirmation.
>> 
>> Besides, the police authority of a large city don't have the time, during an
>> emergency, to check out millions of replies nor take any action if someone
>> does not reply (they are too busy). On the other hand a smaller community
>> may value such a facility, so it seems that they authority will need to
>> choose whatever is appropriate for the circumstances at their discretion.
>> There is no 'one size fits all' solution so we will have to blend many
>> bearers in any real situation.  For example the Norwegians take the opposite
>> view.
>> 
>> However, it is possible to confirm that the multicast was transmitted, as a
>> network of feedback receivers is envisaged in conjunction with an outer loop
>> reporter system, which would report of the message was transmitted on air.
>> If it did not, then an alarm would be generated by the originating
>> aggregator for the log file. So the positive indication of the fact of the
>> transmission over the air is satisfied even though individual delivery is
>> not. 
>> 
>> In summary, IMHO,  Broadcast/multicast bearers will need special treatment
>> as they don't neatly conform to the classic notions of 'push' or 'pull'. 
>> 
>> Warm regards, Mark  Wood.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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