Sometimes, however, I think we've gone too far. I've seen versions of all of the following: Professional driver, closed test track. Don't spill liquids on the keyboard. This coffee is hot. Don't kill yourself. Investing in commodities or the stock market implies risk. Don't do this at home. Don't do this at work. Just don't do it.

I'm no expert on product liability. For that you'd need to speak with the folks at McDonald's (remember the hot-coffee-at-the-drive-through lawsuit?). But still, I've come up with a simple, if personal, view of all this proper product use advice: Duh.

Application Limits and Baselines (Warnings) There is no "duh" in the application networkability field. There are no essential warnings--no matter how obvious. Why? Because vendors don't promise anything serious about application performance. At best, they announce expected results, customer experiences and possibilities. At worst, they promise or suggest nothing. There's no way to tell if the application has ever been tested in a WAN environment.

That's the first thing that gets me. Why promote possibilities and not real facts about an application's behavior? Why not tell me how many round-trips each transaction takes? Instead, SAP offers not data but only a complicated formula to calculate WAN requirements that is reasonably predictive of application performance. It has proven to be predictive, but it's not real evidence of SAP's testing. Where are the results stating specifics for particular scenarios, like 20 users over frame relay with 150-ms latency, among others? We need some proof.

Are users required to generate all the proof on their own? Of course. Prudent users will test a vendor's claims and focus on specific application and networking scenarios that are particular to their implementations. It would be nice to have some hard data, though.

Why not publish facts rather than conjectures? Show the maximum latency tolerance of an application. Clients ask me how high they can make the latency go. Since common frame relay latencies are 80 ms to 120 ms, all vendors would have to say is that the application won't time out until latencies reach some much longer duration. So tell me that upper limit so I can design accordingly, particularly since not all frame relay latencies are in the 100-ms range. Transoceanic latencies can be much higher, yielding a round-trip latency of more than 400 ms in some circumstances. VSAT and other networks can hit this number and worse. Even the Internet will vary into this range at whim (in case you were thinking of using virtual private networks over IP as a replacement for your leased-line or frame relay network). Will the application simply fail at 400 ms? At 250 ms? We're left guessing. Tell me when it will break--or at least prove to me that you've tried to break it!

Of course, this latency break point is not the same as user response time for that application. While network latency is a component of that response time, a full measurement of response time is based not only on network performance but also on server and client performance. (How loaded is the server? How long will it take the graphics subsystem to draw the new screen?) It's also based on the application's own architecture: How many round-trips on the network will be required to handle this transaction?