Subject: RE: [Ieprep] a little homily

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 2 Apr 2002 08:58:29 -0500

Fred,

 "- data application servers can be overloaded to such an extent that they
   are unable to support the load"

What do you think?  Suppose emergency workers just HAVE to have access to
CNN.com (or other sites) during an emergency but the CNN application servers
get overloaded. 

Suppose prioritizing and distinguishing emergency requests from others is
not in the "GET REAL" category.  Can't the Government strike a deal with CNN
to have them email (or upload) the content on some private site especially
reserved for the emergency users at periodic intervals during emergencies?
The Government could strike a deal with a number of such providers and then
specifically put up the information deemed most appropriate.  

Perhaps this would avoid the rush of CNN because the private servers are
hidden from the general population (can we do this?).  Perhaps emergency
workers could be given the URL of the private site much like a GETS card.

Kimberly

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, April 01, 2002 11:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ieprep] a little homily
> 
> 
> We certainly need to be able to do our best, and any useful 
> tool to counter 
> a credible threat is a good thing to do.
> 
> I am going to explain my reasoning with respect to multicast 
> and a special 
> multicast group of addresses. Please understand that I am all 
> for multicast 
> as a technology, and I am aware of other proposals on the 
> table. These are 
> examples, symptoms; I want to use them to address my 
> underlying concern.
> 
> Let me give you an insurance analogy. In Florida, one can 
> insure one's home 
> and property against a number of threats, including fire and 
> hurricane 
> damage. In California, where I live, one can insure one's 
> home and property 
> against a number of threats, including fire and earthquake 
> damage. I don't 
> know whether they sell earthquake insurance in Florida; I can 
> tell you that 
> they don't sell hurricane damage insurance for residences in 
> California. 
> The reason they don't sell it is because there is no credible 
> threat - 
> that's not a problem we have in California.
> 
> Over the past week, we have had a presentation by someone who 
> said he was 
> writing a draft about multicast, and we have discussed the possible 
> assignment of a set of class D addresses to emergency workers 
> in case they 
> can't get them during an emergency.
> 
> In the Class D space, there are 2^24 (roughly 16 million) 
> addresses, of 
> which 2^20 (about one million) are specified as general 
> multicast addresses 
> routable by such protocols as PIM and DVMRP. In the past 
> decade, it is 
> unlikely that more than a hundred have been in use at any given time, 
> because IP multicast is not heavily used in the commercial 
> Internet, or 
> anywhere else. Due to the low level of use, service providers do not 
> routinely go to the effort to configure the capability - they 
> don't see 
> revenue in response to the effort. The evidence that there is 
> a credible 
> threat in the class D multicast address space is not in the 
> least obvious.
> 
> And by the way, the folks looking at IP Multicast during an 
> emergency, 
> according to all reports, are not emergency workers. 
> Emergency workers 
> could presumably use video teleconferencing for certain 
> cases, but in a 
> case where we're really happy to be making audio calls work, 
> that's not the 
> top of anyone's agenda that has commented to this working 
> group. Emergency 
> workers don't use IP multicast, or if they do they haven't 
> bothered to 
> report the fact.
> 
> So these proposals come:
>   - in the complete absence of utility in contemplated 
> emergency communications
>   - without any evidence of a credible threat
>   - in a widespread absence of commercial deployment
>   - when these points were questioned (by me), without even 
> an attempt to
>    justify them.
> 
> However, if the proposal goes forward, what I hear is a 
> requirement to 
> assign addresses that will not be used to applications which 
> do not exist, 
> and a requirement for ~10,000 service providers world-wide to 
> expend money 
> on infrastructure for emergency communications which will not 
> in fact be used.
> 
> This is a waste of money, and an excellent argument for the 
> people who read 
> the recommendations of this working group to dismiss them out 
> of hand, as 
> silly and ill-considered.
> 
> If you want the output of this working group to have an 
> affect, any effect 
> whatsoever, on what people do to support emergency 
> telecommunications, the 
> output has to be credible, and this is not.
> 
> If you want the discussion to be relevant, I have two words for you:
> 
>     GGGG  EEEEEE TTTTTTT    RRRRRR  EEEEEE     A     L
>    GG GG E         T       RR  RR E         A A    L
>    GG     EEE       T       RR RR  EEE      A  A   L
>    GG GGG E         T       RRRRR   E       AAAAAAA  L
>    GG GG E         T       RR RR  E      A      A L
>     GGGG  EEEEEE    T       RR  RR EEEEEE A        A LLLLLLL
> 
> 
> Now, we know that in an emergency, a fair bit of traffic can 
> be generated, 
> causing a massive and sudden congestive collapse. This can 
> happen in three 
> ways:
> 
>   - telephone switches (PSTN and IP) can be so overloaded 
> that they are forced
>    to ignore calls while they serve the ones they have
>   - data application servers can be overloaded to such an 
> extent that they
>    are unable to support the load
>   - data trunks can be overloaded in such a way that they 
> drop a lot of traffic
> 
> We can, realistically, look at the issues in these cases and 
> ensure that 
> they are covered. This requires a gap analysis and framework 
> for emergency 
> telephone switching; this is a chartered deliverable of this 
> working group. 
> It also requires a recommendation for the management of data 
> traffic using 
> elastic applications; this likewise is a chartered 
> deliverable of this 
> working group.
> 
> If there are other credible threats, we need to surface them, 
> and we need 
> to make recommendations concerning them.
> 
> Interesting solutions that meet no credible threat are out of 
> scope. So any 
> proposal of a solution to a problem needs to identify what threat it 
> counters, and demonstrate that the threat is credible. 
> Anything which does 
> not do so is a waste of all of our time.
> 
> I dunno, may you would spend money on Hurricane insurance in 
> California. I 
> wouldn't, and I don't want this working group expending time 
> and energy on 
> that class of threat.
> 
> 
> _______________________________________________
> Ieprep mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ieprep
> 

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep