802.11: performance

33
802.11: Performance Reference: “Does the IEEE 802.11 MAC protocol work well in multihop wireless ad hoc networks ”; Xu, S.; Saadawi, T. IEEE Communications Magazine, Volume: 39 Issue: 6, June 2001; Page(s): 130 –137 (8 02.11PE-1.pdf)

Upload: kaida

Post on 11-Feb-2016

46 views

Category:

Documents


0 download

DESCRIPTION

802.11: Performance. Reference: “Does the IEEE 802.11 MAC protocol work well in multihop wireless ad hoc networks”; Xu, S.; Saadawi, T. IEEE Communications Magazine, Volume: 39 Issue: 6, June 2001; Page(s): 130 –137 (802.11PE-1.pdf). IEEE 802.11 MAC Protocol. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 802.11: Performance

802.11: Performance

Reference: “Does the IEEE 802.11 MAC protocol work well in multihop wireless ad hoc networks”; Xu, S.; Saadawi, T. IEEE Communications Magazine, Volume: 39 Issue: 6, June 2001; Page(s): 130 –137 (802.11PE-1.pdf)

Page 2: 802.11: Performance

2

IEEE 802.11 MAC Protocol• DCF :Distribution Coordination Function

– Basically a CSMA/CA mechanism– 1. A station wanting to transmit senses the medium.

If the medium is busy, it defers. If the medium is free for a specified time called DIFS (distributed interframe space), the station is allowed to transmit.

– 2. The receiving station checks the CRC of the received frame and sends an ACK packet (denoted by M-ACK in the paper)

– 3. If the sender does not receive the M-ACK, it retransmit the frame until it receives an M-ACK or throws it away after a given number of retransmissions (standard: a maximum of 7 retransmissions are allowed before the frame is dropped)

Page 3: 802.11: Performance

3

Hidden Node Problem• Two stations colliding due to not hearing each

other• Reduce colliding probability from hidden nodes

– 1. A station wanting to transmit a packet first transmits a short control packet called request to send (RTS), which includes the Src, Dst, and Dur of the intended packet and ACK transaction

– 2. The Dst station responds (if the medium is free) with a response control packet called clear to send (CTS), which includes the same Dur information

– 3. All other stations receiving either the RTS and/or the CTS set their virtual CS (carrier sense) indicator, called a network allocation vector (NAV), for the given Dur and use this information together with the physical CS when sensing the medium

Page 4: 802.11: Performance

4

Exposed Node Problem• Hidden node (H)

– One that is within the interfering range of the intended destination (R) but out of the sensing range of the sender (S)

• Exposed node (E)– One that is within the sensing range of the

sender but out of the interfering range of the destination

H

R

S

< interferingrange

> sensing rangeE

S

R

> interfering range

< sensingrange

Page 5: 802.11: Performance

5

Simulation Environment• Using NS2 network simulator• Wireless link bandwidth: 2 Mbps• Transmission radius: 250m• Distance btw two neighboring nodes: 200m• Nodes are static• Using TCP traffic

– Carry large file transfers (infinite backlog: the TCP sender always has data to send out)

Page 6: 802.11: Performance

6

Simulation Environment (cont)• In each node

– has a queue (called IFQ) for packets awaiting transmission by the network interface that holds up to 50 packets

– IFQ is managed in a drop tail fashion

• DSR routing protocol was used

Page 7: 802.11: Performance

7

Why TCP?• TCP is the prevalent reliable transport

protocol used in the internet today• TCP can adapt to the network condition and

do congestion control– It can use almost all the available bandwidth

without causing congestion

• Introduction to TCP Reno– Window-based ACK-clocked flow control protocol– Additive-increase/multiplicative decrease strategy

for changing windows according to net. conditions– Slow start (SS), Congestion avoidance (CA)– Fast retransmit, Fast recovery

Page 8: 802.11: Performance

8

TCP Instability Problem• E.g. Single TCP connection (Node 1 Node 5)

Figure 2

Page 9: 802.11: Performance

9

TCP Instability Problem (cont)

Figure 2

Page 10: 802.11: Performance

10

TCP Instability Problem (cont)

Figure 2

Page 11: 802.11: Performance

11

TCP Instability Problem (cont)• In Figure 2-(a),

– In the 120s lifetime of this connection, there are 20 times when the throughput reached or neared zero

– In those 1.0s intervals, almost no TCP packets were successively received, which means that TCP performance degraded seriously

– Every time after this, TCP restarted using slow start

– Since only one connection exists in the experiment, this kind of pause is not expected

• The problem can be lessened or eliminated with a smaller maximum window size, Figures 2-(b), 2-(c)

Page 12: 802.11: Performance

12

TCP Instability Problem (cont)• Reason

– Due to one node failing to reach its adjacent node. This triggers a route failure

– If this is an intermediated node, this node drops all queued packets (ACK in most cases) to that adjacent node and reports a route failure to the source (Here source means data packet source: either the TCP sender or receiver)

– After the source receives this message, it starts route discovery. Before a route is found, no data packet can be sent out

– Usually, this causes a timeout in the TCP sender. Then the TCP session has to wait before a route becomes available again

Page 13: 802.11: Performance

13

TCP Instability Problem (cont)

(collision)

1460B / 2Mbps = 0.00584 sec

TCP data TCP data TCP Ack TCP data TCP Ack

Packets too short to be collided ?

collisions

Link breakage

1 2 73 4 5 6

I think some events are skipped in tx of TCP-Ack

Page 14: 802.11: Performance

14

TCP Instability Problem (cont)• Around 20s

– Node 1 cannot reach node 2– After node 1 tries to contact node 2 and fails seven

times, the MAC layer reports a link breakage• In Figure 3

– Data means TCP packet or TCP ACK packet– The collision and the exposed station problem in node 2

prevent node 1 from reaching node 2– Since node 2 can sense node 4, it has to defer when

node 4 is sending– The result is that node 2 cannot send back CTS even if it

receives that RTS from node 1 correctly– After failing to receive CTS from node 2 seven times,

node 1 quits and reports a link breakage to its upper layer. Then a route failure event occurs

Page 15: 802.11: Performance

15

TCP Instability Problem (cont)• Note that, in a CS wireless network

– The interfering range (and sensing range) is typically larger than the range at which receivers are willing to accept a packet from the same transmitter

– WaveLAN wireless systems are engineered in this way

– This is the reason a collision occurs at node 2 when nodes 1 and 4 are sending at the same time, even though node 4 cannot directly communicate with node 2. Node 2 is within the interfering range of node 4

Page 16: 802.11: Performance

16

TCP Instability Problem (cont)• Summary

– 1. The exposed node problem and collisions prevent the intermediated node from reaching its next hop

– 2. The random backoff scheme used in the MAC layer makes this worse

– 3. For window_ = 4 (Figure 2-c), the maximum number for possible back-to-back sending is four. This greatly reduces the chance that other nodes might fail to access the channel in seven tries. Thus, no route failure occurs

Page 17: 802.11: Performance

17

Serious Unfairness Problem (cont)• Unfairness problem

– Results show that with the IEEE 802.11 MAC layer, simultaneous TCP traffic may suffer from severe unfairness, even between connections with the same number of hopsNot the same as the former reported TCP unfairness

problem, which is caused by the difference of TCP round-trip time

– In the experiment, one TCP connection might be completely shut down even if it starts much earlier than the competing TCP traffic

Page 18: 802.11: Performance

18

Serious Unfairness Problem (cont)

• Neighboring node one-hop unfairness– Two TCP connections– The first starts at 10.0s, and the second 20.0s

later (i.e. at 30.0s)– The first session: node 6 node 4 (2 hops)– The second session: node 2 node 3 (1 hop)– The whole experiment stops at 130.0s– Figure 4, Figure 5

Page 19: 802.11: Performance

19

Serious Unfairness Problem (cont)

Page 20: 802.11: Performance

20

Serious Unfairness Problem (cont)• Figure 4

– The first session has a throughput of around 450Kbps after starting from 10.0s

– However, it is completely forced down after the second session starts at 30.0s

– In most of its lifetime after 30.0s, the throughput of the first session is zero

– There is not even a chance for it to restart– The aggregate throughput of these two TCP

connections completely belongs to the second session- around 920Kbps in the lifetime from 30.0s to 130.0s

Page 21: 802.11: Performance

21

Serious Unfairness Problem (cont)

Page 22: 802.11: Performance

22

Serious Unfairness Problem (cont)

• Figure 5 (W1 run)– Unlike the TCP instability problem, the

unfairness problem cannot be eliminated by adjusting the maximum window size (window_) of TCP

– Check some of the TCP packet events in the W1 run (Figure 6)

Page 23: 802.11: Performance

23

Serious Unfairness Problem (cont)

Page 24: 802.11: Performance

24

Serious Unfairness Problem (cont)

Page 25: 802.11: Performance

25

Serious Unfairness Problem (cont)• Figure 7

– After 30.07s, no TCP packet of the first session is delivered successively from source node 6 to the receiver

– The packet with sequence number 2164 never arrives at the destination (node 4), although it is retransmitted 10 times

– Note that in NS2, the TCP packet size is fixed in one connection, and the sequence number here is counted in packets instead of bytes

– Table 1: condensed version of the simulation packets traces

Page 26: 802.11: Performance

26

Serious Unfairness Problem (cont)

No route available(route failure)

TCP packet expiredduring DSR route re-discovery

Simulation finished

Page 27: 802.11: Performance

27

Serious Unfairness Problem (cont)• Table 1

– The reason for the first TCP packet drop is the route failure in node 5 (Since no node moves in the simulation, the route failure seems very strange)

– Before a route to node 4 is found again, the TCP source retransmits the TCP packet after timeout. They are queued in the IFQ of node 6, waiting for forwarding. This is why we see several TCP packets expired and dropped

– Unfortunately, the TCP packet never reaches node 4 after 30.07s, even after a route to node 4 becomes available. This is because a route failure happens again very soon

Page 28: 802.11: Performance

28

Serious Unfairness Problem (cont)• The cause of route failure

– The problem is rooted in the MAC layer– Node 5 cannot reach node 4– After node 5 tries to contact node 4 and fails seven

times, the MAC layer reports a link breakage– See Figure 8, it is clear that the major cause of

node 5 failing to reach 4 is collision– Since node 5 can sense node 3, it has to defer

when node 3 is sending, so it can only send out a RTS when node 3 is not sending. The result is that node 5 cannot send back CTS even if it receives the RTS correctly (But, this is not the main reason of the link breakage)

Page 29: 802.11: Performance

29

Serious Unfairness Problem (cont)

TCP data TCP Ack TCP data TCP Ack TCP data TCP Ack

Collide with TCP data

Collide with RTS

Page 30: 802.11: Performance

30

Serious Unfairness Problem (cont)• Figure 8

– Five MAC packets dropped at node 4– Four of them are caused by collisions with the

TCP data packet from node 2– One is caused by collision with the RTS control

packet from node 2– The only chance for node 5 to access the channel

to node 4 is by sending out an RTS before node 2 sends out an RTS. Note that this must be after node 3 finishes sending back the data packet (TCP_ACK). The time window opening for node 5 to access the channel is very small

Page 31: 802.11: Performance

31

Serious Unfairness Problem (cont)– Also, because the binary exponential backoff s

cheme in the MAC layer always favors the last succeeding station (node 2 in this case), node 5 hardly wins the contention

– After seven failures, it will quit and report a link breakage to its upper layer. Then a route failure event occurs

– Main reason: Node 4 is within the interfering range of node 2

MAC layer does not function well in multi-hop wireless links

Page 32: 802.11: Performance

32

Discussion & Related Works• TCP traffic shows the problems existing in

the MAC layer very clearly• Current 802.11 MAC protocol has the

following problems:– 1. The hidden node problem still exists in multi-hop

networks The sufficient condition for not having hidden nodes is:

any station that can possibly interfere with the reception of a packet from node A to B is within the sensing range of A. This condition cannot be true in a multi-hop network

– 2. No scheme in the standard to deal with the exposed node problem, which will be more harmful in a multi-hop network

Page 33: 802.11: Performance

33

Discussion & Related Works (cont)

– 3. For carrier sensing, the sensing range (and interfering range) is typically larger than the communication rangeThe larger interfering range makes the hidden node p

roblem worseThe larger sensing range intensifies the exposed nod

e problem

– 4. The binary exponential backoff scheme always favors the latest successful nodeThis will cause unfairness, even when this protocol i

s not used in multi-hop network