The paper talks about a protocol that is built for applications that require the transport of high-rate data and which have got a little attention so far. But there are problems in supporting these applications which are limited radio bandwidth and these applications being loss-intolerant. The application data might be compressed to reduce bandwidth requirements but still they require reliable delivery. The protocols like these which handle voluminous data are normally seen to result in poor network performance just because of the volume of data they handle. An experiment performed is Los Angeles is cited as an example of this in the paper. This is just because of congestion as the design for such protocols is not carefully handled. Congestion in the network can lead to serious latency and eventually will lead to packet losses.
RCRT protocol is different than the already existing protocols as all the protocols studied so far either deal with one of the two issues but not both of them. The two issues being end-to-end delivery and congestion control. It seems strange to study this fact as both of these issues seem interlinked to give out a good network performance. RCRT protocol also demands the network to be able to support multiple concurrent streams from each sensor node as this seems to be the future which will make this protocol to be used widely. RCRT protocol also separates the capacity allocation policy to each node from the underlying transport mechanisms which makes this protocol to stand out.
End-to-end delivery of data and avoiding congestion control are the two basic features of this protocol. The entire protocol revolves around the sink which is the destination, also discovers the missing packets and explicitly requests them form the sensors. Sink decides that the network is congested if the time to repair a loss is significantly higher than a round-trip time. There are six goals which motivate the design of RCRT protocol which are Reliable end-to-end transmission, Network efficiency, support for concurrent applications, flexibility, minimal sensor functionality and robustness.
Three distinct Components which make RCRT different from other protocols are the Congestion detection component, Rate adaptation component and Rate Allocation component. End-to-End Reliability is one of the main features of RCRT and is implemented with the use of NACKs (Negative Acknowledgements). The design of RCRT protocol 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. 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.
Feedback packets are structured in such a way that they are self-contained so even if one of them is lost, the next feedback packet will adjust the node’s rate. Feedback packet contains assigned rate r, a list of NACKed sequence numbers, a cumulative ACK and the average value of RTT for that node. Due to increase in overhead, feedback packets are sent only on one of the 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).
Some of the issues RCRT tackles which have not been addressed in the previous protocols are 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 at least one of the congested nodes.
The drawbacks of this protocol are not addressed in the paper and all of them are left for 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. Also in real world when the protocol is implemented it needs to deal with issues such as network partition which the author does not address in here.
According to an argument in the paper, "If it takes more than few RTTs to recover the losses, then the network is more likely to congest." But the paper doesn’t explain much about why it is the case. To my knowledge, it is possible that more causes will cause the packet to be delayed for which the paper does not provide much information. The paper does not test the protocol with asymmetric nodes if the nodes have different sized retransmit buffers, nodes with smaller buffers may “hog” the traffic and essentially become higher priority than nodes that are capable of buffering packets. This could impact application performance if the application is expecting to receive traffic from multiple nodes for time-sensitive analysis. In a future paper,the authors could perform tests of the lifetime of the sources, as well as the sinks. I would assume the sinks would either have larger batteries or be connected to a constant source of power. Although reliability is an important factor in transporting large blocks of data, long battery life is an important feature that was not addressed.
No comments:
Post a Comment