Load Balancing

As we have discussed earlier, in our system, a dense deployment of DAPs, coupled with the association policy limits the need for frequent load balancing. Our system uses load balancing only to correct severely imbalanced client-DAP assignments, rather than as a means to achieve ``optimal'' performance. The reason for this is simple: every client-AP reassignment, no matter how carefully done, carries with it the potential to disrupt a client's performance.

To illustrate the load balancing capabilities of DenseAP, we carry out the following experiment. We use three clients, situated in a conference room, as shown in Figure 15. We force the DC to initially assign all three clients to the conference room DAP. The clients start simultaneously downloading files from a server on the wired network. The DC correctly recognizes the overload situation, and at 1 minute intervals, reassigns two of the associated clients to two nearby APs, and sets them to operate on different channels. As a result, the throughput of all three clients improves substantially. The results are shown in Figure 18.

A similar scenario is shown in Figure 19. We use only two clients. We force the DC to associate both clients to the same AP. The first client starts a CBR UDP download that consumes 15Mbps. This roughly simulates streaming playback of a high quality video. However, this is not enough to saturate the DAP, and hence the DC does not move either client. At time 50 the second client starts a movie download as well. After one minute, the DC detects that an overload situation has occurred and moves the second client to a nearby DAP, and assigns it another channel. The 1-minute hysteresis interval is a tunable parameter of our system, and depending on system configuration and desires of the user population, can be set to a smaller or a larger value.

Figure 18: Load balancing: 3 TCP downloads

Figure 19: Load balancing: 2 CBR UDP flows

We now examine the time taken for a handoff from one DAP to another during load balancing. As we will see in the next section, it has significant implications for handling of mobile clients. Recall the sequence of steps for a handoff illustrated in Figure 3. The breakdown of time taken by each of these steps is shown in Table 2. As it has been observed in prior work [23], we see that client scanning is the most expensive step during a handoff. The 1.5 second delay may cause a TCP timeout, but won't break an existing connection. To mitigate the impact of such disruptions, our load balancing algorithm is very conservative, and moves clients only if they are associated with an overloaded DAP. Such clients would generally be experiencing poor performance in the first place.

Table 2: Breakdown of a typical handoff in DenseAP.

Step	Time ($ms$)
Disassociation	0
Scanning time	1487.6
Authentication	00.381
Association	00.689
Total handoff time	1488.67