By adding redundancy to transmitted 802.11 frames in software, we were able to extend the range of an outdoor line-of-sight link by 70 percent, or 0.37 miles, and reduce losses significantly on marginal indoor and outdoor links. But without link retransmissions for packets that fail error correction, users will still have difficulty making productive use of a marginal link, even with error coding. To be more usable, we will need to examine:
Retransmissions after error correction. To be able to use TCP over a marginal link, users of rs-link will have to duplicate the functionality of link-layer retransmissions at a higher level, after error correction. A loss rate of 17 percent, while certainly better than 68 percent, is still not good enough to run TCP. One way to add link-layer retransmissions above the error-correction layer is by using the LL-SMART-TCP-AWARE protocol described in [1]. Under LL-SMART-TCP-AWARE (or the simpler ``snoop'' protocol also discussed), link endpoints cache TCP segments as they cross the link, suppress duplicate acknowledgements, and retransmit segments that appear to have failed.
Error feedback. As implemented, rs-link uses 34 percent of the 802.11 link bandwidth for redundancy information. This is worth it if the result is a 75 percent reduction in loss rate, as in the case of our 0.55-mile link. But it's not worth it for a less-marginal link. rs-link should receive feedback on the amount of observed errors from the receiver and adjust the level of added redundancy as appropriate.
Why are Roofnet's results different? Preliminary efforts by the Roofnet group to record and salvage errored frames at 1 Mbit/sec have given disappointing results -- errored frames end up completely corrupted. Why are their results so different from ours? Are urban links with multipath fundamentally different from the line-of-sight outdoor and through-walls indoor links we have examined?