Refector: Heuristic Header Error Recovery for

Error-Tolerant Transmissions

Florian Schmidt, Muhammad Hamad Alizai, Ismet Aktas, Klaus Wehrle

Chair of Communication and Distributed Systems,

RWTH Aachen University, Germany

{schmidt,alizai,aktas,wehrle}@comsys.rwth-aachen.de

ABSTRACTHigh bit error rates reduce the performance of wireless net-works. This is exacerbated by the enforcement of bit-by-bitcorrect transmissions and the resulting retransmission over-head. Recently, research has focused on more efficient linklayer mechanisms and on tolerating payload errors. Headererrors, however, still cause today’s network and transportprotocols to drop the erroneous packets.

Instead of retransmitting such packets, we investigate anovel concept (called Refector ) of heuristically repairingheader bit errors. Refector accepts erroneous packets on endhosts and exploits protocol knowledge and protocol state toassign packets to their correct destination applications. Itoperates on layers 3 and 4, is independent of the underly-ing MAC and PHY, and requires no changes to hardware,firmware, and communication behavior.

We evaluate the Refector concept via a prototype imple-mentation deployed in an 802.11 network. Our results showthat Refector reduces packet loss in the network by morethan 25% when compared to payload-error-tolerant proto-cols such as UDP-Lite.

1. INTRODUCTIONA steady increase in the number of error-tolerant ap-

plications, for example, streaming audio and video, isplaying a pivotal role in how the packet-switched net-works have been evolving recently. For a long timeboth the (TCP/IP) network stack and the radio ac-cess catered to the demands for perfect data integrityof error-sensitive applications, for example, file transfersand SSH. However, error-tolerant applications, whichare more sensitive to network delays and packet lossthan to erroneous packets, have induced the followingseriated evolution in packet-switched networking:

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.ACM CoNEXT 2011, December 6–9 2011, Tokyo, Japan.Copyright 2011 ACM 978-1-4503-1041-3/11/0012 ...$10.00.

Everything error-sensitive: The (TCP/IP) networkstack and the medium access are error-sensitive. Pack-ets need to be retransmitted if not acknowledged at thelink layer. Protocols such as UDP are used to fasten thedelivery of out-of-order yet error-free packets to stream-ing applications.Error-aware medium access: While the medium ac-cess gains improved error handling, the network stackremains error-sensitive and can only handle error-freepackets. It thus needs to recover erroneous packetstransmitted over a medium, such as wireless, that ishighly susceptible to frequent transmission errors. Thishas led to a wide array of low-level error handling mech-anisms such as partial packet recovery [10, 14] and re-construction from retransmissions [8]. The majorityof these mechanisms requires significant modificationsin medium access technologies, i.e., in the protocolsand/or hardware at the link and physical layers.Payload error-tolerant protocols: Finally, proto-cols themselves become partially error-tolerant: Theyonly care about the integrity of packet headers, but theerrors in the data are ignored, assuming they are ac-ceptable for error-tolerant applications. UDP-Lite [19]is a prime example that leads this phase of evolution inpacket-switched networking.

Considering this evolutionary pedigree, a logical nextquestion should be whether we can make the networkstack also tolerant to header errors—if even packetswith those errors can be accepted. This paper exploresthe feasibility and limits of this novel approach in theform of Refector (lat.: repairer, mender): a system thataccepts erroneous packets, even if the errors are withinthe protocol headers, and heuristically repairs these er-rors and identifies the correct communication end-point.

The utility of this approach depends on two key ques-tions: (1) How many packets in a wireless network arelost due to header errors? Previous measurements tar-geted at 802.11 [26] have shown that bit errors, whilebursty in nature, can appear anywhere in a packet,and that furthermore, a header bit is at least as likelyto be corrupted as a payload bit. Therefore, a sub-stantial amount of sent packets is lost at the receiver

due to header errors even when payload errors are ig-nored. This is particularly true for applications withsmall packets, such as VoIP, which have more headerbits than payload bits. (2) Is delivering partially er-roneous data to the receiver beneficial? Error-tolerantapplications, such as VoIP, certainly benefit from par-tially corrupt packets [9]. We have also shown before ina simplified simulation [3] that, if header error toleranceand repair are feasible, there can be considerable gainsto speech quality.

Refector runs on end-hosts and transparently inte-grates with the header processing of protocols, primar-ily at the network and transport layer. Thus, its maintask is to assign erroneous packets to their correct ap-plications even in the presence of header errors. This isbased on two simple primitives: (1) Not all the headerfields of a packet are required by the network stack toidentify the target application at end-hosts. For exam-ple, an error in the TTL field at the end-host is im-material as far as the delivery of a packet to the rightapplication is concerned. Hence, at end-hosts, we canclassify different header fields based on their importancein identifying the target application. This classifica-tion enables Refector to ignore errors in certain headerfields. (2) Refector exploits the dynamic state of thenetwork stack to repair header errors. For example,two packets with the same UDP source-port and dif-ferent destination-port numbers, possibly due to errors,can be assigned to the same application if one of thedestination ports is either invalid or not open.

While the concept of Refector is a very general one,in this paper we primarily focus on the network andtransport layer and thereby stay independent of the un-derlying MAC and PHY layers. Our Refector prototypetargets IEEE 802.11 based wireless LANs. In such se-tups, the wireless connection between the end host andthe access point (i.e., the last hop over the Internet)is a major bottleneck for Internet communications. InSection 4.1 we show that Refector, when using NoAckschemes, reduces the average packet loss by more than25%, rendering it highly valuable for error-tolerant ap-plications in widespread 802.11 WLAN setups.

The rest of this paper is structured as follows. Webriefly describe Refector and discuss our design goalsin Section 2. The design of Refector is discussed in de-tail in Section 3. We evaluate Refector in an 802.11WLAN setup in Section 4. Finally, we discuss limita-tions in Section 5 and related work in Section 6 beforeconcluding the paper in Section 7.

2. SYSTEM OVERVIEWBefore exploring the details of how to repair header

errors, we present the basic operational ingredients ofRefector to facilitate a smooth sailing into the technicalconcepts discussed in Section 3. We further highlight

1! 1! 0! 0! 1! 0! 0! 1!…!…IN!

1!

2!

current open connections!

1! 0! 1! 1!…!…

1! 0! 0! 0! 0! 1!…!…

Figure 1: A simple example of port matchingvia Hamming distances. An incoming packetis matched against the expected values for twoflows. Flow 2 is chosen in this example becauseof the lower Hamming distance (2 vs. 4).

our goals that justify our design decisions, explain thereasoning behind different design trade-offs, and com-prehend the resulting limitations of Refector.

2.1 ConceptThe Refector approach follows a plain analogy with

how a local postman delivers a postal package with awrong address. Because of his experience in serving alocality, he can tolerate errors in the recipient’s nameor street address. Moreover, errors in certain fields ofa postal address, e.g., the country code, do not concerna local delivery. Similarly, Refector makes use of whatwe call domain knowledge, which comes in two forms.

Time-independent domain knowledge is the knowl-edge of a person familiar with a certain protocol abouthow important the different header fields are, on the endhost, to deduce the correct communication end-point.This knowledge can then be used to design a systemthat can tolerate header errors. We defer a detaileddiscussion on different fields to Section 3. One simpleexample is the TTL field in IP header. It is decre-mented at every intermediate hop, and the packet isdropped when the TTL reaches zero. However, on theend-host, this field is irrelevant, because the packet hasalready reached its destination. Despite the fact that awrong TTL field has no effect on the header or payloadprocessing, an error in any of the 8 TTL bits will resultin the packet being dropped because the checksum didnot match.

Time-dependent domain knowledge also takes into ac-count the current state of the system. On the end-host,we know which connections are open at any given pointin time. For each of these connections, a state is main-tained that tells how a header for this connection shouldlook like. The operating system needs this informationto match a packet to a specific connection. As a result,we can match even an erroneous incoming packet to anongoing connection by knowing which connections arecurrently open and which it most likely matches. A

simple example is given in Figure 1: A small headerexcerpt (for the sake of clarity), e.g. the port field, ismatched against two ongoing communication flows atthe end host. It does not perfectly match either of thetwo flows. However, since two bit flips are sufficientto match it to flow 2, as opposed to four bit flips tomatch it to flow 1, the decision is to assign the packetto connection 2.

As a similarity metric, we employ Hamming distances,i.e., the number of differing bits between two bit strings.It is a computationally inexpensive metric that com-putes bit similarity independent of the location of errorsin the string.

2.2 Design GoalsThe design of Refector leverages the following four

primary goals.Improving NoAck feasibility: NoAck schemes signifi-

cantly improve application throughput by avoiding ex-pensive acknowledgments and retransmission of highlytime-critical data, as demonstrated in Figure 2. NoAckschemes eliminate the need for per frame Ack which, be-sides inducing additional communication overhead, hasto honor the inter-frame timing constraints of 802.11.However, NoAck schemes suffer from high loss rates inlossy networks, and are barely usable when combinedwith full-coverage link-layer checksums. We want toenable NoAck schemes by introducing error-tolerancein the network stack. Unlike approaches such as UDP-Lite, we want to tolerate errors in packet headers, whichmeans more packets are successfully delivered to theright communication end-point. Consequently, we canachieve the envisioned advantages of these schemes suchas saving timeouts and retransmissions, reducing la-tency at the receiver’s side, and improving the over-all network performance by freeing air time for othertransmissions.

MAC and PHY compatibility: We do not want to in-troduce specialized MAC and PHY layers. This is be-cause changes in hardware or the overall infrastructure,such as WLAN, are expensive. Refector only imposestwo requirements on the underlying layers: (i) the abil-ity to pass through damaged packets, and (ii) the abil-ity to disable MAC acknowledgments, that is, NoAcksupport. These features are commonly available in theIEEE 802.11e extension for quality of service supportedby a wide range of commodity hardware. This exten-sion defines access categories—flows with different QoScriteria—and also supports disabling acknowledgmentson a per-packet basis via a flag in the MAC header.Thus, error-tolerant and error-sensitive flows can coex-ist by only disabling acknowledgments for packets be-longing to error-tolerant flows.

Protocol compatibility: We want to confine the changesintroduced by Refector to pure software changes. More-

0 5

10 15 20 25 30

1470 bytes payload

with ACKNoACK

0 5

10 15 20 25 30

Thro

ughp

ut [M

Bit/s

]

500 bytes payload

0 5

10 15 20 25 30

1 2 5.5 6 9 11 12 18 24 36 48 54

Bitrate [MBit/s]

50 bytes payload

Figure 2: Application-level throughput on802.11 with and without acknowledgments. Un-der good channel conditions, disabling acknowl-edgments can considerably improve throughput,especially at high bit rates.

over, the behavior of a Refector host to its communi-cation partners or an outside observer should remainstandard-compliant. This design goal enables Refec-tor to integrate well with existing IP based networksbecause it neither changes the communication relatedbehavior of protocols (i.e., UDP and IP) nor the trans-mitted data (both headers and payload).

Supporting heterogeneous application requirements:

We want Refector to be an optional, rather than manda-tory, feature for all applications running on an endhost. Applications such as VoIP shall be able to opt-into error-tolerant communication with Refector support,which leaves the standard case at completely error-freecommunication (e.g., FTP, but also control informationsuch as ARP). Thus, the integration of Refector withthe protocol-stack does not adversely affect the perfor-mance of concurrent applications.

Concluding, all our design goals favor accommodat-ing common requirements—such as compliance to theexisting standards, low deployment effort, and seam-less integration into existing systems—over potentiallymore effective optimization efforts that require disrup-tive changes in existing networked systems.

3. REFECTORThis section illustrates the design details of Refec-

tor. Approaches such as UDP-Lite filter out all packetswith errors in UDP headers. Packets with errors in IPheaders are also dropped before they reach UDP-Lite.

In contrast, the very purpose of Refector is to acceptpackets with errors in the UDP and the IP headers.

We particularly focus on the transport and networklayers (i.e., UDP and IP) for two reasons. First, thenetwork stack is a highly standardized design with thegoal of interoperability between many heterogeneoussystems. It is neither dependent on the underlyinghardware, firmware, or driver, nor on the applicationsthat use its functionality. This makes changes in thispart, as long as they do not impair compatibility, effec-tive and widely usable. Second, a plethora of solutionshas already been proposed on the application layer, forexample, streaming codecs to cope with partially erro-neous data [7, 12], and on the MAC layer with [10] andwithout [20] hardware/firmware changes.

Over the 30 years since the original specification ofUDP/IP protocols, their setup has remained unchanged.This is both a testament to the good design of the In-ternet protocol suite and to the issue that compatibilitybetween hosts is vital for the functioning of the Internet.Changing specifications or introducing new protocolsproves exceedingly difficult. The monotonousness ofthis Internet protocol specification, however, has lead toinefficiencies. Some techniques and their correspondingheader fields have gradually fallen out of use, e.g., frag-mentation and reassembly in the IPv4 protocol. Simi-larly, many fields are designed to contain a wide rangeof values, while in practice, at least on end hosts, onlyfew of these values are used at any given point in time.Refector leverages these inefficiencies both by ignoringthe contents of some fields, and by trying to introduceadditional redundancies in others where possible.

3.1 Header Fields CategorizationTo manipulate erroneous packets, Refector divides

header fields of a packet into two categories, don’t-care

and vital. Don’t-care fields are not required for identi-fying the right communication endpoint of a packet andare simply ignored by Refector. Vital fields however, iferroneous, have to be repaired.

In the following we show that each header field of IPand UDP protocols can either be categorized as don’t-care or as vital (cf. Figure 3). Furthermore, we showhow errors in vital header fields can be recognized andrepaired.

3.1.1 Internet ProtocolThe IPv4 header has a size of at least 20 bytes divided

into the following fields.Version and IHL: The first byte is split into a versionidentifier and the header length. We categorized bothof these fields as don’t care: The version field is redun-dant with information in the underlying MAC headerthat identifies the encapsulated network protocol. Wealso consider the header length static because header

!"########$########$########$########!%! &'

!"#$%&'

()*+,

-./0*12+34

()*"+&,+-"#.%/"

5 6 '7 '8

012

03"'4%,%/54%&'

(&456+2"'748

9657$ 9#57:"'4+;,,$"4

(%:"+4&+2%." 1"53"#+<8"/=$>:

0?+1"53"#

2"'748

$########$########$########$########$!" !%! &'5 6 '7 '8

@A?+1"53"#

<8"/=$>:

########$########$########$########

Figure 3: Classification of header fields in theIP and UDP header.

options (at least in IPv4) are practically non-existent.In a standard network, header options are rarely seen atall, and some are even deprecated and filtered by gate-ways (such as the originally defined routing headers).Type of Service: The next byte contains DiffServ [24]and ECN [25] information. We categorize DiffServ asdon’t-care because it is not required once the packethas reached its destination. We also categorize ECN asdon’t-care because (i) it does not impact the behaviorof IP layer, and (ii) TCP is not the focus of our workand will discard a corrupted packet in any case.Total Length: Total length is a two-byte field that con-tains the length in bytes of the complete packet at thispoint in time. There is little practical use in this fieldsince the actual packet length can easily be derived fromother sources of information, such as the MAC layeror the length of the packet in data memory. After apacket is received by the network interface, it is copiedinto the main computer memory and the operating sys-tem is informed about the length of data in this packet.Therefore, we categorize it as don’t care.Identification, flag and fragment offset : The next fourbytes contain information for IP-level fragmentation andreassembly. This feature has long fallen into obscuritydue to MTU discovery and MAC-level fragmentationand is not even part of the basic IPv6 header any more.Therefore, the three fields are considered as don’t-carein our approach.TTL: The TTL field is not required for protocol process-ing at the receiving host and is therefore categorized asdon’t care.Protocol : The protocol field identifies the next protocolhandler to be run once the packet leaves the IP handler.This is one of the most important fields at the end host,however, it is not easily repairable: For example, UDP(encoded as 17; 00001001) and ICMP (encoded as 1;00000001) are only separated by a single bit. Hence, a

single bit flip can result in the packet being forwardedto the wrong handler. We categorize this field as vital.Checksums: The IP header checksum only covers the IPheader itself. We categorized it as don’t-care because(i) it depends on a large number of fields that we cat-egorized as don’t-care, and (ii) the checksum in itselfdoes not provide us any information about the correctcommunication end-point.Source and Destination Address: Finally, the last 8bytes contain the sender and receiver IP address. Thesefields contain important information about the correctcommunication end-point and we mark them as vital.To repair these fields, we consider time-variant informa-tion about the currently ongoing communication flows:Refector maintains a list of IP addresses retrieved frompackets that are received without any errors.

After receiving a packet with errors, Refector matchesthe source address of the packet against the list of IPaddresses to find the best match in terms of the Ham-ming distance. We define a maximum Hamming dis-tance threshold to avoid attributing packets to wrongflows. Practical tests have shown that a threshold of3 effectively prevents misattributions (see Section 4.4)because other factors, such as UDP ports, are also con-sidered before the packet is delivered to an application.

Refector performs a similar matching between thedestination address in the header and valid addresses forthe receiving host. This approach may seem less effec-tive for numerically close destination addresses as mightoccur where several hosts in the same sub-network useRefector. Here, the small Hamming distance betweenaddresses might increase the risk of misattributions andacceptance of packets that were destined for anotherhost. However, before the packet reaches the IP layer,it has already passed another step of identification de-pending on the underlying medium access control tech-niques: A time or code division system or MAC addressensures that the packet was destined for the host. Com-pared to IP addresses, MAC addresses show a consid-erably higher randomness. Under the typical EthernetMAC addressing scheme, even in a network of machinesof the same type, three of the six bytes of the address donot show any noticeable correlation between the differ-ent hosts (the first three being a manufacturer prefix).Note that Refector, while it requires the MAC layer notto discard packets with CRC mismatches, does not ap-ply repair techniques to the MAC layer.

3.1.2 User Datagram ProtocolThe UDP header contains four fields of two bytes

each. In effect, the only functionality it adds on top ofIP are port numbers to allow demultiplexing of severalflows on one host.Source and Destination Ports: The first two fields con-tain the source and destination port of the flow the

packet belongs to. These fields contain the most im-portant piece of information to identify the right com-munication endpoint of a packet, and hence, we markthem as vital. Similar to IP addresses, Refector main-tains a list of port numbers derived from packets thatwere received without any errors. For packets with erro-neous port fields, Refector finds the best match from thelist in terms of the Hamming distance. Again, to pre-vent misattribution, it is necessary to find a Hammingdistance limit that facilitates effective repair withoutcreating packet misattribution. However, unlike IP ad-dresses, which are assigned to hosts in a fixed manner,port numbers can be actively chosen within a limitedrange, as discussed in the next section.Length and Checksums: The remaining two fields be-long to the don’t-care category. This is because thelength of the packet can be derived from the size of thedata structure containing the packet data. The check-sum covers the UDP header and payload, and is ignoredby Refector.

3.2 Port AllocationAs discussed in the previous section, the destination

port is the most important field in the UDP header withregard to identifying the communication endpoint at thereceiving host. By carefully allocating ports to applica-tions at the receiving host, we can make the port num-ber fields more resilient to bit errors. Therefore, Refec-tor modifies the kernel’s port assignment algorithm toincrease the Hamming distance between the ports num-bers1. This reduces the risk of attributing a packet toa wrong application.

3.2.1 Selection MechanismThe IANA defined “private ports” are in the range

between 49152 and 65535, but many operating systemsuse a larger range typically starting from 32768. Thisis the range readily available for our custom port al-location scheme. Refector employs BCH codes [2] toselect ports for error-tolerant applications. BCH codesconstruct “codewords”—port numbers in this case—thathave a predefined minimum Hamming distance betweeneach other.

A BCH code is a polynomial error-correcting codeover a finite field GF (qm) defined by a generator poly-nomial. With UDP ports, we have a binary field of 16bits. However, as all the port numbers with the mostsignificant bit set to 0 are reserved, we need a BCH codethat operates on codewords of 15 bit length. Therefore,Refector uses a BCH code over GF (215). The port num-bers are then created from these codewords by prepend-ing a most-significant bit 1.1Note that applications still can request specific ports, over-

riding the kernel’s allocation. However, they lose the advan-

tage of a guaranteed minimum Hamming distance.

generator polynomial no. data bits no. code bits min. distance corrects errors no. portsx4 + x+ 1 11 4 3 1 2048

x8 + x7 + x6 + x4 + 1 7 8 5 2 128x10 + x9 + x8 + x6 + x5 + x2 + 1 5 10 7 3 32

Table 1: Example generator polynomials for BCH codes. We used their property to create codewordsof a given length and minimal Hamming distance to choose port numbers that are distant enoughfrom each other to be resilient to a certain number of bit errors.

The choice of the generator polynomial influences thenumber of data bits and parity bits; a trade-off betweenits resilience to errors, and the number of ports we canchoose with that resilience. A collection of examplepolynomials and their properties are shown in Table 1.We use the generator polynomial x8+x7+x6+x4+1 forour implementation, giving us 128 ports for the rangestarting at 32768 (or 64 ports for 49152) at a minimumHamming distance of 5, and therefore, the ability tocorrect up to two bit errors.

We consider 128 ports sufficient because Refector isdesigned for end hosts, and the number of open connec-tions at any time is low on such machines. We moni-tored the number of open sockets on a student lab ma-chine during a normal workload of browsing, e-mail,instant messaging, etc., and never witnessed more than65 simultaneously open ports. Furthermore, if our allo-cation scheme runs out of ports, it will fall back to theoriginal scheme.

3.2.2 Analytic ApproximationAfter presenting our port assignment strategy, we

now analytically compare this strategy with the stan-dard case, that is, any port number in the private portrange can be assigned if the application does not choosea specific one. We focus on the case of less than 128 con-current connections and assume the worst case scenariounder this condition: The minimum Hamming distancebetween two port numbers is 5 in the case of Refectorand 1 in the standard case.

A Hamming distance of 1 means that two ports shareall but one bit, and this bit is the deciding factor inthe correct assignment (attribution) of a packet to thetarget application. The number of misattributions istherefore equal to the bit error rate (BER) assumingindependent distribution of errors. With an increasingnumber of ports with 1-bit Hamming distance betweenthem, the misattribution rate increases. This is becauseseveral bits in the 16-bit port field become deciding fac-tors. For n ports with 1-bit Hamming distance, themisattribution rate therefore can be approximated as:

1−�(1−BER)n

�(1)

In the case of Refector, the minimum Hamming dis-tance is always 5, that is, at least 3 of those 5 distancebits have to be flipped to cause misattribution. For two

0

0.2

0.4

0.6

0.8

1

10-3 10-2 10-1 100

Mis

attri

butio

n R

ate

Bit Error Rate

Standard port choiceRefector port choice

Figure 4: Packet misattribution rate: Refec-tor’s port selection algorithm creates a higherresilience to misattribution. Even at a BER of10−2, the worst-case misattribution rate is stillbelow 0.05%, compared to 14% in worst-casestandard assignment.

ports with 5-bit Hamming distance, the misattributionrate therefore becomes:

1−5�

k=3

�5

k

�BERk (1−BER)5−k (2)

For several ports with 5-bit Hamming distance be-tween them, the exact misattribution rate depends onhow many of the differing bits are overlapping betweenthese ports. The absolute worst case, in which everyport with a 5-bit distance is active, has a misattribu-tion rate of2:

1−15�

k=3

�15

k

�BERk (1−BER)15−k (3)

Figure 4 summarizes the worst case misattributionof Refector when compared with the standard case. Aspointed out, this analysis assumes that bit errors are in-dependent of each other. However, as in practice errorsin 802.11 tend to occur in bursts [26], we will comparethis analysis with our real-world evaluation results inSection 4.4.2This is actually strictly worse than what is defined by the

chosen BCH code, because no port will have all 5-bit neigh-

bors as valid choices.

0

20

40

60

80

100

54 48 36

Pack

ets

rece

ived

[%]

Bitrate [MBit/s]

payloadsize [byte]

50100500

1470

(a) UDP

0

20

40

60

80

100

54 48 36

Pack

ets

rece

ived

[%]

Bitrate [MBit/s]

payloadsize [byte]

50100500

1470

(b) UDP-Lite

0

20

40

60

80

100

54 48 36

Pack

ets

rece

ived

[%]

Bitrate [MBit/s]

payloadsize [byte]

50100500

1470

(c) Refector

Figure 5: Influence of payload size on packet loss: As opposed to UDP with checksum coverage ofheader and payload, where payload size influences the reception rate, UDP-Lite with a header-onlychecksum coverage, and Refector, which tolerates errors in headers and payload, have a receptionrate independent of payload size. (The graphs show results collected from one of our test machines.)

3.3 User-Kernel InterfaceOne of our design goals is to allow both error-tolerant

applications (e.g., VoIP) and error-sensitive applications(e.g., FTP) to coexist on a Refector host. Refector ex-tends the socket interface between the kernel and theapplications with the additional option SO_BROKENOKwhich is set by the application when it creates the socket.This option allows Refector to determine whether or notto deliver erroneous payloads, that is, payloads con-tained in packets with checksum mismatches on anylayer, to the application.

Refector also creates a signaling path in the oppo-site direction. The idea is to inform the applicationwhether or not the delivered payload is error-free. Thiscan be beneficial for an application even if it is readyto cope with erroneous data. When an application usesthe recvmsg system call to receive incoming data, it alsoreceives additional information in the form of a set offlags, such as whether the data fit the provided receive-buffer. Refector adds the flag MSG_HASERRORS, whichis set when a CRC check failed on any layer, and thusindicates that the delivered data may contain errors.

4. EVALUATING REFECTORThe evaluation of Refector is based on IEEE 802.11

based WLAN technology. Our evaluation focuses onthree key parameters: packet delivery rate, packet mis-attribution, and the influence of encryption on the per-formance of Refector. We conclude this section by dis-cussing the overhead introduced by Refector’s heuristicmatching.

In the following, we briefly describe our experimentalsetup before going into the details of our results.

4.1 Experimental SetupThroughout our evaluation, we compare Refector

with UDP-Lite, a standardized connectionless protocolthat allows partial checksums which only cover part

of a datagram, that is, header and an application-specified amount of the beginning of the payload. Forour evaluation, we set UDP-Lite’s checksum coverageto header-only for two reasons: (a) Including parts ofthe payload in the checksum negatively impacts theperformance of UDP-Lite in terms of the number ofpackets delivered to the application at the end host,and, (b) securing the header clearly shows the effectof header error-tolerance—the key difference betweenthe two techniques—introduced by Refector. Note thatUDP-Lite has the same usage requirements as Refector:Both approaches require support to receive erroneouspackets and disable MAC acknowledgments.

We implemented Refector for Linux kernel 2.6.32.27.Our experimental setup consisted of one AP and fourhosts. All the machines used network cards with anath5k [1] chipset. The AP machine provided AP func-tionality via hostapd [11]. To identify error-tolerantstreams, the sender application sets the IP header’sType-of-Service field to a value that is mapped to the802.11 access category “voice”, which was configured atthe AP to be sent out without acknowledgments.

We performed our experiments in an indoor settingat the computer science building of the RWTH AachenUniversity. The building has a very dense deployment ofAPs from the university network. We used 802.11 chan-nel 5 which is the same channel used by a neighboringAP of the university network. Hence, the ongoing traf-fic on these neighboring APs served as background andcompeting traffic. Because we did not have direct influ-ence on this traffic, we performed our experiments overthe course of several days and nights. Our experimentsfor this analysis have two key characteristics: (1) Eachexperimental run comprised one UDP-Lite flow and oneor several Refector flows per receiving host. (2) In eachexperimental run, the AP sent 10 000 packets per flow.Packets of all flows were sent concurrently; hence, slowchanges in the channel quality did not influence thecomparability of the results. We combined the results of

20%

30%

40%

50%

60%

70%

80%

90%

20% 30% 40% 50% 60% 70% 80% 90%

Pack

et D

eliv

ery

Rat

e R

efec

tor

Packet Delivery Rate UDP-Lite

0%

20%

40%

60%re

l. im

prov

emen

t

Figure 6: Lower Graph: Comparison of UDP-Lite and Refector by packet delivery rate over400 runs from different stations. Upper graph:relative improvement (packet loss using UDP-Lite divided by packet loss using Refector) ofRefector over UDP-Lite. On average, we wit-nessed an improvement of about 27%.

200 experimental runs on each machine to leverage thedifferent reception qualities caused by their positioningand timing of the experiments. Thus, we received re-sults for different error and packet loss rates.

4.2 Influence of payload size on packet lossBefore presenting detailed results on our key perfor-

mance parameters, we need to answer one question:Does the payload size impact the performance of Re-fector and UDP-Lite? It is important to answer thisquestion here because a negative answer will alleviatethe need to use payload size as a defining parameter inthe evaluation of Refector.

Figure 5 clearly shows that for UDP the size of thepayload impacts the overall packet loss in the network.However, packet loss rates of UDP-Lite and Refectorremain unaffected by varying payload sizes. This is be-cause UDP creates a checksum that secures its headerand the payload. For a fixed bit error rate, the num-ber of non-matching checksums therefore increases withpacket size. For our UDP-Lite setup, however, the cov-erage is fixed at 8 bytes. The number of non-matchingchecksums for a fixed bit error rate is now independentof payload size.

The same holds true for Refector because checksummismatches are ignored, so the checksum coverage is ef-fectively zero. This means that no erroneous packets aredropped because of checksum mismatches: The packet

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

1

0% 10% 20% 30% 40% 50%

CD

F

Improvement over UDP-Lite

Figure 7: CDF of the relative improvementachieved by Refector over UDP-Lite (as definedin Figure 6).

is only dropped if no communication end-point can bederived after applying Refector’s heuristic matching.Based on these results, for the rest of this evaluationsection, we will not use payload size as a factor in eval-uating Refector.

4.3 Packet Delivery RatePacket delivery rate, that is, the percentage of sent

packets that are delivered by the receiver to the ap-plication layer, is one of our key performance metrics.Figure 6 shows our results. The lower graph comparesthe packet delivery rate of Refector with UDP-Lite. Weexclude results with less than 20% and more than 99%delivery rate, because due to the very small and randomamount of packets received or lost, respectively, theseexperiments showed severe variation in results, even af-ter several days and nights of measurements. Each datapoint in the graph compares a UDP-Lite flow with asimultaneous Refector flow. Although varying channelconditions lead to diverse packet delivery rates, Refectoroutperforms UDP-Lite, which already tolerates errors inthe payload, in more than 99% of the experiments.

The upper graph in Figure 6 summarizes the resultsby presenting the relative improvement achieved by Re-fector, computed by dividing the number of packets lostusing UDP-Lite by the number of packets lost usingRefector. We use this metric for measuring relative im-provement because the difference between a packet lossof 1% and 2% can be significant for some error-tolerantapplications: They will show their most noticeable qual-ity degradation early on, that is, during the first fewpacket losses.

On average, Refector reduces the packet loss by 27%in the network when compared with UDP-Lite. Pleasenote that this average improvement is sensitive to howmany results at which delivery rate contribute to theaverage: Including an overwhelmingly large number ofexperiments at a very high or very low quality will skew

the average. Therefore, our experimental results pre-sented here are evenly spread over the whole range ofpacket delivery rates. Note that the relative improve-ment typically increases with the channel condition,that is, at more practical packet loss rates of less than10%, Refector tends to give a higher relative benefit.Finally, Figure 7 shows the CDF of relative improve-ment achieved by Refector in all the experimental runs.These results show the feasibility of Refector as a systemthat can improve the quality of error-tolerant applica-tions, such as voice and video, by reducing packet lossin the network.

4.4 Packet MisattributionAnother important factor is packet misattribution:

Because of the heuristic nature of Refector’s header er-ror tolerance, it is possible that packets are assigned tothe wrong application. Although we analytically provedin Section 3.2.2 that packet misattribution is negligiblewhen using Refector’s port selection mechanism, theseresults were based on the assumption that bit error ratesare independent from each other. This assumption con-tradicts the bursty errors rates observed in 802.11 basednetworks [26]. Hence, we investigate whether the ana-lytical approximation holds true in a real world deploy-ment.

There are two misattribution scenarios to distinguish:(1) misattribution between applications running on thesame end host, and (2) misattribution between appli-cations running on different hosts in the network. Inall our experiments, we did not see a single instance ofthe second case. This is due to a packet’s MAC addresscomparison with the destination’s MAC address at thelink layer.

To evaluate packet misattribution, we used two con-current Refector applications running on each host inthe network. We filled the application payloads withbit patterns specific to each flow and examined the re-ceived data to recognize misattributed packets. Fig-ure 8 compares our empirical result with the analyti-cal approximation (cf. Equation 2) from Section 3.2.2.Each data point is the result of 100 000 transmissions.It clearly shows that the packet misattribution rate isnegligible: Except for rare outliers, the misattributionrate remains below 0.1% until the payload bit errorrate increases above 3%, at which point packets areseverely corrupted, and loss rate even with Refector ex-ceeds 80%. Although these results are derived from twoconcurrent applications, we strongly believe that even inthe case of multiple applications the misattribution ratewill remain close to its respective analytical approxima-tion as long as the Refector port selection mechanismis used to assign port numbers to applications.

It is also important to note that misattribution canonly occur for error-tolerant applications that use Re-

0

0.002

0.004

0.006

0.008

0.01

10-3 10-2 10-1

Mis

attri

butio

n R

ate

Bit Error Rate

Measured resultsAnalytical approximation

Figure 8: Packet misattribution rates for twoconcurrent Refector applications.

fector. Error-sensitive applications require correct pack-ets (as indicated by correct checksums). Only erro-neous packets are processed by Refector’s heuristics,and those heuristics only take into account sockets of er-ror-tolerant applications. Therefore, Refector will neverassign an erroneous packet to an error-sensitive appli-cation.

4.5 Influence of EncryptionOur evaluation results so far were based on unen-

crypted communications. However, to enhance the pri-vacy of a wireless network’s users, encryption is oftenapplied on the MAC layer. Hence, we also measure theinfluence of encryption on the performance of Refector.

The 802.11 security subsystem provides two features:data integrity via a message identity code (MIC) andthe actual encryption of data. Enforced data integrityprotection is not possible with any error-tolerant trans-mission scheme because the two concept are mutuallyexclusive: either a receiver accepts errors in the receiveddata, or it imposes strong integrity check via MIC.

The influence of encryption on error-tolerant trans-missions primarily depends on the cipher’s error prop-agation, that is, the number of additional bits that willbe corrupted during decryption for each bit that wasreceived incorrectly. 802.11 provides two encryption al-ternatives: CCMP uses AES and TKIP uses RC4. AEScan corrupt up to 64 additional bits per bit error. How-ever, the stream cipher RC4 does not corrupt any ad-ditional bits during decryption. For this evaluation, wetherefore focus on TKIP/RC4 as the natural choice forerror-tolerant transmissions.

For this part of our evaluation, we introduced twochanges into the MAC layer implementation of the re-ceiver. (1) We ignored decryption errors, that is, mis-matches of the MIC, similar to accepting CRC mis-matches. As with any checksum mismatch, error-sen-sitive applications will not receive payloads that couldnot be checked via the MIC, upholding data integrity

20%

30%

40%

50%

60%

70%

80%

90%

20% 30% 40% 50% 60% 70% 80% 90%

Pack

et D

eliv

ery

Rat

e en

cryp

ted

Packet Delivery Rate unencrypted

(a) Comparison of an unencrypted and an encrypted

stream using Refector for error tolerance and repair.

20%

30%

40%

50%

60%

70%

80%

90%

20% 30% 40% 50% 60% 70% 80% 90%

Pack

et D

eliv

ery

Rat

e R

efec

tor

Packet Delivery Rate UDP-Lite

(b) Comparison of an encrypted Refector stream with an

encrypted UDP-Lite stream.

Figure 9: Influence of RC4 encryption on Refector’s error tolerance: While more packets are unsal-vageable, Refector still performs well under encryption, and still noticeably outperforms UDP-Lite.

protection for them. (2) We disabled countermea-sures (against potential attacks on the encryption) thatare taken by the MAC implementation if it witnessestoo many MIC mismatches. These changes only re-quired small modifications in the hardware-independentmac80211 [21] implementation inside the Linux kernel.It is important to note that these changes reduce the se-curity because it opens possibilities for additional crypt-analytic attacks. Therefore, these changes are merelyintroduced (i) to measure the influence of encryptionon the performance of Refector, and (ii) to support easydeployment of Refector in a network that encrypts allits frames on the MAC layer.

Figure 9(a) compares two concurrent UDP streamsusing Refector, one encrypted and one unencrypted. Itclearly shows that Refector achieves higher packet de-livery rate with unencrypted streams. This is becauseTKIP uses per-frame initialization vectors (IVs) to cre-ate a new key for every frame. If the IV, which is trans-mitted within the MAC header, is corrupted, the framecannot be decrypted at all. However, at delivery ratesabove 80%, the performance differences are small.

To show the advantage of Refector over UDP-Lite inan encrypted network, Figure 9(b) compares a Refectorstream with a UDP-Lite stream. This setup is directlycomparable to Figure 6 for the unencrypted case. Theresults are very similar: Refector’s advantage holds inthe encrypted scenario. Note that UDP-Lite also bene-fits from our changes to the MAC encryption implemen-tation. Without these changes, every bit error leads todropping the frame, rendering UDP-Lite’s payload errortolerance useless.

4.6 OverheadRefector’s heuristic matching introduces computa-

tional overhead in the network stack. However, thisoverhead is very small because:

1. Most header fields are categorized as don’t-care,and therefore do not require any repair effort.

2. For the remaining fields (i.e., IP addresses andports), Refector only computes their Hamming dis-tance—a computationally inexpensive operation—to members of a list of previously encountered ad-dresses and ports.

3. The number of these comparisons only linearly in-creases with the size of these lists. End hosts typ-ically do not have many IP addresses, and portcomparisons are only performed among ports ofRefector-enabled applications. Hence, these listsremain small, introducing very low memory re-quirements and also keeping the number of Ham-ming distance calculations very small.

Consequently, this low computational overhead of Re-fector was not even measurable on our test machines.

5. DISCUSSIONIn this section we highlight three major limitations

of Refector and shed light on how these limitations canbe dealt with.

Acknowledgment policies: Currently, the utilityof Refector is limited to NoAck schemes. This is pri-marily because our initial design goal is the seamlessintegration of Refector with existing MAC standards.

It is due to the strict timing constraints of existingMAC acknowledgment schemes, such as in 802.11, thatRefector is unable to coexist with such schemes. Forexample, the receiver has to decide within a short time-frame (the SIFS, typically between 10µs and 16µs)whether to acknowledge a frame or not. This time isinsufficient even to hand over the frame from the net-work card to the operating system. Relaxing the timingconstraints of acknowledgments at the MAC layer is asimple solution to overcome this problem and to extend

the benefits of Refector beyond NoAck schemes. Thisway, the receiver should be able to deliver the packetto the network stack and decide if the packet could beassigned to an application before sending out a positiveor negative acknowledgment for that packet.

Rate Adaptation: While Refector’s error-tolerantapproach can significantly improve packet delivery ratesat the application level, many rate adaptation schemes,such as the still widely used ARF [17] or the currentLinux default Minstrel [22], do not work out of the boxwith NoAck schemes. These rate adaptation schemesrely on acknowledgments as feedback for future rateadaptation decisions.

If Refector’s error-tolerant NoAck traffic constitutesa substantial portion of the traffic between a stationand an access-point, the rate adaptation performs sub-optimally. We are currently investigating a rate adap-tation scheme that will work without explicit per-framenotifications via acknowledgments. To this end, we areworking on a receiver-initiated rate adaptation that canintegrate with existing rate adaptation approaches, up-holding the principle of Refector being easily deployablein existing network infrastructures.

Multi-hop scenarios: A substantial amount of Re-fector’s improvement stems from the local knowledgethat can be leveraged at the receiving end-host. Thisdoes not necessarily hold true for relaying gateways.For example, unlike UDP ports, an IP address cannotsimply be matched against the locally used address(es),because the packet may needed to be relayed to a differ-ent host that we know nothing about. It is therefore anopen question how well Refector would perform in wire-less multi-hop scenarios, and how it could be adaptedto such scenarios. However, this question is of minorimportance and beyond the scope of discussion in thispaper because we specifically focused on WLAN setup,that is, a host directly connected to an access point.

6. RELATED WORKError tolerance within a communication system has

fostered a great deal of research effort in recent years.However, the majority of these efforts has focused onPHY and MAC layer solutions. Figure 10 depicts theprominent techniques that deal with recovering erro-neous packets.

Hybrid-ARQ [5] combines forward error correctionand retransmissions: additional FEC information is sentinstead of a simple retransmission. PPR [14] uses softinformation to recognize errors and only retransmit er-roneous parts. Similarly, SOFT [27] uses soft infor-mation received by several nodes, which then exchangethis information via Ethernet to reconstruct a correctcopy. ZigZag [8] uses the symbols received at the phys-ical layer from retransmissions of the same packet torecover erroneous packets. These solutions require spe-

Figure 10: Current approaches to achieve moreerror tolerance within a communication system.

cial hardware that gives access to soft information orthe PHY symbols.

In ZipTx [20], the receiver is required to send neg-ative acknowledgments to the sender to request parityinformation for recovering the packet. While it runs oncommodity 802.11 hardware, it changes the MAC layerbehavior. Maranello [10] creates multiple checksumsover blocks of the transmitted packet. The receiveronly requests the retransmission of erroneous blocks.It changes the 802.11 MAC protocol behavior in a waythat does not interfere with standard nodes in the samenetwork. MRD [23] combines information from mul-tiple receptions of a packet, either by multiple nodesor through retransmissions. All these solutions aim atcreating a correct copy of the packet to hand over tothe network stack. The goal of EEC [4] is to estimatethe BER and provide this information to sender and re-ceiver. The estimation introduces additional samplingdata into the packets and changes the MAC protocol.

Similar to Refector, Jiang [15] proposes to use redun-dancy in MAC addresses to heuristically correct errorsat the MAC layer of 802.11. However, it is not clear howthe system would perform in a real network, especiallysince it does not consider the inherent timing problemsof such a solution in 802.11. UDP-Lite [19] is among therare solutions that tackle erroneous packets at higherlayers of the protocol stack. It has prominently fea-tured in this paper as a benchmark and for comparativeevaluation of Refector. UDP-Liter [18] introduces com-patibility between UDP and UDP-Lite and presents anapplication-kernel interface similar to Refector.

Header compression schemes [13, 6, 16], while origi-nally aimed at reducing overhead, support error-tolerantcommunications: By reducing the header size, they de-crease the chance of bit errors in vital portions of thepacket. One of the most advanced schemes, robustheader compression (ROHC) [16], can reduce headers toabout 10% of their original size, and is planned for usein LTE cellular networks. However, header compres-sion needs to be deployed on all participating nodes onboth sides of the wireless connection as it changes com-munication behavior via compressed headers. Also, toremove all redundancies, each sender needs to maintain

the current state of connections of all its communicationpartners. In contrast, Refector only needs local knowl-edge about connection, resides on the receiver side, anddoes not change the communicated data.

7. CONCLUSIONWe presented Refector, a novel scheme that assigns

erroneous packets to their correct applications even inthe presence of header errors. Employing Refector inan 802.11 network without acknowledgments improvespacket delivery rate by more than 25% using negligiblecomputational resources. We also showed that the usedheuristics produce very little error, and that it is possi-ble to use Refector with encryption, depending on theused cipher.

We identify the following aspects as future work.(1) Analyze the wide applicability of Refector by evalu-ating it using other MAC protocols and physical layers.In fact, 802.11 is a rather unforgiving system for er-ror tolerance because of its strict acknowledgment tim-ing policies. We are currently investigating the effectsof Refector in other scenarios. (2) Extend the use ofRefector towards multi-hop wireless network scenariossuch as wireless mesh networks and sensor nets. (3) In-tegrate Refector with error-aware medium access tech-nologies, such as Maranello [10], to see if these ap-proaches compliment each other to improve packet de-livery and reduce retransmissions in a lossy wirelessnetwork. (4) Combine Refector with soft-informationbased schemes such as PPR’s SoftPHY [14] for 802.11networks.

Overall, this paper shows the applicability of Refec-tor as a solution to enhance packet delivery in lossywireless networks. Our evaluation under different net-working conditions shows that Refector can realize itsadvantages in real world deployments.

AcknowledgmentsWe would like to thank Stefan Götz, Raimondas Sas-nauskas, and Elias Weingärtner for many fruitful discus-sions and valuable feedback. This research was fundedin part by the DFG Cluster of Excellence on Ultra High-Speed Mobile Information and Communication (UMIC).

8. REFERENCES[1] Linux Wireless ath5k driver. [Online] Available

http://wireless.kernel.org/en/users/Drivers/ath5kOctober 12, 2011.

[2] R. C. Bose and D. K. Ray-Chaudhuri. On a class of errorcorrecting binary group codes. Information and Control,3(1):68–79, 1960.

[3] T. Breddermann, H. Lüders, P. Vary, I. Aktas, andF. Schmidt. Iterative Source-Channel Decoding withCross-Layer Support for Wireless VoIP. In Proc. ITG SCC,2010.

[4] B. Chen, Z. Zhou, Y. Zhao, and H. Yu. Efficient errorestimating coding: feasibility and applications. In Proc.

SIGCOMM, pages 3–14, 2010.

[5] R. Comroe and D. Costello. ARQ Schemes for DataTransmission in Mobile Radio Systems. IEEE Journal on

Selected Areas in Communications, 2(4):472–481, July1984.

[6] M. Degermark, B. Nordgren, and S. Pink. IP HeaderCompression. RFC 2507, IETF, Feb. 1999.

[7] ETSI EN 301 704 V7.2.1 (2000-04). Adaptive Multi-Rate

(AMR) Speech Transcoding (GSM 06.90 Version 7.2.1

Release 1998), Apr. 2000.[8] S. Gollakota and D. Katabi. Zigzag decoding: combating

hidden terminals in wireless networks. In Proc. SIGCOMM,pages 159–170, New York, USA, 2008. ACM.

[9] F. Hammer, P. Reichl, T. Nordström, and G. Kubin.Corrupted speech data considered useful: Improvingperceived speech quality of voip over error-prone channels.Acta acustica, 90:1052–1060, Dec. 2004.

[10] B. Han, A. Schulman, F. Gringoli, N. Spring,B. Bhattacharjee, L. Nava, L. Ji, S. Lee, and R. Miller.Maranello: practical partial packet recovery for 802.11. InProc. NSDI. USENIX Association, 2010.

[11] hostapd. [Online] Available http://w1.fi/hostapd/October 12, 2011.

[12] ITU. ITU-T Recommendation G.729, Jan. 2007.[13] V. Jacobson. Compressing TCP/IP Headers for Low-Speed

Serial Links. RFC 1144, IETF, Feb. 1990.[14] K. Jamieson and H. Balakrishnan. PPR: Partial Packet

Recovery for Wireless Networks. In Proc. SIGCOMM,pages 315–326, August 2007.

[15] W. Jiang. Bit Error Correction without Redundant Data: aMAC Layer Technique for 802.11 Networks. In Proc.

WiNMee, Apr. 2006.[16] L.-E. Jonsson, K. Sandlund, G. Pelletier, and P. Kremer.

RObust Header Compression (ROHC): Corrections andClarifications to RFC 3095. RFC 4815, IETF, Feb. 2007.

[17] A. Kamerman and L. Monteban. WaveLAN-II: ahigh-performance wireless LAN for the unlicensed band.Bell Labs Technical Journal, 2(3):118–133, 1997.

[18] P.-K. Lam and S. Liew. UDP-Liter: an improved UDPprotocol for real-time multimedia applications over wirelesslinks. In Proc. Wireless Communication Systems, 2004,pages 314–318, Sept. 2004.

[19] L.-Å. Larzon, M. Degermark, S. Pink, E. Jonsson, andE. Fairhurst. The lightweight user datagram protocol(UDP-Lite). RFC 3828, IETF, July 2004.

[20] K. C.-J. Lin, N. Kushman, and D. Katabi. Ziptx:Harnessing partial packets in 802.11 networks. In Proc.

MOBICOM, pages 351–362. ACM, 2008.[21] Linux Wireless mac80211 framework. [Online] Available

http://linuxwireless.org/en/developers/Documentation/mac80211, October 12, 2011.

[22] Minstrel rate control algorithm. [Online] Availablehttp://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/minstrel, October12, 2011.

[23] A. Miu, H. Balakrishnan, and C. E. Koksal. Improving lossresilience with multi-radio diversity in wireless networks. InProc. ACM MOBICOM, pages 16–30, 2005.

[24] K. Nichols, S. Blake, F. Baker, and D. Black. Definition ofthe Differentiated Services Field (DS Field) in the IPv4 andIPv6 Headers. RFC 2474, IETF, Dec. 1998.

[25] K. Ramakrishnan, S. Floyd, and D. Black. The Addition ofExplicit Congestion Notification (ECN) to IP. RFC 3168,IETF, Sept. 2001.

[26] A. Willig, M. Kubisch, C. Hoene, and A. Wolisz.Measurements of a wireless link in an industrialenvironment using an IEEE 802.11-compliant physicallayer. Industrial Electronics, IEEE Transactions on,49(6):1265–1282, Dec. 2002.

[27] G. Woo, P. Kheradpour, D. Shen, and D. Katabi. Beyondthe bits: cooperative packet recovery using physical layerinformation. In Proc. MOBICOM, pages 147–158. ACM,2007.