To help developers factor the network environment into their application designs, consider four network dimensions: narrowband versus broadband, public versus private infrastructure, fixed versus mobile, and wired versus wireless.
First, consider the narrowband wired case. Narrowband application design best practices are well known, if not always followed. The fundamental tenets are: Keep bandwidth requests low, expect latency to be high, and piggyback network requests to avoid synchronous request/response activity.
Now, think about broadband. High-speed connections provide more bandwidth than dial-up services do, but sources of delay, including router hops and packet loss, still abound. Move from a private to a public network and the situation deteriorates even further, not only in terms of delay but in terms of availability. Internet reliability still hovers between 97 percent and 99.3 percent compared with the 99.9 percent reliability of a well-engineered LAN, according to Meta Group studies. So the application must be designed to work in disconnected mode, or at least in dial-up mode, because the public broadband pipe can fail.
Finally, think about the wireless scenario. This is much like a mobile dial-up connection but with potentially better persistence--but often lacking QoS mechanisms. You can't guarantee a quality mobile network unless you've built the network yourself. In a private warehouse, for example, an application can function seamlessly while the user moves about a Wi-Fi network. But move onto a public infrastructure and the problems associated with public wired infrastructure, including high latency and low reliability, crop up. Use a cellular network and you'll get better coverage, or so the theory goes, but delay will skyrocket. Our studies of new cellular networks, including WCDMA-based 3G services, show a base latency of about three quarters of a second, which has a huge effect on application performance.
Which brings us right back to where we started. If you want application reliability, don't make assumptions about network service quality.