This paper describes COPE, a forwarding architecture that employs the wireless coding technique of XORing multiple packets together at a router to reduce the number of total transmissions. COPE sits between the IP and MAC layers and decides which packets it can encode together to maximize the number of packets sent in one transmission while at the same time ensuring that nexthops have enough information to actually decode the packet intended for it.
Nodes know which packets its neighbors have via reception reports that nodes broadcast frequently; however, this method fails in congestive periods, at which point nodes are left to guess which packets neighbors have based on routing metrics like ETX. The topmost principle used by COPE is to never delay packets waiting around for other packets it can code with that at the head of its queue. Additionally, COPE tries to send packets of the same length, which equates to padding shorter packets with zeroes if needed and queueing short and long packets in two different virtual queues per nexthop.
COPE adds a packet header that includes IDs of the native packets and their nexthops, as well as reception reports and cumulative ACKs. Even with this additional overhead, COPE can provide an increase in goodput in addition to an increase in coding gain. The hidden terminal scenario of wireless hurts COPE's TCP goodput, but when hidden terminals are disallowed (hence removing lots of collisions) COPE can improve TCP's goodput by over 30%.
I was surprised to see that packets were coded between 20-50% of the time based on guessing. Since COPE seems to perform well with guessing, it makes me wonder if reception reports are even really necessary at all. An interesting point of this coding scheme is that because multiple packets destined for the same nexthop can't be coded together, it opens up the fairness realm for packets destined towards a neighbor that might not oterhwise have been able to capture the media for a while. I like the simple notion behind this paper of using XOR operations to reduce the number of packets transmitted, though as the paper admits, this technique will not work so well for a network that is energy-limited.
1 comment:
The approach is clever, borrowing from prior work on efficient multicast. But in the end, there is a question of just how practical the approach is. Certainly support for TCP and managing the packet caches presents issues. The energy issue is also a good one.
Post a Comment