Net2WG/Notes/20070921
Contents
7/21/2007 Net2 Meeting Notes
Agenda
* CTP updates * Link layer/SP
Participants
* Mike * Razvan * Arsalan * Kyle * Om * Phil
Action Items
* Get in touch with the dissemination folks to update the interfaces (Kyle) * CC1000 white bit (Kyle) * Start discussion on the link layer (Om)
Discussion Notes
CTP updates
Om - I committed tos/lib/net/4bitle. If the link on which the packet has arrived is good (white bit), this estimator asks the router if the source of the packet is potentially on a good path to the root. If it is, it evicts a random neighbor from its table and inserts the source of the packet into the table.
Kyle - I have made changes in testapp due to new interface changes. Impacts dissemination as well as collection. Will interact with the dissemination people.
Om - The routing engine that I committed is incompatible with older link estimator. Should we delete the old link estimator?
Kyle - For internal testing and comparison it might be fine to have two versions. The external world should see one, the one that is know to be the best.
Om - So should we deprecate le?
Kyle - Yes.
Om - Lets defer on whether to delete it till later.
Link layer/SP
Om - I wanted us to review Arsalan's work from a long time ago, maybe a year ago and listen to any new insights and thoughts.
Arsalan - The original version SP done by Joe. Moteiv has its own. Berkeley has its own. What we realized was that it was kind of shaped along the lines of what features are interesting to design and expect other people to program using these features.
Joe talks about the good and bad aspects of SP on Moteiv blog. The one problem is Joe can customize his application for SP. Phil might say if someone who is unbiased, will that person use it or find it useful?
I personally think SP is useful. It provides link layer independence. There might be an argument that it is designed for TDMA. The original SP failed for rate control that is why there are protocols such as Flush and Rate Controlled Transport. I think the layer itself is useful but needs to trim itself to provide the fundamentals - link layer independence and neighbor table. Even message futures can be done. Caution against a huge bulky link layer saying it is general and can do anything with it.
Arsalan - What happens if there are two routing protocols for the compare bit? Need a central manager because they might not be designed to work well together. Priority does not help. Policy module for global commands.
Om - How can the policy manager help the new link estimator that uses the compare bit?
Arsalan - The policy manager, for example, can decide how many slots are allocated to each routing layer.
Om - Need a wider discussion with Joe, Phil, and others.
Om - Any further comments on doing away with buffer swap?
Arsalan - Reduces programming errors so it is a good idea in general though I understand Phil's argument.
Razvan - Can we provide the option to have either one. Radio provides both the interfaces and the applications decide which one to wire two.
Phil - Sure, one could do that. What bugs have people encountered that will be solved by copy interface.
Razvan - There were lots of implementation bugs but now with queue and pool it is harder to make a mistake.
Om - when you copy and try to swap that could introduce errors. lets do a wider discussion - a competent c programmer in an embedded platform, how much should that person know about Tinyos to not make this error.
