Check out the new USENIX Web site. next up previous
Next: Computing Channel Occupancy Time Up: Time-based Regulator Previous: Time-based Regulator


Scheduling Frame Transmissions

Whenever the MAC layer is ready to accept a new packet for transmission, it calls HWTXEVENT. TBR decides which backlogged packet to release as follows. TBR chooses one output queue among all the output queues with positive available channel time (tokens) and dequeues a packet for transmission.

The manner in which the output queue is chosen has no impact on the overall correctness since only the queues with positive tokens are considered. Nonetheless, the order could impact the short-term fairness. For simplicity and to alleviate short-term unfairness, TBR chooses the output queue among those with positive tokens in a round-robin manner. We note that short-term unfairness can further be reduced by choosing the queue which has the packet with the shortest potential final completion time as in traditional fair queuing schemes [8,24].

Once the output queue is chosen, TBR can decide which frame in the queue gets transmitted. For TCP, in-order packet delivery is desirable and thus first-in-first-out discipline is preferable. However, if there are time-sensitive packets (used by real-time protocols), they should have priority over TCP packets with earlier arrival times. The correctness of TBR does not depend on how a packet to dequeue is chosen. We also note that TBR works with any buffering scheme (e.g. RED, drop-tail), whose goal is to decides which packets to drop when the queue is getting full. Note that we distinguish buffering schemes from packet scheduling schemes. The former is responsible for deciding which packets to drop whereas the latter decides which packet gets transmitted [8].

TBR also dictates the scheduling of packet transmissions at the clients. Specifically, whenever $tokens_i \leq 0$, TBR needs to explicitly inform node i to delay transmission for a short amount of time. This can be accomplished in two major ways. First, the TBR agent at the AP informs the client by either sending an explicit notification packet or piggyback such information in a downlink packet when possible. Second, the client monitors the total channel occupancy time of packets transmitted and received and transmits only if there is available channel time allocated for the node. To do so, the client only needs to know ratei. However, as we explain in Section 4.3, TBR at the AP may update ratei depending on the overall traffic conditions and when that happens, TBR needs to inform the client. In both cases, a client agent is necessary at each client to communicate with TBR at the AP. We choose the first method for simplicity.

The actual amount of communication overhead depends on the MAC protocol used. TBR requires a single bit in the MAC header of a data frame transmission to inform the client to delay its transmission for a pre-determined amount of time. In cases where there is only uplink traffic, TBR can still use the same procedure if the underlying MAC protocol (e.g. DCF) employs a stop-and-go retransmission strategy. A stop-and-go protocol requires the node receiving a data frame to reply with a synchronous acknowledgment, which can carry the TBR notification bit. Furthermore, if the underlying MAC protocol employs a polling mechanism (such as 802.11's PCF), no explicit communication is necessary since TBR can dictate which node gets polled.

Cooperation from each client is only necessary if the client has uplink UDP flows that represent a significant fraction of its traffic. Studies of WLAN traffic at university campuses [18,25] and at a multi-day conference [1] show that TCP accounted for more than $90\%$ of bytes exchanged over the WLANs. TCP data packets are paced by TCP ack packets (``ack clocking'' [13]) sent out by the receiver. In a typical scenario, all TCP data and ack packets go through the same AP. Therefore, delaying TCP data (ack) packets at the AP has the effect of slowing down the sending rates of downlink (uplink) TCP flows.

We note that our current TBR implementation does not contain the client-side implementation of TBR. As we demonstrate in Section 5, TBR without the client cooperation can effectively provide long-term channel time guarantees for TCP flows in both directions as well as downlink UDP flows.


next up previous
Next: Computing Channel Occupancy Time Up: Time-based Regulator Previous: Time-based Regulator
Godfrey Tan 2004-05-04