Subject: RE: [Ieprep] RE: network congestion, VoIP, NCS contracting approa ch, etc.

From: "Nguyen, An" <[email-masked]>
Date: Wed, 13 Nov 2002 13:57:21 -0500

Bill,

    > Reliability for emergency traffic is something NCS would like to
    > work on next.

>Wrong order of approach.  You don't want to create a problem and then fix
>it.  If you take on reliability first, you'll never create a hole to dig
>yourself out of.

Well, I am not talking for the IETF organization. I am talking the effort
being worked in the T1 organization on behalf on the NCS. Sorry for not
stating it clearly.

Regards,

An

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

---

From: "Nguyen, An" <[email-masked]>
Date: Wed, 13 Nov 2002 20:09:03 -0500

Rex,

Agreed with you on this. What I meant to say was that T1 attempts to address
some of the fourteen requirements for ETS in the 
NSTAC(National Security Telecommunications Advisory Committee to the
President) report. Reliability, availability and priority are some of those
requirements. We have not addressed any of those yet, and have not assigned
any priority to them yet. Your comments are well-taken.

Thanks,

An
-----Original Message-----
From: Rex Buddenberg [mailto:[email-masked]]
Sent: Wednesday, November 13, 2002 4:26 PM
To: Nguyen, An
Cc: 'RJ Atkinson'; ieprep
Subject: RE: [Ieprep] RE: network congestion, VoIP, NCS contracting
approa ch, etc.

On Wed, 2002-11-13 at 11:13, Nguyen, An wrote:

> > 
> >I believe you have your priorities in the wrong order.  
> 
> >First, is it ok to translate 'reliability' into availability (up time /
> >total time) and survivability?  
> 
> >The engineering solution to the availability problems involve multiple
> >threading (elimination of single points of failure).  In most cases,
> >this tends to result in overprovision which overtake the QoS issues.  
> 
> Actually, since reliability/availability/survivability and priority are
> related to QoS in Y.1541, they will be addressed somewhat concurrently in
> the T1 organization. At least that is the plan agreed to at the last
> meeting.

Order of business is important; if you discuss concurrently, you're
likely to get into the paralysis by analysis loop you see going on here.

Availability and survivability properly belong in one bin.  And, IMHO,
it should be the first bin.  The tools to counter Ao vulnerabilities and
those to counter survivability vulnerabilities are pretty much the
same.  The only real difference is with survivability, some Bad Guy is
killing your equipment and with Ao, you're equipment is killing itself
(maintenance-induced failures are a lesser included offense here).
  
QoS control, on the other hand, requires a different toolset.  From your
para above, it's not clear whether priority is the problem or the
solution.  If you're predetermined that it's the problem, then implement
diff-serv and caveat emptor -- you've got some folks out here warning
you that the cure may be worse than the disease.  
	What I'm suggesting is that if you appropriately solve your Ao and
survivability problems, this one may or may not exist.  

(Precise language warning: if you read, say, the Defense Science Board
literature, they lump All Of The Above into a bin called 'Security'.)