Practical Partial Packet Recovery for 802.11: Maranello · Broadcom 802.11 network interface card)...

Practical Partial Packet Recovery for 802.11: Maranello

Brad Karp(with slides contributed by Kyle Jamieson)

UCL Computer Science

CS M038 / GZ063rd February 2016

Context: Coping with Wireless Bit Errors• Wired links are usually all-or-nothing– Either the packet arrives correctly or the link is

“cut”

• Wireless links often deliver packets with errors– Bit error rate dependent on interference from other

links, fading (recall Roofnet experiments)– Packets may have only a few, localized bit-errors– Or packets may have mostly errored bits, but a

small piece of salvageable content

2

Idea: Partial Packet Recovery• When a frame is received with bit errors:– Sender retransmits just the bits that need

correcting– Receiver combines original transmission with

retransmissions to form a correct packet

• Increases throughput because:1. The retransmission is smaller than the original2. Shorter transmissions have higher delivery

probability than longer transmissions3. Consequently, senders select higher bit rates

3

Approach #1: Block Checksum• Divide each packet into blocks

– Each block has a one-byte sequence number– Each block has an eight-bit CRC checksum

• Receiver requests retransmit of just blocks that fail checksum by replying with a negative acknowledgement (NACK) frame– NACK frame specifies incorrect block sequence numbers

• Pay block checksum overhead in the common case (no errors)

• Examples: Seda, FRJ

4

Maranello Practical Partial Packet Recovery for 802.11

Block-based partial packet recovery

2

corruptpacket ✓ ✖✓ ✖✓

Blockchecksums

Approach #2:Forward Error Correction

• Don’t attempt to identify correct/incorrect bits– Instead send parity bits that contain information

about every bit in the packet– Common parity coding scheme: Reed-Solomon

(R-S)

• Example: ZipTx [MobiCom ‘08]– Two-round forward error correction mechanism • In 1st round, transmitter sends a small number

of R-S parity bits for a corrupted packet• In 2nd round, transmitter sends more R-S parity

bits – If both rounds fail, the receiver requests a

retransmission of the whole packet 5

Approach #3:Physical-layer Hints

• Physical layer “scores” each bit with a numerical confidence in that bit’s correctness, passes score up to higher layers

• Receiver’s link layer asks for retransmissions of just the bits from low-confidence part of the frame

• Many different ways of combining retransmissions with original transmission– Example: SOFT [MobiCom ’07] combining information

from multiple access points that receive a frame

Physical layer Receivedframe:

ConfidenceLinklayer

6Correctbits Incorrectbits

Maranello• Block-based checksum design implemented on

commodity 802.11 hardware (Broadcom)

• Novel overhead-free link-layer design for the case of no wireless bit errors (common case)

• Maranello protocol implemented in firmware(software running on a small microprocessor on the Broadcom 802.11 network interface card)

7

Maranello: Protocol

• Receiver computes link-layer frame checksum, compares to the 802.11 frame checksum field, begins recovery if they don’t match:

1. Receiver breaks errored frame into fixed-size blocks– Sender and receiver agree on the block size

beforehand

8Maranello Practical Partial Packet Recovery for 802.11


2

corruptpacket



2

corruptpacket

Incorrectbits

Maranello: Protocol (2)

2. Receiver computes Fletcher-32 block checksums for each block and includes all block checksums in a NACK reply– If the NACK is lost, transmitter resends entire packet

3. Sender computes block checksums over each block– Compares computed block checksums to received

block checksums to determine errored blocks

9



2

corruptpacket ✓ ✖✓ ✖✓

Blockchecksums


4. Sender transmits repair blocks corresponding to just the blocks received that contain errors (repair packet)– Sender doubles contention window before repair

transmission (recall bounded exponential backoff)– If repair packet contains errors, receiver transmits

nothing• Sender then retransmits the original frame

10



2

corruptpacket

repair blocks

✓ ✖✓ ✖✓


5. Receiver repairs original transmission with repair blocks– Re-computes and verifies a CRC-32 frame

checksum (computed over entire frame) to check that the recovered packet is indeed correct



2

repairedpacket

Interoperation with Legacy 802.11• 802.11 sender with Maranello receiver– Does not recognize Maranello NACK from receiver– So sender retransmits as normal after the (short)

“ack timeout” period

• Maranello sender with 802.11 receiver– Just sends 802.11 ACK if correct, nothing if

incorrect– Maranello sender will retransmit entire frame to the

802.11 receiver after ACK timeout

12

Errored Bit Location by Packet

• Orange dot indicates a bit error – In frame corresponding to vertical axis position– At location in that frame corresponding to horizontal axis position

13


100

corru

pted

pac

kets

bits

802.11 errors are clustered

4

WiFi Errors Cluster Together

• Some packets have few bit errors (hypothesis: noise burst?)– Errors are mostly restricted to certain 64-byte blocks– Can be recovered by retransmitting those blocks

14

WiFi Errors Cluster Together

• Some packets have many bit errors (hypothesis: interference or loss of synchronization?)– Similarly, can be recovered by retransmitting errored

blocks 15

How many blocks are needed to repair?

• Horizontal axis: number of bit errors in packets• Vertical axis: Stacked bar graph (# 64-byte blocks required to repair)


1 2 3-7 8-14 15-32 33-368 369-3475 3476-5847fraction corrupt packets, labeled by bit errors

0

0.5

1

fract

ion

repa

ired

by b

lock

s 12345...1920212223

Need few blocks for repairs

5


0

0.5

1

fract

ion

repa

ired

by b

lock

s 12345...1920212223


0

0.5

1

fract

ion

repa

ired

by b

lock

s 12345...1920212223

One block fixes a one-bit error

• Among all packets with one bit error, one 64-byte block always repairs the packet

17

One block usually fixes two bit errors

• Among packets with two bit errors:– One 64-byte block repairs the packet 99.7% of the time– Two 64-byte blocks repair the packet 0.3% of the time

18

How many bit errors can one block fix?

• Fraction of packets repaired by one 64-byte block, by number of errored bits– Under 15 errored bits, ≈ 90% packets can be fixed with one block– Packet size 1,500 bytes, so one block is ≈ 4% of the packet’s size



0

0.5

1

fract

ion

repa

ired

by b

lock

s 12345...1920212223


5

≤32 bit errors,repaired by one block


0

0.5

1

fract

ion

repa

ired

by b

lock

s 12345...1920212223

How many blocks are needed to repair?

• There are 23 blocks per packet, so orange area represents packets that need a complete retransmission (very few)



0

0.5

1

fract

ion

repa

ired

by b

lock

s 12345...1920212223


5

≤32 bit errors,repaired by one block

many bit errors,still correct blocks

Summary: How many repair blocks?• So far, we have seen the following:– The overhead of one block is 4% of a packet– For 1−2 errored bits, one block fixes most packets– Under 15 errored bits, one block fixes ≈ 90% packets– Very few packets require a complete retransmission

• But is number of repair blocks required the right question?– We are looking for evidence that partial packet recovery

will in fact increase performance, i.e., throughput

– Do these data tell us anything about how often how many bit errors occur? (i.e., where on the x-axis are we most of the time?)

21

Repair Size• Measure how many repair bits (on average) a

particular protocol needs to fix one incorrect bit

• Trace-driven simulation– Use Broadcom cards to send and receive packets

with known payloads over the air– Record traces of the received frames and mark

each received bit as correct or incorrect– Software simulator runs the protocol to be

evaluated, in simulation, using trace data for received frames

22

Repair Size:Maranello Competitive at Low BER

• At low BER: Maranello requires only marginally more repair bits than Reed-Solomon ZipTx approach

• Parity bits fix a small number of errors efficiently (simulated “ideal” ZipTx that knows the number of errors needing repair) 23


1

5

9

13

17

21

25

29

.003 .007 .015 .102 .106

repa

ir bi

ts p

er in

corre

ct b

it

error traces by average bit error rate

Symbols (PPR)Ideal Reed Solomon (ZipTx)

Blocks (Maranello)

Deployable partial packet recovery

3

Symbols (PPR)

64 byte blocks (Maranello)

Ideal Reed Solomon (ZipTx)

333

67

��142

��Full retransmission67

��

Repair Size:Maranello Outperforms ZipTx at High BER

• At high BER: Maranello outperforms Reed-Solomon based approach

• Additional Reed-Solomon parity bits contain information about the entire packet, inefficient if errors are localized to a single block(s) 24


1

5

9

13

17

21

25

29

.003 .007 .015 .102 .106

repa

ir bi

ts p

er in

corre

ct b

it

error traces by average bit error rate

Symbols (PPR)Ideal Reed Solomon (ZipTx)

Blocks (Maranello)

Deployable partial packet recovery

3

Symbols (PPR)

64 byte blocks (Maranello)

Ideal Reed Solomon (ZipTx)

333

67

��142

��Full retransmission67

��

• Backoff and bit-rate selection impact Maranello’s performance– 802.11 standard specifies

backoff (but chipsets do not always respect the standard)

– Recall: Standard doesn’t specify bit rate selection

• Maranello helps Intel because it increases delivery rate at high bit-rates, avoiding backoff

• Maranello helps Atheros because it reduces the chance of falling back to 1 Mbit/s


Retransmission behavior varies

16

Windows Broadcom

Windows Intel

Windows Atheros

Linux ‘minstrel’ Broadcom

0 2 4 6 8

10 12

tx ti

me

(ms)

retransmission rate (Mbit/s)

0 2 4 6 8

10 12

back

off (

ms)

54 1

0 2 4 6 8

10 12

tx ti

me

(ms)


0 2 4 6 8

10 12

back

off (

ms)

54 48 36 24

0 2 4 6 8

10 12

tx ti

me

(ms)


0 2 4 6 8

10 12

back

off (

ms)

54 36

0 2 4 6 8

10 12

tx ti

me

(ms)


0 2 4 6 8

10 12

back

off (

ms)

54 48 36 1

Retransmission Behavior Varies Across Hardware

25

retransmissionsà

retransmissionsà

Implementation: Alternatives1. Implementation in the OS kernel driver software– Microbenchmark shows > 70 μs (≫ 10 μs SIFS time) delay

between receipt of packet and triggered response, so unsuitable• CPU interrupt latency and NIC-RAM bus transfer

delay

2. Software-defined radio platforms (e.g. GNU radio)– High-latency (ms) Ethernet or USB bus makes

unsuitable

3. Sora software defined radio [NSDI ‘08]– Software-defined radio on PCI express bus– Open question as to whether it would work for partial

packet recovery (ACKs cached in current version of Sora)

26

Implementation• OpenFWWF open firmware for Broadcom 802.11 NIC

– Publically-downloadable firmware assembly code that runs on Broadcom NIC microprocessor

• Broadcom 802.11 NIC system components:

1. Tx/Rx FIFO queues: buffers frames to/from the physical layer (transmission over the air)

2. Internal shared memory: State variables that can be read/written from the kernel driver

3. Template RAM: “Scratch” memory for composing an arbitrary frame and transmitting over the air

4. Internal registers and external conditions: Interface with the physical layer and timers (for, e.g., backoff)

27

Implementation: NACK Generation• Receiver computes block checksums in firmware

• Problem: For low transmission rates, Maranello NACK airtime is greater than 802.11 ACK– May cause problems if hidden terminals present. Why?

• Data contains network allocation vector (NAV) but with a duration shorter than Maranello needs for NACK

• Solution: No solution; just let the collisions happen. Claim that preliminary experiments show improved overall throughput

28

S RH

Implementation: NACK Generation

• Problem: 802.11 NIC microprocessor is not fast enough to compute block checksums during SIFS interval (10 μs) – Each block checksum takes up to 4 μs– But running 802.11, the microprocessor is normally

idle during a frame reception

• Solution: Modify firmware to copy partially-received packets into memory the microprocessor can access– Overlap one block’s block checksum computation with

reception of the next block

29


•Compute block checksums

•10μs

Exploiting 802.11’s timing

ack timeoutDIFS & backoffcorrupt packet retransmission

SIFS

reserved time for expected ack

11

• Identify mismatchedchecksums

•100μs

build nack build repair

Implementation:Repair Packet Construction

• Transmitter starts an ACK timer after sending a frame

• Sender always retransmits the first block of a packet, “which contains important headers of various layers”–Why is this necessary?

• Repair packets contain an extra 32-bit checksum in the last four bytes of link-layer data payload–Why is this necessary, given 802.11 has link-layer

checksum?

30

Implementation: Sender Side• Before the first transmission, sender pre-computes

block checksums in the OS kernel driver, on the main CPU– Then sends block checksums to the firmware with

the packet’s contents

–Why? Main CPU is more powerful, can spare the time, and block checksum computation on the sender is not time-critical (why?)

31

Performance Evaluation• 802.11 channels 1, 6, 11 (span the 2.4 GHz unlicensed

frequency band) in environments with background traffic– Advantage: Characterizes performance of Maranello in situ• Evaluate in three different environments (research

lab, home, university), so can claim some generality

– Disadvantage: Lose repeatability of the experiment, so more difficult for the experimenters to isolate experimental factors that impact performance

• Enable Minstrel bit rate adaptation– So compare Maranello and 802.11 at or close to the

best bit-rate for a particular link

• Evaluate throughput, latency gains, and then drill down for causes

32

Link Throughput Experiment• By how much does Maranello increase link

throughput?

• Methodology– Use the Iperf network measurement tool in UDP

mode to saturate a wireless link in the testbed– A one-minute run for 802.11, then immediately

afterwards, a one-minute run for Maranello• < 15 second gap implies wireless conditions

unlikely to have changed– Repeat the experiment ten times with sender and

receiver in the same locations– Change locations of sender and receiver, in the same

testbed

33

Maranello Increases Link Throughput• University building results

– Best results (high channel contention)

– Other environments qualitatively similar

– Each point in the scatter plot represents an Iperf run

• Slanted lines delineate constant-factor gains

• Results:– About one-third of the

time little to no gain

– About one-third of the time almost 2× gain

34

0

5

10

15

20

25

30

0 5 10 15 20 25 30

thro

ughp

ut o

f Mar

anel

lo

throughput of 802.11

1X1.3X1.6X2X0.5%40.3%

45.1%13.2%0.8%

(a) Research lab

0

5

10

15

20

25

30

0 5 10 15 20 25 30

thro

ughp

ut o

f Mar

anel

lo


1X1.3X1.6X2X3.6%65.6%

24.4%5.6%0.8%

(b) Home

0

5

10

15

20

25

30

0 5 10 15 20 25 30

thro

ughp

ut o

f Mar

anel

lo


1X1.3X1.6X2X4.1%36.2%

34.8%17.9%7.0%

(c) University building

0

5

10

15

20

25

30

0 5 10 15 20 25 30

thro

ughp

ut o

f 802

.11


1X51.4% 48.6%

(d) Baseline: 802.11 vs. 802.11

Figure 6: Maranello has a higher throughput than 802.11. Each figure compares 802.11 with Maranello in a differentenvironment, or to show the uncertainty of the comparison, with 802.11 itself. Each point represents the performanceof back-to-back one-minute UDP throughput measurements; ten points were collected for each configuration of senderand receiver stations.

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70 80 90 100 110

CD

F

link layer latency (ms)

Maranello802.11

Figure 7: With block-based repair, Maranello recoverspackets faster than 802.11’s retransmissions.

6.3 The Sources of Throughput Gain andLatency Reduction

To break down the sources of performance improvement,we enhance the transmission status report for each packetwith the following information: (1) whether a repair

packet was used, (2) if used, at which attempt, and (3)the number of retransmitted blocks in the repair packet.The original report also includes (1) whether the packetis successfully delivered, (2) the number of attempts, (3)the bit rate used for the packet. With this information,we can calculate the delivery probability at each attempt,the transmission airtime and the number of transmittedbytes for each attempt. We run Iperf for one minute for10 randomly selected links and plot in Figure 8 the prob-ability of successful attempt for two retransmission ratefallback schemes: Linux “minstrel” fallback which al-ways uses 1 Mbps as fallback rate, and 2-step fallbackwhich drops the bit rate selected by minstrel for the ini-tial transmissions by 2 steps (if possible) and uses it asfallback rate. The two-step fallback selection emulatesthe Broadcom driver for Windows XP (Section 4.1). Inthis figure, the x-axis is transmission attempt. The retrylimit of Broadcom cards is 7, 1 initial transmission, andat most 6 retransmissions. The y-axis is the probabilitythat an attempt can succeed.

Figure 8 shows that the probability of successful re-

11

Transmission Latency Experiment• Does Maranello decrease the time it takes to correctly deliver one packet across a link?

• Methodology– Measure time from the firmware fetching a packet from the head of the Tx FIFO queue, to receipt of an ACK– Includes retransmissions (in the case of 802.11), repair

transmissions (in the case of Maranello), backoff, etc.– Firmware’s microsecond timestamp counter measures this time precisely

– Alternative: Measure time from fetching a packet from the head of the Tx FIFO queue to packet’s correct reception• In most cases, this would be a fixed time interval less

than proposed measurement (time to deliver the ACK to sender)35

Maranello Decreases Transmission Latency

• Latency for packets that need one or more retransmissions• One pair of sender, receiver locations• 802.11 modes at 16 and 32 ms represent Minstrel 1 Mbit/s fallback• A log scale on the x-axis would show more detail at lower latencies

– Possibly showing the high-rate retransmissions

36

0

5

10

15

20

25

30

0 5 10 15 20 25 30

thro

ughp

ut o

f Mar

anel

lo


1X1.3X1.6X2X0.5%40.3%

45.1%13.2%0.8%

(a) Research lab

0

5

10

15

20

25

30

0 5 10 15 20 25 30

thro

ughp

ut o

f Mar

anel

lo


1X1.3X1.6X2X3.6%65.6%

24.4%5.6%0.8%

(b) Home

0

5

10

15

20

25

30

0 5 10 15 20 25 30

thro

ughp

ut o

f Mar

anel

lo


1X1.3X1.6X2X4.1%36.2%

34.8%17.9%7.0%

(c) University building

0

5

10

15

20

25

30

0 5 10 15 20 25 30

thro

ughp

ut o

f 802

.11


1X51.4% 48.6%

(d) Baseline: 802.11 vs. 802.11

Figure 6: Maranello has a higher throughput than 802.11. Each figure compares 802.11 with Maranello in a differentenvironment, or to show the uncertainty of the comparison, with 802.11 itself. Each point represents the performanceof back-to-back one-minute UDP throughput measurements; ten points were collected for each configuration of senderand receiver stations.

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70 80 90 100 110

CD

F

link layer latency (ms)

Maranello802.11

Figure 7: With block-based repair, Maranello recoverspackets faster than 802.11’s retransmissions.

6.3 The Sources of Throughput Gain andLatency Reduction

To break down the sources of performance improvement,we enhance the transmission status report for each packetwith the following information: (1) whether a repair

packet was used, (2) if used, at which attempt, and (3)the number of retransmitted blocks in the repair packet.The original report also includes (1) whether the packetis successfully delivered, (2) the number of attempts, (3)the bit rate used for the packet. With this information,we can calculate the delivery probability at each attempt,the transmission airtime and the number of transmittedbytes for each attempt. We run Iperf for one minute for10 randomly selected links and plot in Figure 8 the prob-ability of successful attempt for two retransmission ratefallback schemes: Linux “minstrel” fallback which al-ways uses 1 Mbps as fallback rate, and 2-step fallbackwhich drops the bit rate selected by minstrel for the ini-tial transmissions by 2 steps (if possible) and uses it asfallback rate. The two-step fallback selection emulatesthe Broadcom driver for Windows XP (Section 4.1). Inthis figure, the x-axis is transmission attempt. The retrylimit of Broadcom cards is 7, 1 initial transmission, andat most 6 retransmissions. The y-axis is the probabilitythat an attempt can succeed.

Figure 8 shows that the probability of successful re-

11


Retransmission behavior varies

16

Windows Broadcom

Windows Intel

Windows Atheros

Linux ‘minstrel’ Broadcom

0 2 4 6 8

10 12

tx ti

me

(ms)


0 2 4 6 8

10 12

back

off (

ms)

54 1

0 2 4 6 8

10 12

tx ti

me

(ms)


0 2 4 6 8

10 12

back

off (

ms)

54 48 36 24

0 2 4 6 8

10 12

tx ti

me

(ms)


0 2 4 6 8

10 12

back

off (

ms)

54 36

0 2 4 6 8

10 12

tx ti

me

(ms)


0 2 4 6 8

10 12

back

off (

ms)

54 48 36 1

Source of Maranello’s Improvements

• Attempts #2, #3: Both 802.11 and Maranello maintain bit rate– But, Maranello sends a shorter repair packet– Shorter packet has a lesser chance of being lost

• Minstrel fallback to 1 Mbit/s on attempt #4 increases delivery probability– Maranello still sending shorter repair packets

37

0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7

prob

abilit

y of

suc

cess

ful a

ttem

pt

transmission attempt

802.11Maranello

(a) Linux “minstrel” (1 Mbit/s) fallback

0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7

prob

abilit

y of

suc

cess

ful a

ttem

pt


802.11Maranello

(b) Windows Broadcom (2-step) fallback

Figure 8: Maranello can successfully retransmit a packet earlier than 802.11. Each line represents a link measuredeither with 802.11 or Maranello; the probability that Maranello’s recovery packets are delivered is typically higher.

0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7

fract

ion

of e

ffect

ive

time


802.11Maranello


0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7

fract

ion

of e

ffect

ive

time


802.11Maranello


Figure 9: Maranello can use airtime more effectively for packet transmissions. Each line represents a link measuredeither with 802.11 or Maranello; Maranello spends more time transmitting bits not yet correctly received.

transmission for Maranello is usually higher than that of802.11. Because the retransmission rate fallback doesnot budge for the first two retransmissions, the proba-bility of successful retransmission can be thought of asthe conditional probability that, given a packet (or two)recently failed to be delivered at the chosen rate, thisnext transmission at the same rate will be delivered. Notsurprisingly, for 802.11, this probability descends moresteeply than for Maranello. Maranello, in contrast, cansend shorter repair packets, which are less likely to becorrupted [8], even at the original bit rate.

The delivery probability increases at the fourth attemptbecause the firmware reduces the bit rate for the lastfour attempts. The successful attempt probabilities forthe first three attempts are more important, because mostpackets can succeed at the first two retransmissions. Theestimate of the delivery probability for the seventh at-tempt (after three previous attempts at 1 Mbit/s) is un-certain due to the dearth of data. For example, the 7th

attempt that had 0.0 delivery probability of Maranello,only one packet was transmitted seven times. For the7th attempt with 1.0 delivery probability of 802.11, therewere 5 packets transmitted 7 times and all succeeded atthis last attempt.

We also plot the fraction of effective time for eachtransmission attempt in Figure 9. Effective timerepresents the time spent transmitting correct blocks;Maranello can use airtime more effectively, because thecorrect bits in corrupted packets may be combined withrecovery packets to reconstruct the original packets andthe transmission time of these correct bits is effective.

6.4 Deployment on Access PointsTo show that Maranello can increase overall network per-formance and does not interact poorly with unmodified802.11 devices, we deploy Maranello on Linksys wire-less routers running OpenWRT [23]. We associate twodesktop stations, A and B, with the Maranello AP. We

12

• Measure deliveryprobability ofeachtransmission attempt– Higher delivery probabilityà

higher throughput, lower latency

• Note:thisgraphcountstransmissions(including firsttransmission)

• Attempt #1:Roughly equalbetween 802.11,Maranello (bothjustsend theoriginal packet)

Maranello Is More Efficient

• Fraction of effective time– Time spent transmitting correct blocks that have not yet been received

• Maranello doesn’t throw away correct bits as 802.11 does– Therefore Maranello increases effective time

38

0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7

prob

abilit

y of

suc

cess

ful a

ttem

pt


802.11Maranello


0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7

prob

abilit

y of

suc

cess

ful a

ttem

pt


802.11Maranello


Figure 8: Maranello can successfully retransmit a packet earlier than 802.11. Each line represents a link measuredeither with 802.11 or Maranello; the probability that Maranello’s recovery packets are delivered is typically higher.

0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7

fract

ion

of e

ffect

ive

time


802.11Maranello


0

0.2

0.4

0.6

0.8

1

1 2 3 4 5 6 7

fract

ion

of e

ffect

ive

time


802.11Maranello


Figure 9: Maranello can use airtime more effectively for packet transmissions. Each line represents a link measuredeither with 802.11 or Maranello; Maranello spends more time transmitting bits not yet correctly received.

transmission for Maranello is usually higher than that of802.11. Because the retransmission rate fallback doesnot budge for the first two retransmissions, the proba-bility of successful retransmission can be thought of asthe conditional probability that, given a packet (or two)recently failed to be delivered at the chosen rate, thisnext transmission at the same rate will be delivered. Notsurprisingly, for 802.11, this probability descends moresteeply than for Maranello. Maranello, in contrast, cansend shorter repair packets, which are less likely to becorrupted [8], even at the original bit rate.

The delivery probability increases at the fourth attemptbecause the firmware reduces the bit rate for the lastfour attempts. The successful attempt probabilities forthe first three attempts are more important, because mostpackets can succeed at the first two retransmissions. Theestimate of the delivery probability for the seventh at-tempt (after three previous attempts at 1 Mbit/s) is un-certain due to the dearth of data. For example, the 7th

attempt that had 0.0 delivery probability of Maranello,only one packet was transmitted seven times. For the7th attempt with 1.0 delivery probability of 802.11, therewere 5 packets transmitted 7 times and all succeeded atthis last attempt.

We also plot the fraction of effective time for eachtransmission attempt in Figure 9. Effective timerepresents the time spent transmitting correct blocks;Maranello can use airtime more effectively, because thecorrect bits in corrupted packets may be combined withrecovery packets to reconstruct the original packets andthe transmission time of these correct bits is effective.

6.4 Deployment on Access PointsTo show that Maranello can increase overall network per-formance and does not interact poorly with unmodified802.11 devices, we deploy Maranello on Linksys wire-less routers running OpenWRT [23]. We associate twodesktop stations, A and B, with the Maranello AP. We

12

Deployment on Access Points• So far, we’ve only seen Maranello in isolation on a

link – How well does Maranello perform in an AP network

with multiple clients?

• Methodology– Deploy Maranello on Linksys wireless routers– Associate two desktop clients (A, B) with a

Maranello AP– Send uplink (to the AP) UDP traffic from A and B using

Iperf– Downlink traffic is more common by volume, but

would not show how senders interact

39

AP Deployment:Maranello Increases Throughput

40

0

2

4

6

8both

802.11bothMar.

AMar.

BMar.

A M

bit/s

0

2

4

6

8

B M

bit/s

Figure 10: With two clients sending to an AP, on average,Maranello increases their individual and overall through-put. Error bars indicate min and max for five one minuteruns.

run four types of experiments: A and B both runningMaranello, both running 802.11, A running Maranelloand B running 802.11, and vice versa. We connect athird station, C, to the AP using Ethernet, to act as anIperf server. We do not run the Iperf server on the APdirectly due to its limited CPU power. During a singleone-minute experiment, A and B send UDP packets to Cas fast as they can. Although experimenting with down-link traffic might be more typical of access point use, inthat situation, that AP would be the only transmitter andwould not show how Maranello transmitters interact withunmodified 802.11 transmitters.

Figure 10 plots the throughput of these two stations us-ing a stacked bar graph. There are two key notes. First,running Maranello does not decrease the performance ofthe unmodified 802.11 station. That is, Maranello doesnot “cheat” the existing station of throughput. Second,when both stations run Maranello, the throughput is sig-nificantly increased for both stations. An interesting ob-servation is that it appears not to help A or B to indi-vidually run Maranello when in contention. (The resultsin Section 6.1 imply that each station gains individuallywhen running Maranello without a persistently compet-ing station.) We plan to investigate this surprising resultthat Maranello is more social than selfish when compet-ing with an unmodified station.

7 DiscussionIn this section, we discuss how Maranello can be com-plementary with frame aggregation, which is used in802.11n, and how the block size affects the performanceof Maranello.

7.1 Frame Aggregation and Maranello areComplementary

To increase throughput, 802.11n reduces the 802.11 pro-tocol overheads, such as interframe spacing, PHY layerheaders and acknowledgment frames, by aggregatingdata packets into jumbo frames. Aggregated packets thatare received incorrectly are indicated in a block acknowl-edgment which is sent back to the transmitter. The trans-mitter can then send a new chunk that contains only thecorrupt packets. Even though only part of a packet mayhave errors in it, 802.11n frame aggregation must retrans-mit whole packets: correctly received bits are wasted.

Frame combining can improve throughput, but it alsosignificantly increases latency, as senders must wait toaggregate enough frames to fill a jumbo frame. Blockacknowledgments provide a complementary aggregationof feedback for 802.11n, where ACKs may be bufferedtogether and sent as a group, similarly increasing per-packet latency. Maranello is complementary with theseframe aggregation techniques because by repairing cor-rupted aggregated packets, Maranello can further in-crease link throughput.

7.2 Optimal Block SizeThe Maranello block size is 64 bytes, primarily becauseit is the smallest multiple of 32 that can be supportedby hardware (Section 5.2.2). A larger block size wouldincrease computation efficiency somewhat and shortenNACKs, which may be useful at low bit rates. When theerror rate is low, however, larger blocks may lead to re-pair packets with unnecessary extra bytes, wasting chan-nel time.

We consider an interesting future direction of researchto be dynamically adjusting the block size. The idealblock size may vary based on an estimate of wirelesschannel conditions and the bit rate chosen by the trans-mitter, which determines the bit rate of the acknowledg-ment and thus the transmission time of the NACK. Whenthe NACK is transmitted at a low rate, it may be betterfor global throughput to keep NACK transmissions shortthan to be precise about the blocks in error. A similartradeoff exists in the FEC systems between the codingrate of error correction bits and recovery efficiency. An-other approach to determine the optimal block size thatwe intend to explore is to use theoretical models of wire-less communication errors [13, 29].

8 ConclusionIn this paper, we design, implement, and evaluateMaranello, a practical partial packet recovery protocolfor 802.11 wireless networks. Maranello has the follow-ing features simultaneously: (a) it introduces no extra

13

• Both stations running Maranello: significant throughput increase

AP Deployment:Maranello Increases Throughput

• Both stations running Maranello: significant throughput increase

• Running Maranello on one station increases throughput of other– No explanation given in paper

41

0

2

4

6

8both

802.11bothMar.

AMar.

BMar.

A M

bit/s

0

2

4

6

8

B M

bit/s

Figure 10: With two clients sending to an AP, on average,Maranello increases their individual and overall through-put. Error bars indicate min and max for five one minuteruns.

run four types of experiments: A and B both runningMaranello, both running 802.11, A running Maranelloand B running 802.11, and vice versa. We connect athird station, C, to the AP using Ethernet, to act as anIperf server. We do not run the Iperf server on the APdirectly due to its limited CPU power. During a singleone-minute experiment, A and B send UDP packets to Cas fast as they can. Although experimenting with down-link traffic might be more typical of access point use, inthat situation, that AP would be the only transmitter andwould not show how Maranello transmitters interact withunmodified 802.11 transmitters.

Figure 10 plots the throughput of these two stations us-ing a stacked bar graph. There are two key notes. First,running Maranello does not decrease the performance ofthe unmodified 802.11 station. That is, Maranello doesnot “cheat” the existing station of throughput. Second,when both stations run Maranello, the throughput is sig-nificantly increased for both stations. An interesting ob-servation is that it appears not to help A or B to indi-vidually run Maranello when in contention. (The resultsin Section 6.1 imply that each station gains individuallywhen running Maranello without a persistently compet-ing station.) We plan to investigate this surprising resultthat Maranello is more social than selfish when compet-ing with an unmodified station.

7 DiscussionIn this section, we discuss how Maranello can be com-plementary with frame aggregation, which is used in802.11n, and how the block size affects the performanceof Maranello.

7.1 Frame Aggregation and Maranello areComplementary

To increase throughput, 802.11n reduces the 802.11 pro-tocol overheads, such as interframe spacing, PHY layerheaders and acknowledgment frames, by aggregatingdata packets into jumbo frames. Aggregated packets thatare received incorrectly are indicated in a block acknowl-edgment which is sent back to the transmitter. The trans-mitter can then send a new chunk that contains only thecorrupt packets. Even though only part of a packet mayhave errors in it, 802.11n frame aggregation must retrans-mit whole packets: correctly received bits are wasted.

Frame combining can improve throughput, but it alsosignificantly increases latency, as senders must wait toaggregate enough frames to fill a jumbo frame. Blockacknowledgments provide a complementary aggregationof feedback for 802.11n, where ACKs may be bufferedtogether and sent as a group, similarly increasing per-packet latency. Maranello is complementary with theseframe aggregation techniques because by repairing cor-rupted aggregated packets, Maranello can further in-crease link throughput.

7.2 Optimal Block SizeThe Maranello block size is 64 bytes, primarily becauseit is the smallest multiple of 32 that can be supportedby hardware (Section 5.2.2). A larger block size wouldincrease computation efficiency somewhat and shortenNACKs, which may be useful at low bit rates. When theerror rate is low, however, larger blocks may lead to re-pair packets with unnecessary extra bytes, wasting chan-nel time.

We consider an interesting future direction of researchto be dynamically adjusting the block size. The idealblock size may vary based on an estimate of wirelesschannel conditions and the bit rate chosen by the trans-mitter, which determines the bit rate of the acknowledg-ment and thus the transmission time of the NACK. Whenthe NACK is transmitted at a low rate, it may be betterfor global throughput to keep NACK transmissions shortthan to be precise about the blocks in error. A similartradeoff exists in the FEC systems between the codingrate of error correction bits and recovery efficiency. An-other approach to determine the optimal block size thatwe intend to explore is to use theoretical models of wire-less communication errors [13, 29].

8 ConclusionIn this paper, we design, implement, and evaluateMaranello, a practical partial packet recovery protocolfor 802.11 wireless networks. Maranello has the follow-ing features simultaneously: (a) it introduces no extra

13

Date post:	05-Jun-2018
Category:	Documents
Upload:	duongthu
View:	221 times
Download:	0 times

Practical Partial Packet Recovery for 802.11: Maranello · Broadcom 802.11 network interface card)...

Documents