Net2WG/Notes/20100115

---

---

Agenda

---

* TOS 2.1.1 testing status
* CTP feedback

Participants

---

* Luis, USC
* Phil, Stanford
* Om, Stanford
* Mike, JHU

Discussion Notes

---

TOS 2.1.1 testing status

Om: I updated the README for TestNetwork, so it describes what users should expect from a successful test.

Phil: I need to touch-base with a few people, and take a look at some patches. Hopefully, I can cut RC4 over the weekend.

Om: What about ZigBee WG?

Phil: I need to hear from the WG if they don't want to be included in this release.

CTP feedback

Om: I invited Luis from USC to share his experience building protocols on top of CTP.

Luis: I Worked with CTP while studying in Portugal. One project that I worked on was WMTP. We had a sparse testbed with obstacles such as the indoor garden. We found that CTP didn't converge well on our testbed, and picked links that might not be optimal.

Phil: CTP is very dynamic and can take some time to converge.

Luis: We also found that CTP prefers shorter routes over longer routes that might yield better packet reception rate. For example, if we hard-coded "ideal" route, the PRR was about 90%. However, CTP prefers direct link to the sink with 80% PRR.

Phil: Can we access this testbed?

Luis: The testbed does not have wired back-channel, so it might be a bit challenging to access from outside. I will get in touch with the admin.

Luis: I also think that the forwarding engine code should not be so tightly coupled with the CTP code (CtpP.nc). This way, users can easily change it. Also, if I want to use my own forwarding engine, the integration makes it hard to remove the original code.

Phil: There is a trade-off between modularity and code simplicity. When we designed CTP, we wanted the code to be tight, small, and high-performance.

Om: There are a few requests to separate out the forwarding engine. This could be one future direction.

Phil: I think it is also a good idea to have a good tutorial on the CTP code structure, something more than the TEP.