Net2WG/Notes/200802029
Net2WG/Notes/200802029 Meeting Notes
Agenda
* TTX
Participants
* Om, USC * Phil, Stanford * Romain * Rodrigo, Berkeley * Razvan, JHU
Discussion Notes
TTX
People: - Phil - Om - Romain - Rodrigo - Razvan
TTX:
Om: Almost no interest in network protocols.
Phil: Are you joking?
Om: There were very few people that offered help.
Phil: Let's back off. Nobody is going to leap out their seats and say: I'm ready to hack thousands of line of code for you in that kind of a setting. The theme of the meeting was the action has moved from core into net2.
Om: I said that to get some feedback and have that kind of reaction. Nobody offered to test or write code. Except for Zigbee which Martin did say he can help out. He came and talk to me during the working session. There was also the comment by David about 6lowpan and the compatibility on the wire. This I think were the two direct comments/questions.
Phil: I talked with David numerous times about that. Jonathan Hui has even write a TEP on this. It's not net2's problem, it's core's problem.
Om: Right. There is one issue we discuss and I need to follow up with David about this: it would be good if we have access to the interfaces they use for 6lowpan. It would be nice to have compatible interfaces.
Phil: I talk with Jonathan about this. We'll see how much Arch Rock will stay involved.
Om: Those are the interaction that I had. I didn't receive any request for new protocols. Did you hear any new requests?
Phil: No.
Om: There is the comment from John Regehr to make a table with all the net2 offerings for people to be aware about what we have. That PowerPoint slide we had in the presentation is a first step but we could make it a lot better.
Om: So those were the interaction I had. Razvan, did anyone talk to you? About Deluge?
Razvan: There was somebody interested (WenZhan Song from Washington State University) in Deluge in iMote2. They are working in tinyos-1.x which is something I cannot help much.
Phil: Is there support for iMote2 in tinyos-1.x?
Razvan: Apparently the support in tinyos-1.x is better than tinyos-2.x.
Phil: Wow...
Om: iMote2 will be an obsolete platform?
Phil: There is no maintainer.
Razvan: What happened with Arch Rock? Phil: I sent and email about this. Intel hired Arch Rock to write a port. The contract ended in 2006 and Arch Rock is no longer supporting the platform.
Om: Is Intel still interest in this platform?
Phil: No idea.
[ Rodrigo joined the call ]
Om: Did anyone say anything to you during the TTX? CTP? net2?
Rodrigo: No. There was a question from Steve which is a student at Berkeley about CTP traces. He mentioned that in some cases a node which has a parent which is root one hop away and another one that is little worse that is two hops away. It selects the closest one but then there is a spike in the quality that goes down. What happens is the node looks at the other node and say: aha, this one is better! So it selects the other node and now will never go back to the one that is one hop away.
Phil: So his basic argument is the threshold of 1.5 is too high. If the one link goes to 2.5 or jumps to 6 and the goes to 2 then it will never go from the 2 to 1. My response to that was how frequent is this phenomena. If it is significant then we'll have to take care of it.
Om: BWT, Romain is here. He is the Tymo developer. Romain, do you have any comments on the net2 protocols? I think that PPT was your first introduction to all the activities from net2.
Romain: No, nothing special. I worked with some of them a few months ago.
Om: I want to push TYMO towards release so let us know when we need to test. I know you are working on documentation, test programs and stuff like that. Let's talk about some of the emails from tinyos-devel.
Phil: Sure.
Om: One is link cost. I didn't get a response but I think is a big problem if we are going to do that.
Phil: My position is a little different: if just one person wants to reduce the MultihopLQI forwarding engine this doesn't mean we should generalize this call with no clear benefit in sight.
Om: Maybe we should talk about the future of the MultihopLQI. Phil, you want to keep it as close as tinyos-1.x and there are others that wants to improve it. And I think you said that maybe we should fork it.
Phil: My position is a little subtle than that. To go in research mode churning the code because we feel like improving, given how many people probably depend on it, it sort of... mean. Rather, if we want to develop a new protocol we should.
Om: Are we sure a lot of people are using it? We are not sure, aren't we?
Phil: Here is what you should do: you should go an tweak with the implementation and when 2.1 will come out and lots of people's code will brake then try to deal with the situation. That's kind of my feeling.
[ some discussion about avoiding changing things without clear performance benefits ]
Razvan: I have some things to ask. First: in TOSSIM there is a file called UscGainInterferenceModelC.nc. Is that still workable? Is something using it? Are there examples?
Phil: This is not net2 but we can talk it here. It was that existed before I added CPM so it still exists.
Razvan: Does it still work?
Phil: Sure. I haven't test it in the 9 months but in theory it should. Part of the problem is that it has a different interface, a different way to configure it than CPM.
Razvan: And there is no example? Let's say I want to use it...
Phil: Go back to 2.0. Look at 2.0 tutorials.
Razvan: OK, ok. Another question: in CTP, in the forwarding engine there are two queues: one for the packets initiated locally and one for the packets that come from other nodes. Right?
Phil: No. There is only one queue.
Razvan: There is only one but the guys that are locally only have one slot in this queue. Right?
Phil/Om: Yes.
Razvan: This I think might be a problem. If I have a big forwarding queue some outside nodes can inject mode packets and can depreciate the performance of the local guys.
Phil: This is correct. We talked about this and there were 2 choices. It also depends where are you in the tree and how big is the subtree size. If the throughput is the issue then you'll need to dynamically estimate. The decision was for each local sender to have a slot or all local senders to share a slot. I actually argue for the latter which is even worse if you have like 50 local senders. I thought that was actually better but I was overruled and Kyle though that having one per sender was better. Clearly it depends on your situation. One way to deal with this is to allocate more local senders and based on estimates of the subtree size allow the local senders to use more of those local slots.
Razvan: I don't exactly how I can do this without changing CTP...
Om: You can instantiate more CtpSenders.
Phil: You can see it this way: you put a queue above CTP and the queue can have more than one packet in flight at one time. And it dynamically scales how many packets it has in flight based on where the node is in the tree.
Razvan: And I can make this on the same am_id, right?
Phil: Yeah, it's collection id. When does this matter... You are concern about remote nodes having more bandwidth than local nodes? This is like only in the second half of the tree.
Razvan: You can end up in this situation also like this: let's say you have a backbone provided by CTP and then you have some nodes that don't run CTP which connect to them. In this case you can end up with more local traffic than a remote.
[ A longer discussion about the semantics of send/sendDone. The link that Phil provided about this was http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-March/000555.html ]
