Net2WG/Notes/20060928
Net2WG 20060928 Meeting Note
Agenda
*Link Layer Interface *Status Update
Participants
Arsalan (A), Ning (N), Om(O), Phil(P), Rodrigo(R), Sukun(S), Note: Sukun
Note
Link layer update, general update. Deluge port
A: A few interface update in the wiki. There might be semantic issues, global behavior, delay, etc. It will be sent out today. It goes over how to structure, what is link layer abstraction, main components (Message pool, neighbor table, link estimator). There are two questions: What information will be exposed? How do we put policy in the routing table?
P: Hold duration?
A: ‘Hold for’ is a period of time to pass a message to the link layer. In Trickle case, you wait for that much, if something is coming to the queue, we don’t send it.
A: It is a way to handle heavy queue.
A: Scott talks about sending out this interface to other universities.
P: Good place would be Tinyos-devel. There are lots of university and industry people. There will give pretty good feedbacks.
A: It would be good to have as much feedback as possible.
R: That can be the role of TEP like RFC. RFC is ‘request for comments’.
P: We can send a draft of TEP.
R: It would be great to have something to send as a document.
A: We can send this out to the group, then to Tinyos-devel.
P: The questions will be which interface is better, which is not.
A: The size of link layer abstraction is a little larger than SP. We decided that timing units should be terms of packets, or keep it as a real time?
R: Packet seems to be more portable across platforms.
P: At application layer, time would be easier.
R: We can go with both.
R: Does ‘Hold for’ have to be done at the link layer?
A: It depends on how much efficiency bias we can get by putting it there.
R: It might be better to keep the link layer minimal.
P: What are the key features communities want.
R: What missing functionality would disable any protocol, so it can not run?
P: Any protocol requiring exact timing of sending a packet. Important thing would be how big is the class of protocols which are supported.
R: What applications we are supporting may not be clear.
P: We can present to community about what should be in and what should be out.
R: That sounds a good idea.
P: Low power link for CC2420 would be a candidate of work.
P: As Rodrigo talked, it would be good to repeat the test like before.
P: In SenSys, it might be good for all of us give a small presentation: what we’ve been doing. After the poster session on Thursday evening.
O: In terms of test plan, do we do the similar tests?
P: Yes, it would be.
O: Rodrigo and I would be main people for testing?
R: Kyle did some tests.
P: Ning, do you have a testbed? Are you interested in tests?
N: Yes, sure. There are 20 MicaZ node testbed, but they are very close by.
R: It will be good enough to look for the problem. Let us wait for the green light for the code, and we can start.
P: The code would be ready on Monday.
