As we get set to march into Atlanta and gorge ourselves on a seemingly endless supply of marketing messages, new products, rehashed products and tutorials, let's look at one of the key phrases that is bound to appear more than once or twice on vendor banners: SLAs.

Now you may be thinking that stands for ''Service Level Agreements.'' However, I am very concerned it will come to be known as "Service Level Arguments." Here’s why:

We're now at that point where network users are demanding a better level of service, which vendors are beginning to provide. With that in mind, we have seen a ton of marketing hype surrounding SLAs – why they are good, whose is best, and how much money they will save users. Unfortunately, SLAs are as confusing as VLANs a few years back. Every service provider's definition of ''service level'' is different (no surprises there) and there are no solid metrics on which to judge the level of service. This means that SLAs – in almost any form – are going to be hard to understand and even more difficult to police.

As an example of how confusing even a good (i.e., positive) announcement can be, let’s take a look at Sprint’s recent service-level announcement for its Internet/intranet dialup service:

''The new performance guarantees include one of the industry's first Internet and Intranet busy-free dial access guarantee of 99 percent availability full-time, all the time. Sprint’s other IP performance guarantees include 99.5 percent availability on dedicated access and the Sprint Internet and Intranet backbones, and 140 millisecond network backbone delay for Sprint’s Intranet customers. Demonstrating confidence in its IP networks' performance, Sprint will provide customers with a 10 percent credit on their monthly dedicated port fee, among the industry's most aggressive money-back guarantees, if performance levels are not met, based on the performance of Sprint’s Internet and Intranet networks.''

1) Busy Free Access
Sprint pledges “The new performance guarantees include one of the industry's first Internet and Intranet busy-free dial access guarantee of 99 percent availability full-time, all the time.'' But does this mean that every time, for any reason, a user cannot access the Sprint network that a 10% refund is in order? What about those times when the access provider (i.e., local telco) cannot connect the call and the user gets a ''fast busy''? I’m not sure that many user modems can differentiate between that and a ''Sprint modem'' busy signal. Further, what about that refund. Is it for the entire month or just the period of time the user couldn’t access the network? And what about the 99% guarantee – is it 99% of the time that the user tries to access the service, or is it 99% of the time overall for the entire network (where Sprint relies on its own internal ''modem outage'' reports).

2) Dedicated Access 99.5% Availability
Sprint pledges ''Sprint’s other IP performance guarantees include 99.5 percent availability on dedicated access.'' But just how far into the network does that go? Does it mean access to the Sprint POP, or is it access to the network routers themselves? And what about egress from the Sprint network. Sure, 99.5% availability within the Sprint network is great, but what if the problem is the Sprint egress router that connects to the rest of the Internet? A failure of that router would not technically stop access to the Sprint network, but could be just as damaging if your end destination is not within the Sprint network.

3) Minimum Network Delay
Sprint pledges ''140 millisecond network backbone delay for Sprint’s Intranet customers.'' This is actually a good deal – if you know what your internal network application’s delay requirements are (and most users do not). From an operational perspective, I wonder how this is impacted by network down time when delay is infinite? For that matter, how is this calculated? Is this a measure from access router to egress router on the Sprint side or is it from the user’s source router to the user’s destination router? If it is within the Sprint network only, is it for each user, or is it for the entire network in aggregate? If it is the former, users must deploy some type of tracking system (Sprint does offer a good one). If it is the latter, the user must be willing to believe Sprint’s internal tracking system. But what if the user wants to monitor their delay themselves - will Sprint actually believe the user’s measurements?

Let’s take a look at some confusing issues regarding service agreements in general, such as the duration of performance loss. Is this based on performance averaged over the monthly billing cycle? Or is that at any point in time? Let’s face it, service could be really bad for a minute or two, but does that mean that a vendor is going to shell out credits for the entire month? If it is in fact based on the monthly average, then do all users of the service get the credit – even if they did not actually use the service for that particular month? Since most users still pay a monthly ''access'' fee, would they get a reduction on that fee even though the didn’t ring up any ''usage'' time?

Putting Sprint aside for a moment, we have not even touched on the ability of the typical service providers to control their own internal networks to provide for such a service. Forget the debate surrounding what "Quality of Service" and "Class of Service" actually mean – neither are available today in the mass-market Internet. Clearly, there needs to be some fairly sophisticated metrics, definitions and testing procedures to offer even the most fundamental SLA. Unfortunately, these products are only now coming onto the market and they are not free.

Users looking to sign up for these new SLA agreements might be better off taking a moment or two to make sure that the vendor can actually control their network to provide such services and is willing to put the monitoring of such services into the hands of the user. Further, understanding the scope of the service will be critical. Signing up for a really great SLA might be a great idea, but if it really isn’t end to end (i.e., desktop to server), then it probably won’t do much for your end-to-end applications.

Service providers looking to enter this space should carefully consider their actions, as promising too much too soon could backfire and cost them money over the long run - when SLA capabilities will actually exist. Those wishing to take the jump today might want to take a look at companies such as Visual Networks, which is doing some interesting work in this area.

But until we get a handle on what SLA really means, I suggest that users and vendors alike consider carefully how and when they use this term, lest it become like the early ''VLAN'' implementations – a good idea, but very, very confusing to the marketplace. There are far fewer VLANs today than originally anticipated. I only hope that SLAs don’t follow suit because they really are a good, and necessary, idea.

It is worth noting that the vendor used in this case (Sprint) actually has done a good job of trying to provide the services they claim. Even though their services are relatively basic, they are a necessary step in growing into full SLA-capable networks.

However, users should still ask these questions themselves of this particular vendor and understand the full parameters of the service before setting their own level of expectations.

Further, this service is but one of many that are about to hit the market. Some will be more complete; others will be not so lucky.

As for end to end support and true QoS capabilities in a manageable SLA, I think we'll be lucky if we see that at Networld+Interop 1999.