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
, 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 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.