ISBN: 0-471-41405 -0
Download (direct link):
While there are many sophisticated ways to improve performance over wireless networks, one of the simplest ways is also one of the most efficient ones: caching. Most users today are familiar with the concept of caching, because they know that the Web browser not always gets the information but that the Reload button will force it to perform this task. The most famous analogy involves going shopping. You store the most commonly used groceries in the refrigerator (cache) so that you do not to have to run down to the store every time you make dinner. For wireless applications, caching is utterly important— and the performance gains are often impressive. WAP uses caching extensively and also enables the application developer to control how individual objects are cached (although this task is not always easy) by setting expiration times (and so on). The size of the cache varies between different WAP devices and is likely to continue as such. For WAP developers, it is essential to test the actual interaction of the application and the cache. Objects that do not need frequent updates should be cached, and only testing will show whether things are displayed as they should be.
You can also implement caching on the client side manually in the application software, but if it is not a browser application, the difference between a cache and a smart management of client data is infinitesimal. Some middleware solutions include a general-purpose cache that stores objects that you frequently
request. The gain of such a solution varies greatly with the application that you use, but this method is an easy way of gaining performance.
Although client -side caching is the obvious way to enhance performance, server-side caching will also become more and more pervasive. With server-side caching, the main gains are not as obvious because it will not transport any less data over the air. The gain is instead load distribution and making life easier for the application servers. Some applications are peaky by nature, meaning that the usage is extremely high at a few peak times and low most of the time. This situation puts the operator or service provider in an awkward position, forcing him or her to decide whether to deploy tons of application servers that can handle peak traffic (remaining unused most of the time) or just to have a smaller amount of servers that are incapable of handling all of the traffic at a peak time. An example is the typical traffic information service that gives users instant mobile access to the latest traffic and accident information. This application will have millions of hits per hour in larger cities during commute hours, while not many will use this service in the middle of the day. Using server-side cache proxies at strategic positions will enable the clients to receive the most common requests from the cache proxy instead of the application server. As a result, the operator does not have to invest heavily in excess capacity just to handle peak traffic. An additional benefit is that the cache proxy is likely to be capable of serving each user more quickly because it is closer to the users.
You could place server-side caches/proxies in many different places (for instance, on the service network). We describe applications architectures in general, including the service network, in the next chapter.
One of the mandatory methods for coping with irregular flows is to provide buffers that are big enough. During bursts of large amounts of data, the buffer can smooth this process by storing the data until the destination can process it. Especially with the advent of high-speed 3G networks, where throughputs are in the range of hundreds of kilobits per second, it becomes important to have buffers that can handle these bursts. The problem is even more general than that, however, and is often caused by a destination device whose CPU is incapable of handling the high bit rates. The processing of the data can sometimes be very power consuming.
The problem occurs when the bandwidth (as well as the latency) is high. You can measure this level by multiplying the bandwidth (bits per second) by the RTT (in seconds). The result is the capacity of the round-trip route between the
sender and the destination. The bandwidth-delay product is measured in bits and is used as a measurement of how much data the connection maintains in the loop at one time.
On a 3G network that has lots of packet loss, the RLC layer will retransmit the lost packets (which, as we described in Chapter 6, “Unwiring the Internet,” provide an additional delay in the transmission). As a result, the bandwidth will be in the range of hundreds of kilobits per second, and the RTT will be a couple of hundreds of milliseconds. As an example, let’s say that the RTT is 400ms and the bandwidth is 400Kbps. The bandwidth-delay product will then be 400,000 bits per second x 0.4 s = 160,000 bits = 20KB. Now, let’s assume that we are receiving the data on a 3G-enabled PDA. We will need to have more than a 20KB buffer—preferably even much more in order to handle the retransmissions. This amount is quite a lot, considering that some desktop operating systems have less than half that value as a default buffer size for incoming packets (see Figure 8.4). Desktop systems were built for high bandwidth but not at the same time as high delay. Therefore, the high-speed wireless systems will set new requirements, and we will need more research in this area.