(Kim, et al.)
RCRT: Rate-Controlled Reliable Transport for Wireless Sensor Networks
(Paek, et al.)
Today we discussed two protocols that solve the problem of reliable and rate limited transport in wireless sensor networks. First, we discussed the similarities between the two designs and came to the conclusion that both papers use end-to-end NACKS, link-layer ARQ, and provide some sort of mechanism to communicate control information from the nodes. One thing that was not explicitly stated in either of the papers was the different applications for which Flush and RCRT were designed. This addressed some of the skepticism I had about the feasibility of these implementations for general sensor network deployments, since each paper makes assumptions that are not be universally applicable.
I thought the Flush paper somewhat oversimplified the problem of source to sink data transport by accounting for only 1 data flow at any instant. This means that the sink has to directly request data from each source node. While the design works great from a single flow, it also means that all the congestion and rate control information only goes one way: from the source to the sink. There is no mention of the Flush design working in the other direction, and packets from the sink are transported reliably by each node transmitting to the next node in the routing path with ACK confirmation at each step. Flush could probably be modified to handle both directions with some additional overhead.
In the intro, the authors mention that Flush can adapt to varying network conditions. When I first read this, I assumed that Flush would adapt to nodes leaving the network and re-entering or scenarios where the routing path changes. In the evaluation section, I was disappointed to see that the test for adaptability was just having the nodes drop packets at a probability of 0.5 for an interval of 10 seconds. Therefore, the adaptability claim wasn’t properly addressed in terms of node failures, and all other experiments were conducted by freezing the routing tree for every run.
The main discussion point concerning RCRT was the “totalitarian” nature of the relationship between the sink and the network. In other words, when a node’s RTT for repairing a loss exceeds 4, the sink limits the rate of EVERY node by using a multiplicative rule. To bring the network’s rate back up again, every node has to fall below the threshold. We inferred that the authors did this maybe because modifying the rates of each node on an individual basis is too difficult. The network becomes too complex, and it becomes exceedingly difficult for the sink to understand exactly how the nodes affect and interact with each other.
One of the more general philosophical points dealt with the inevitable choice between avoiding congestion and detecting congestion and taking subsequent action. In the RCRT paper, we saw that the network “heals” itself as congestion increases. However, IFRC takes the opposite approach and does what is necessary to prevent the network from being congested. We came to the conclusion that the latter approach will most always lead to better energy utilization because there is never any wasted “effort”. In other words, packet loss leads to the wasted energy since the amount utilized cannot be regained.
