On Wed, Jun 8, 2011 at 6:36 AM, Jon Szymaniak <jts7...@rit.edu> wrote: > Hello All, > > I'd like to follow up on a post made in Feb 2010 > (http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2010-February/044460.html). > > From what I see in CtpRoutingEngineP.nc, CTP congestion control appears to > be disabled via the ECNOff variable being hardcoded to "true," implying > that nodes will never delay their transmissions or change their parent (with > sufficient ETX delta) due to the parent's C-bit being set to 1. Am I > correct? > > Also, could anyone provide any additional information regarding why > congestion control is disabled (i.e., why ECNOff is hardcoded to "true")? > Is this a design decision intended to offload congestion control to another > layer, a section of code that requires more testing, or a feature that > should be enabled only when an application can sacrifice latency for greater > packet delivery?
We tried doing congestion signaling based on simple threshold on the number of packets in the queue and packet forwarding delays when the bit is signaled. This led to unstable behavior and we turned it off. It is appropriate to use this bit for signaling but to use it properly you want mechanisms at higher layer. > In some Castalia-based simulations of CTP, I tried enabling congestion > control and did see a slightly more packets being delivered, with a tradeoff > of increased latencies and THL (hop count). This seems reasonable to me -- > packets could be delayed due to the congestion timer, and non-optimal routes > might be temporarily selected while a parent is congested. However, I would > appreciate any insights anyone has to offer on this. This is very interesting and you should share the results. - om_p _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
