[32537] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Limits of reliability or is 99.999999999% realistic

daemon@ATHENA.MIT.EDU (mdevney@teamsphere.com)
Mon Nov 27 15:28:23 2000

Date: Mon, 27 Nov 2000 12:25:44 -0800 (PST)
From: <mdevney@teamsphere.com>
To: Toby_Williams@enron.net
Cc: nanog@nanog.org
In-Reply-To: <882569A4.003849DC.00@ecmta1.enron.net>
Message-ID: <Pine.LNX.4.21.0011271216520.30731-100000@core.teamplay.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE
Errors-To: owner-nanog-outgoing@merit.edu


All--

In a perfect world, your provider says the service is always on, the
service is always on.  In the real world, we have to deal with outages --
some kids vandalise a phone box, new tech trips over some cables, some
idiot telco misimplements MPLS and brings your service down for a day....

These things happen, and sometimes we all just have to suck it down and
deal with it.  But if it happens continuously, you have to ask your
provider for some assurance that it won't keep happening.  This is what
SLAs are for.

In my experience, a company that delivers reasonable levels of service has
no need for SLAs with their clients.  The service is up, everybody is
happy.  SLAs are like your parent telling you to do the dishes again "and
get it right this time, or else you go to bed with no jell-o!"

Which s why, in looking for a vendor, I ask for an SLA.  If they have one
as a standard offering, then I know that they've messed up a lot in the
past, and will probably be messing up more than I like in the
future.  It's like the kid who never did his homework coming up to the
teacher on the last day of school asking for extra credit.  NO YOU
FOOL!  You should have done it right the last 180 days!

Anyway, just my thoughts.

On Mon, 27 Nov 2000 Toby_Williams@enron.net wrote:

> Date: Mon, 27 Nov 2000 10:14:43 +0000
> From: Toby_Williams@enron.net
> To: nanog@nanog.org
> Subject: Limits of reliability or is 99.999999999% realistic
>=20
>=20
>=20
>=20
>=20
>=20
> SLAs are the point where commercial & operational worlds collide. The num=
bers
> being offered should:
>=20
> Reflect the targeted quality of the service
> Tie in with meaningful damages for not achieving them
>=20
> In a market where I can offer 99.7% or 100% and the difference is a whole=
 day's
> service credit, I know what I'd be offering. No question.
>=20
> If on the other hand, the expectation is that I pay out a year's contract=
 value
> in cash upfront every time I miss a target in a month, then I'd only want=
 to
> offer a target that will *always* be achieved.
>=20
> In the market at the moment, the situation is much closer to the first sc=
enario
> than the second - ie damages for SLAs do not mean anything to either:
>=20
> the buyer, as compensation for not receiving the service that they have
> contracted for;
> or
> the seller as a motivation to work within the targets, because capped ser=
vice
> credit agreements do not touch the bottom line
>=20
> Today, in the IP market, it is irrelevant whether services come with 99.0=
 or
> 99.99999 SLAs & at some point the market needs to address the responsibil=
ity
> that if they are to offer a service of a certain "guaranteed" quality, th=
en they
> should stand-by that guarantee with their money and give this guarantee m=
eaning.
>=20
> I don't think this is the case at the moment, and that's why we even see =
100%
> SLA in the market - because the level of pay-outs on SLAs don't matter to=
 the
> seller.
>=20
> No. I'm not suggesting that sellers offer guarantees for consequential lo=
sses.
> Simply ones that:
>=20
> 1. give the buyer the peace of mind that if the service they've contracte=
d to is
> below par, that they will have enough money put back in their pocket for =
them to
> have replaced their service, like-for-like in the market, to cover themse=
lves
> over the period.
>=20
> 2. enable the market players to truly differentiate their service offerin=
gs by
> quality, rather than marketing.
>=20
> Toby
> [std. disclaimer of responsiblity here]
>=20
> Date: 25 Nov 2000 20:24:48 -0800
> From: Sean Donelan <sean@donelan.com>
> Subject: Limits of reliability or is 99.999999999% realistic
>=20
> <snipped for brevity>
>=20
> But back to my question. =A0What is the real requirement? =A0Amazon.COM h=
ad
> system problems on Friday, and their site was unusuable for 30 minutes,
> definitely not 99.999%. =A0But what did that really mean? =A0The FAA lose=
s
> its radar for several hours in various parts of the country. =A0What did
> that really mean? =A0Essentially every system given as an example of "hig=
h-
> availability, high-reliability" I've looked at, doesn't hold up under
> close examination.
>=20
> Is 99.999% just F.U.D. created by consultants?
>=20
> Instead of pretending we can build systems which will never fail, should
> we work on a realistic understanding of what can be delivered?
>=20
>=20
>=20
>=20



home help back first fref pref prev next nref lref last post