Subject: [Ieprep] identification of problem

From: "King, Kimberly S." <[email-masked]>
Date: Mon, 9 Dec 2002 06:17:45 -0500

>Second, we often discuss solutions leaving the important 
>requirements. For example, most of the ieprep requirements 
>can be satisfied by over-provisioning. I can provide you with 
>more solutions for ieprep(multicast, sensor networks, separate 
>spectrum as proposed in EMTEL, overlay architecture,
>VPN, ISLAY, QoS models etc...) I remember Fred slamming many for 
>discussing the solution space. So, first lets do some 
>requirements work before thinking about solution. It is relevant 
>only when we talk about BCPs. 

Fred was absolutely right in discouraging discussions of solutions space
before requirements.  However, something even more fundamental is missing--a
concise statement of the problem to be solved.  

Over two *years* ago, Sean Donelan asked some probing questions.
( http://www.iepscheme.net/archive/0045.html )
"What problems have emergency service users actually had using the
Internet?"

"Have they really had identical problems as with the switched telephone
network, or different problems which don't happen with the switched phone
network."

While the first question is just as open today, we do have some evidence
related to the second one.  Please read the outstanding report "The Internet
Under Crisis Conditions: Learning from September 11 (2002)"
http://www.nap.edu/books/0309087023/html/.  

At the crux of the matter, the Internet is not centrally controlled, is
extremely survivable, and was specifically engineered to avoid congestion
collapse so *if* the problem is to avoid congestion collapse in an emergency
(as defined by the way the PSTN collapses in an emergency) then the answer
probably is that the Internet already does that.  The Internet adapts to
congestion and additionally the evidence shows that people adapt to how they
use the Internet (the communications become more succinct and less rich)
when a traditional emergency hits.  Neither adaptation is possible in the
rigid PSTN world of applications that reserve constant bit rate bandwidth.

More realistically, Internet communications might be more likely to
temporarily collapse from various widespread security attacks than from
increases in user usage or some physical damage as the result of an
emergency.  

In order to discuss requirements, there has to be a crisp definition of the
problem to be solved.

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

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 9 Dec 2002 05:53:36 -0600

> In order to discuss requirements, there has to be a crisp definition of the
    make the charter narrow with specific problems.
 Lets work on problem statement and emergency user requirement
(from various emergency response agencies)  before concentrating
on elastic/inelastic requirements. 

> http://www.nap.edu/books/0309087023/html/. 
      I like the report for its measurement perspective which helps
 us understand how redundant/robust Internet 
 when compared to PSTN.  Note that the report says we still
lack some  measurement infrastruture to accurately measure
the performance.
    But, their are lot of difference between their goal and ours.
They studied robustness of Internet whereas we are focusing
on facilitating effective communication between emergency users 
during times like 9/11. 

Yes studying Robustness of Internet is interesting..e.g.
     - How can we make BGP robust to all code-red/misconfigurations
     - How can we make DNS more robust to DoS attacks
     - How can we make TCP robust to packet re-ordering
     - Any enhancements to RED for robustness (RED-nounce )
     -  How can i use triggers to make robust transport communication
    - What are the features to track DoS 
    - any architectural considerations for making robust systems
    - Robust coding issues (making all protocol stacks to be resistent to
      DoS )
   etc etc.
But all the above issues are totally out of scope. But, sure making
various components of Internet structure  more robust is _one_ of 
many solutionns to support emergency users.  Hence, I accept with 
kimberly that we have to write problem statement/emergency user 
requirements before diving into that part.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: [email-masked]
Date: Tue, 10 Dec 2002 10:19:24 EST

In a message dated 12/9/2002 2:19:05 PM Eastern Standard Time, 
[email-masked] writes:

And you seem to think that "local congestion" doesn't qualify as collapsed
for the PSTN (which I disagree with), but why do you have such a blatent 
double
standard that it does qualify as collapsed in the IP network case ?

[MAP] I have never said or implied that I thought that a "local congestion" 
qualifies as "collapsed" in the IP network case. The whole point I've been 
trying to make is the need to develop ways to deal with "local congestion", 
i.e., congestion on a single link which the emergency traffic is trying to 
use. (I've been told that no IP routing protocol can route around such 
congestion and it will result in all calls getting equally poor quality.) 
When claims have been made that there is no problem, I've asked for specific 
solutions to specific cases, but have gotten nothing but sarcastic responses, 
either that the requirement doesn't exist, or that the case I'm describing is 
stupid.

I'd like to hear a specific solution to the congestion case I detailed in my 
e-mail of 6 Dec. I have to take the absence of serious answers as an 
indication that there are none.

Mike Pierce
Artel