Detecting greedy receivers. 

Context in source publication

Context 1

... and normal receiver have BER= 2 e . TCP sender at remote site: So far we consider the connections span only wireless links. Next we consider the case where the two connections span both wireless and wireline links, as shown in Fig. 11(a). We vary the wired link latency from 2 ms to 400 ms , and set BER of both wireless links to 2 e − 5 . Fig. 11 compares goodput under no greedy receiver versus under one greedy receiver ( R 2 is a greedy receiver in this case). We observe that increasing wireline latency initially increases the gap between the normal and greedy receiver. This is because an increasing wireline latency makes end- to-end loss recovery more expensive. When the wireline latency is beyond 200 ms , the goodput of greedy receiver starts to decrease, even though it still significantly out-performs the normal receiver. This is because TCP ACK-clocking reduces its goodput as delay increases, and the goodput gain from the normal receiver is not enough to offset such drop. For misbehavior 3, a greedy receiver sends an ACK even upon receiving a corrupted data frame. This misbehavior is effective when the greedy receiver uses UDP, and the source and the destination address in the corrupted DATA frame are preserved. As shown in Table 1, this is quite common. We create data loss using one of the following two ways. We disable RTS- CTS exchange and place two receivers next to each other and senders far apart from each other to create the hidden terminal problem. Alternatively, we create loss by injecting random loss of bit-error-rate (BER) of 2 e − 5 when the two sender-receiver pairs are within communication range of each other. In both cases, the two flows experience similar loss rates. Vary greedy percentage: As shown in Fig. 12, an increasing greedy percentage increases the discrepancy Next we evaluate the performance impact of greedy receivers in a testbed consisting of 4 DELL Dimensions 1100 PCs (2.66 GHz Intel Celeron D Processor 330 with 512 MB of memory). They form two senders and two receivers. The locations of the nodes are fixed, on the same floor of an office building. Each node runs Fedora Core 4 Linux, and is equipped with 802.11 a/b/g Net- Gear WAG511 using MadWiFi. In our experiment, we enable RTS/CTS, and use a fixed 6 Mbps as MAC-layer data rate. 802.11a is used in our testbed experiments to avoid interference with campus 802.11b wireless LAN in the building. Our testbed evaluation focuses on misbehavior 1, since MadWiFi currently does not allow us to implement the other two misbehaviors. Given the trend of moving more functionalities to software, this is not an inherent constraint. We implement misbehavior 1 as follows. Because the current MadWiFi does not allow us to directly modify NAV in CTS frames, we get around this problem by implementing RTS inflation on one of the senders. We increase RTS NAV to 32700 μs . This automatically triggers inflated NAV in CTS frames. (The inflated CTS NAV is 32655 μs .) Since we want to study the impact of a greedy receiver, we have the sender transmit at lowest power so that its RTS with inflated NAV is not overheard by the other sender and receiver. Only the CTS frames from the greedy receiver is heard by all the other nodes to effectively create greedy receiver misbehavior. Table 3 compares the goodput under 0, 1, or 2 greedy receivers. The reported goodput is median over 5 runs, where each run lasts 2 minutes. As it shows, without greedy receiver, both receivers get similar goodput. When only one receiver is greedy, the greedy receiver gets virtually all the bandwidth and starves the normal receiver. When both receivers are greedy, the one transmitting earlier dominates the medium and starves the other receiver. These results are consistent with simulation results, and confirm the serious damage of greedy misbehavior in real networks. In this section, we present techniques to detect and mitigate greedy receiver misbehaviors. We assume that senders are well-behaving and do not collude with greedy receivers. Fig. 14 shows a flow-chart of our countermeasure scheme. The scheme can be imple- mented at any node in the network, including APs and clients. The more nodes implementing the detection scheme, the higher likelihood of detection. Next we describe how to detect inflated NAV, spoofed ACKs, and fake ACKs. Inflated NAV affects two sets of nodes: (i) those within communication range of the sender and receiver, and (ii) those outside the communication range of the sender but within communication range of the receiver. The first set of nodes know the correct NAV, since they overhear the sender’s frame and can directly compute the correct NAV from the receiver by subtracting the duration of sender’s frame. Therefore these nodes can directly detect and correct inflated NAV. The second set of nodes can infer an upperbound on a receiver’s NAV using the maximum data frame size ( e.g. , 1500 bytes, Ethernet MTU). If the NAV in CTS or ACK exceeds the expected NAV value, greedy receiver is detected. (In fact, without fragmentation, NAV in ACK should always be 0.) We can further locate the greedy receiver using received signal strength measurement from it. To recover from this misbehavior, nodes will ignore the inflated NAV and replace it with the expected NAV to use for virtual carrier sense. To detect greedy receivers that spoof ACKs on behalf of normal receivers, we use their received signal strength. More specifically, let RSS N denote the received signal strength from the original receiver, RSS C denote the received signal strength in the current ACK frame, and T hresh cap denote the capture threshold. RSS N can be obtained using a TCP ACK from that receiver, assuming TCP ACK is not spoofed If RSS is significantly different from RSS N , the sender reports greedy misbehavior. Furthermore, when RSS N ≥ RSS C T hresh cap , the sender can directly recover from this misbehavior by ignoring the received ACK. This is because in this case the original receiver must have not received data and sent ACK, otherwise the ACK coming from the original receiver would have captured the spoofed ACK; ignoring such MAC-layer ACKs allow the sender to retransmit the data at the MAC-layer as it should. To examine the feasibility of using RSS measurements for detecting spoofed ACKs, we collect RSSI measurements from our testbed, consisting of 16 nodes spread over one floor of an office building. Our measurements show that around 95% RSSI measurements differ from median RSSI of that link by no more than 1 dB. This suggests that RSSI does not change much during a short time interval, and we can use large change in RSSI to identify spoofed ACKs. Based on the above observation, a sender determines a spoofed ACK if | RSSI median − RSSI curr | > RSSIT hresh , where RSSI median is the median RSSI from the true receiver, RSSI curr is the RSSI of the current frame, and RSSIT hresh is the threshold. The accuracy of detection depends on the value of RSSIT hresh . Fig. 15 plots the false positive and false negative rates as RSSIT hresh varies from 0 to 5 dB , where false positive is how often the sender determines it is a spoofed ACK but in fact it is not, and false negative is how often the sender determines it is not a spoofed ACK but in fact it is. As it shows, using 1 dB as the threshold achieves both low false positive and low false negative rates. The previous detection is effective when RSSI from N R is relatively stable and RSSI from GR is different from N R . To handle highly mobile clients, which experience large variation in RSSI, the sender can use a cross-layer approach to detect the greedy behavior. For each TCP flow, it maintains a list of recently received MAC-layer ACK and TCP ACK. Greedy receiver is detected when TCP often retransmits the packet for which MAC-layer ACK has been received. This detection assumes wireline loss rate is much smaller than wireless loss rate, which is generally the case. To detect greedy receivers that send MAC-layer ACKs even for corrupted frame, the sender compares the MAC-layer loss with the application layer loss rate. The latter can be estimated using active probing (e.g., ping). Since packets are corrupted, GR cannot send ping response and we can measure the true application loss rate. If loss rate is mainly from wireless link, applicationLoss ≈ M ACLoss maxRetries , when packet losses are independent. If applicationLoss > M ACLoss maxRetries + threshold , the sender detects faked ACKs, where threshold is used to tolerate loss rate on wireline links when the connection spans both wireless and wireline. The appropriate value of threshold depends on the loss rate on the wireline links. We implement in NS-2 the greedy receiver countermeasure (GRC) against inflated NAV and ACK spoofing described in Section ...