Wednesday, October 8, 2008

XORs in the Air: Practical Wireless Network Coding

This paper puts a lot of theory into practice. The main idea that was introduced was basically doing packing coding to improve on the throughput. But XORing together different packets and broadcasting them, the receivers can XOR the received packet again to obtain the needed data. This way you can transmit multiple packets at once and save on number of transmissions. The paper lends itself to the natural broadcast that wireless networks come with. Receivers hear each other's packets all the time, which this method leverages.

Several issues arise, such as knowing which packets to XOR together to get maximum bandwidth. While reading the paper, it was still not clear to me how they determined what to XOR the packet with. They used simple examples of two nodes transmitting, but this method has to assume that the receiving node has the same data information as another sender's packet, or else how else would the router XOR 2 packets together? The results are more promising for UDP, as they don't implement congestion control in the protocol, thus it would get congested easier, which allows more packets to be XORed together. This of course improves the performance compared to the congested UDP, but does that mean that it can prevent network congestion?

All in all it seems like the implementation was rather complicated for a low gain. So many mechanisms need to be added to the hardware switches, and different packet headers need to be appended onto the data packets while being transmitted. Also, it now takes the receiver even more work after it receives it, and there's a chance that the XORed packet guessed wrong about the receiver node's packets, and the receiver actually can't XOR back the native packet. For this protocol to really become mainstream, it seems the gain in throughput needs to be off the roof for it to be convincing in anyway. But from the results, it wasn't spectacular, especially for the tcp cases. Congestion control would back off packets anyway, so throughput gain will be limited.

1 comment:

Randy H. Katz said...

I agree with some of your skepticism. Theoretically, the idea is very interesting and the evaluation is good. The implementation details seems complicated however, and some details are not immediately obvious in the paper -- e.g., how the packet pool is actually managed.