RCRT:Rate-Controlled Reliable Transport Protocol for Wireless Sensor Networks JEONGYEUP PAEK, RAMESH GOVINDAN University of Southern California 1
Applications that require the transport of high-rate data have got a little attention so far. To support these applications we need to solve two problems: Limited radio bandwidth. Loss-intolerant. Also, protocols designed for such end-to-end delivery of voluminous data can result in poor network performance. Congestion in the network can lead to serious latency and eventually will lead to packet losses as seen in the graph shown below: 2
We can see here more than half the packets were delivered more than an hour after they were injected into the network. 3
Why is RCRT protocol different than the already existing ones? All the protocols studied so far either deal with reliable end-to-end delivery of data OR discuss a congestion control mechanism without ensuring end-to-end reliable delivery. The protocol demands the network to be able to support multiple concurrent streams from each sensor node. RCRT protocol separates the capacity allocation policy to each node from the underlying transport mechanisms. 4
END-to-END Delivery: Basic approach where the sink discovers missing packets and explicitly requests them from the sensors. CONGESTION CONTROL MECHANISM: Sink decides that the network is congested if the time to repair a loss is significantly higher than a round-trip time. 5
Six Goals which guide the design of RCRT protocol: Reliable end-to-end transmission. Network Efficiency. Support for concurrent applications. Flexibility. Minimal sensor functionality. Robustness. 6
Three distinct Components which makes RCRT different from other protocols:- 1. Congestion detection component: observes packet loss and recovery dynamics and decided on congestion. 3. Rate Adaptation component: estimates the total sustainable traffic in the network. 4. Rate Allocation component: adjusts the overall rate in agreement with the allocation policy P j for the sink j. 7
End-to-End Reliability. The design leverages the fact that the sink has enough memory to keep the track of all missing packets. The sink keeps track of sequence number of received packets and a gap in this sequence number indicates packet loss. NACKs (which avoid ACK implosion and thus reduces overhead)are used to indicate the respective sensor node of the loss of packets. 8
- The source node overwrites its retransmit buffer once it receives cumulative ACKs in the feedback packet. - The sink also maintains a list of out-of-order packets for each flow to provide in-order delivery of data packets to the application. 9
Congestion Detection: Ideally 1 RTT should be the time required to recover a loss. So if it takes more than few RTTs to recover the losses, then network is more likely to be congested. Hence, expected number of packets during one RTT is r(i) * RTT(i). So if the sum of out-of-order packet list and the missing packet list at the sink is equal to the above product, it means 1 RTT has passed since the first recovered loss. 10
Rate Adaptation: RCRT is unique in this aspect as it adjusts the total aggregate rate of all the flows as observed by the sink rather than the rate of a single flow. This makes RCRT protocol independent of the number of flows and less oscillatory when there are a large number of flows. RCRT protocol implements rate adaptation only after waiting for 3 RTT + 3(current inter-packet interval) so that the congestion measures at the sink are appropriately updated. 11
12
Rate Allocation: RCRT s rate allocation component assigns rates to each flow in keeping with the rate allocation policy such that the individual flow rates sum upto R(t). Also each node expresses a desired rate that we call its demand and the policy allocates rates to each node proportional to its demand. 13
Feedback packets: Feedback packet contains assigned rate r, a list of NACKed sequence numbers, a cumulative ACK and the RTTavg value for that node. Due to increase in overhead, feedback packets are sent only on one of the following conditions Detection of one or more missing packets. The node is sending at a rate different from the assigned rate. A duplicate packet with an already acknowledged sequence number has been received. A feedback packet has been explicitly requested by the node (generally happens after half of the retransmit queue is filled). 14
RCRT tackles the problem of detecting the loss of last packet during connection tear-down where the sender and the sink synchronize their sequence numbers. RCRT adaptation to the network scenario will be delayed in case of bursty losses and loss of consecutive feedback packets but will eventually control the situation as it will receive one packet from atleast one of the congested nodes. 15
FUTURE WORK RCRT protocol supports multiple concurrent applications but coordination between rate allocation across multiple sinks is yet to be taken care of. RCRT adjusts the total flow in the network and hence unconstrained bottleneck regions also get affected. As RCRT makes decisions on RTT timescales, the convergence time could be large in case of networks with high maximum RTT. Also since each of the nodes experience congestion for different fractions of their lifetimes, demand proportional allocation policy used by RCRT is possible but difficult to implement on a long term basis which is left to future work. 16
Thank You. 17