Keeping Channel Utilization High

When traffic contains a mixture of TCP and UDP flows that have various sending rates (and bottleneck link bandwidth), it is important to correctly determine the amount of channel occupancy time made available to each node. Specifically, TBR needs to adjust rate_i to reflect changing traffic conditions. For instance, the system will be under-utilized if we give each node $\frac{1}{n}$ of the available channel time but some nodes cannot consume all of their available time shares whereas others can consume more if allowed.

TBR periodically adjusts rate_i associated with each node i so that the channel utilization is kept at maximum without violating the max-min fairness constraint [6,14]. That is, the smallest rate_i in the network must be as large as possible. Subject to this constraint, the second smallest token rate must also be as large as possible.

We note that DCF in conjunction with a simple round-robin queuing scheme at the AP generally achieves the max-min notion of fairness when only TCP flows are involved. Assume that there are 3 uplink TCP flows and that one flow can only consume $\frac{1}{5}$ of the channel bandwidth (the wireless hop is not its bottleneck link). DCF will allow each of the remaining flows to consume $\frac{2}{5}$ of channel bandwidth provided that the bottleneck link of both flows is the wireless link.

TBR with any MAC protocol achieves the same fairness criteria provided that the MAC layer has the work conserving property that DCF does, i.e. each client node with data to transmit contends for channel access opportunistically. Notice that the max-min fairness criteria does not require that the actual demand of each node is known. Rather, one can simply achieve the fairness goal by incrementally giving more channel time to each competing node that can consume all the channel time made available to it [3]. We implement this general idea in TBR.

Initially each competing node starts with the desired token rate of $\frac{1}{n}$. TBR schedules a timer event called ADJUSTRATEEVENT that periodically adjusts the token rate available to each node. As shown in Figure 7, ADJUSTRATEEVENT computes the excess capacity of the under-utilized nodes, each with the actual token rate (actual_i) lower than the assigned rate by the threshold R^th. It then computes the excess capacity E^min to redistribute equally among nodes (I') that have fully utilized the provisioned bandwidth in the previous round.

The actual method of computing E^min is of little importance for the long-term correctness so long as E^min is not too big. However, E^min does affect the responsiveness of TBR to changing traffic conditions. We will discuss more about this in Section 4.5. If E^min is too large, the instantaneous throughputs experienced by flows can significantly vary. Such behaviors may increase the buffer requirements at the nodes to avoid TCP ack compression that can lead to packet drops.

Figure 7 shows a particular way of choosing E^min. We pick, among all under-utilized nodes, node m with the maximal excess capacity (the largest difference in actual and assigned token rate). Half of E^min is subtracted from m's token rate and the other half redistributed among nodes that have consumed tokens at rates close to their assigned rates. In Section 5, we show that TBR is able to keep the channel utilization high in the presence of varying traffic conditions.

Figure 7: Pseudo-code of the token rate adjustment event