Motivation and Problem Elaboration

The main idea of the proposed BBi-MAC is to better support traffic flows with bi-directional packets transmission, particularly the TCP flows and bi-bi-directional UDP flows such as conversational VoIP calls. To this end, we define two-way or bi-directional traffic as the traffic pattern resulting from: 1) one or more TCP connections transferring data between a CRU pair, 2) two or more UDP connections transferring data in opposite directions between a CRU pair, and 3) a combination of at least a TCP flow and at least an UDP flow between a CRU pair.

It is commonly known that for TCP flows, a congestion control mechanism is employed.

The essence of this congestion control mechanism is the observation that data packets arrive at the receiving host at the rate that the bottleneck link will support. If the receiver’s TCP ACKs arrive at the sender with the same spacing, then the sender can send new data packets at the same rate to avoid overrunning the bottleneck link. It is said that such ACK policy makes the protocol self-clocking because the sender can dynamically adapts its transmission speed to both the speed of the network and the speed of the peer sending TCP ACKs.

Since a TCP’s self-clocking depends on the arrival of TCP ACKs at the same spacing with which the receiver generated them, if these TCP ACKs spend any time sitting in queues during their transit through the network, their spacing may be altered. When ACKs arrive closer together than they were sent, the sender might be misled into send-ing more data than the network can accept, which could led to congestion and loss of efficiency. This is called the ack-compression effect. It has been proven both statistically and experimentally that the ack-compression effect could result in unfairness and reduced overall throughput compared to what could be expected without this effect.

In addition, the throughput of a TCP flow could also be affected by its round-trip time (RTT). The RTT is the time between when a TCP data is being put on the wire and when its corresponding ACK is received. In TCP connections, every TCP receivers keeps a Receive Window (RWIN), which refers to the amount of data that the TCP receiver can accept without acknowledging the TCP sender. On the other hand, a TCP sender can transmit data up to the window size before waiting for the TCP ACKs. The TCP throughput T limitation caused by the TCP window size can then be calculated as follows:

T ≤ RW IN

RT T . (3.1)

In most of the system, the RWIN has a default size of 64KBytes. Therefore, it is obvious that when the RWIN is fixed, the variation of RTT can affect the TCP throughput.

A smaller RTT can increase the maximum achievable throughput while a large RTT can decrease the TCP throughput.

From detailed observation, we have identified the occurrence of ack-compression effect in the Uni-MAC in transmitting TCP flows. Also, it is found that the RTT time of a TCP packet becomes longer due to the protocol design. These observations are further elaborated as follow.

Consider a CRN with only a single pair of CRUs, transmitting a TCP flow from CRU A to CRU B, and the Txop being set to two. As explained earlier, TCP’s self-clocking depends on the arrival of TCP ACKs at the same spacing with which the receiver generated them. This desire same spacing of TCP ACKs, however, is broken in the Uni-MAC as proposed by [10].

With the Uni-MAC, when the TCP data are transmitted, the TCP ACKs could not be replied immediately due to only one-way bandwidth reservation by the protocol. Instead, the TCP sender first sends Txop TCP data packets consecutively. After that, both CRU A and CRU B return to the control channel. At this time point, since both the CRUs have packets in queue to be transmitted (TCP data for CRU A and TCP ACK for CRU B), both of them have to compete for the next chance of bandwidth negotiation, i.e., transmitting an REQ^CR.

In the Uni-MAC, to ensure that the control channel is accessed fairly by the CRUs, every CRU has to defer for a random waiting duration (RWD), which is a factor of SIFS,

before it is allowed to transmit an REQ^CR. Such a design gives every CRUs an equal chance to be a CRU sender. In the best case, the CRU B (denoted as TCP receiver hereafter) may defer for a shorter RWD as compared to CRU A (denoted as TCP sender hereafter).

Therefore, it will get a chance to transmit an REQ^CR before the TCP sender and switch its role to be a CR sender. After a successful REQ^CR/GRANT^CRhandshake at the control channel and obtaining the channel access at the pre-negotiated data channel, the TCP receiver can transmit its accumulated TCP ACKs after some standard procedures.

The resulting TCP transmission sequence of the best case as elaborated above is shown in Fig. 3.1. However, one can see that such data transmission sequence is not favorable because it breaks the TCP self-clocking nature due to the ack compression effect. When this happens due to the deficiency of the protocol design, the TCP sender has to tune the interval it sends TCP data and thus degrades the TCP transmission rate.

In an unpreferable situation, the TCP sender may get a shorter RWD continuously as compared to the TCP receiver as shown in Fig. 3.2. Worst of all, this might happen repeatedly until the TCP sender has used up its TCP window size and thus can only transmit the next TCP data after it receives a TCP ACK. Therefore, the TCP sender will no longer compete for the next chance of bandwidth negotiation and provides the TCP receiver a full opportunity to transmit an REQ^CR control packet after a RWD. As a consequence, the TCP receiver could transmit the accumulated TCP ACKs only some time later and this results in a more severe TCP ACKs compression and degrades the TCP throughput drastically.

The TCP performance degradation problem will be further deteriorated if the con-sidered network consists of some other CRUs and PUs which are also competing for the bandwidth. In this situation, the TCP ACKs compression problem will get even more severe because (i) The TCP sender has to compete with others CRUs for the bandwidth negotiation on the control channel. Therefore, its chances of immediately transmitting an REQ^CR becomes slimmer; and (ii) Even if the TCP sender has completed the hand-shaking procedure with the TCP receiver and both have switched to the data channel, it might not be able to get an immediate chance of packet transmission if PU’s activities are sensed on that channel. Combination of these two factors can further prolongs the time between a TCP data is sent and the corresponding TCP ACK is received, i.e., the RTT.

Figure 3.1: Illustration of the best case of the TCP packets exchanges when Txop = 2

Figure 3.2: Illustration of a bad case of the TCP packets exchanges when Txop = 2