Net2WG/Notes/20071012
Net2WG/Notes/20071012 Meeting Notes
Agenda
* Link-layer SP * 4B status
Participants
* Phil, Stanford * Arsalan, Berkeley * Om, USC * Rodrigo, MIT * Mike, JHU * Razvan, JHU
Discussion Notes
Om is joining the phone-call.
Om: Maybe we should start with the link-layer discussion.
Phil: Sure.
Om: Can you summarize the things? Are you talking about the email from David?
Arsalan: Yeah. The configure event is all great and now we were talking more about moving to the implementation. I was arguing with Phil, what I said in that email, is that the Policy Manager is a good place to do that so instead of modifying the protocol to make him make the call you can define a policy with the Policy Manager. The place where we ran into a little of a debate was, Phil said what happens when the protocol want to do this and this and this and needs to do the call specifically. The Policy Manager is customize knowing you have that protocol running on top and if the protocol wants something different than the default it ca specify that. Phil argument was that this is broken because if you do that the Policy Manager which is design to let the link abstractions to optimization but this will not be possible if you do all those individual calls. My response was that the stuff they are calling like security, acknowledgments, sleep interval has nothing to do with optimizing for fairness algorithms.The Policy Manager is just a source of information so if a packet says this is what I want I don't see any problem with it where Phil argues what about transient power and how you maintain fairness. That is basically where we were.
Phil: The issue here is that I feel the Policy Manager is becoming this nebulous thing and you need to build it. I don't believe in the idea of completely general that you can do anything. It's not going to be able to do be able to do things. You need to find what things you want him to do and make sure it does them well. When you don't know what problems you solve you come up with ways to solve problems. And if you don't know what the set of problems are then you solution will be so general that it will not be helpful. The whole reason for the configure event is that it will not require per packet state. The Policy Manager or the component will be signal with the configure event to figure out what to do and you'll not have to keep all these metadata fields. But if you want to let all these layers to also say all these things on a per-packet basis, as they do today, yet the Policy Manager can step in and say do these things when you haven't told me what to do, so you'll need the state maintain per-packet because you can still to things per-packet, but you also have to signal the configure in some cases. You end up trying to get the best of both worlds and you end up with the worse of the both worlds. The whole purpose of the configure event was to move the need of per packet metadata. Right?
Arsalan: Yup.
Om: This is the implementation perspective. About usability perspective.. What I was doing two weeks ago is to use the duty-cycling so I have to search for all the places where send calls are been made and insert the proper calls and stuff like that. So there is also this usability aspect as well.
Phil: Yeah, good point! Arsalan, you can also say: Ha-ha! The configure is the perfect place for the Policy Manager. There is this single thing which can accept a bunch of parameters and also signal the configure event to be the actual caller for stuff that it doesn't know what to do about. You can also make the Policy Manager decide which packet to send next and ask the right guy what configuration to do. To make things work in both ways it's a little tricky.
Arsalan: I got you. Fair enough...
Phil: The Policy Manager should have the policy if you make it distributed it's going to be hard to make claims about anything.
Arsalan: I get you. You're right.
Rodrigo is joining the phone-call.
Om: So what is the conclusion? Is the configure event a good step for what the Policy Manager is suppose to do?
Arsalan: Yeah. I think that's it. The configure, the way I saw it, defines a subset of the policy so it will be an integral part of the Policy Manager.
?: Ok, so what's the next step here?
Om: Phil, I saw the conversation about threads in TinyOS, maybe we should do that king of API stuff?
Phil: Oh, yeah. Part of me thinks that Arsalan should just go and built it. If he is the one that will do the work he should do the kind of work he wants to do. We don't need a committee. The API for the thread stuff was different. Arsalan tossed out lots of interfaces before... Working for it for 3 weeks and then talking will be more useful than talking about interfaces. The more time you spend building it, the more entrench you get. If you spent 3 months you don't want to rewrite everything. But on the other hand, the more time you spend on it, the more concrete the issues will be. There will be some sort of sweet-spot... Arsalan's judgement will say when that is.
Rodrigo: I have a question, the devil-advocate kind of question: If Arsalan goes off and built this, who is going to use it?
Om: I'll use it because I need to set the duty-cycle parameters for the packets that are send out.
Razvan: If all you need is that what don't you use some sort of wrapper?
Om: I could... but the question was if I'm going to use the Policy Manager.
Rodrigo: The Policy Manager requires more infrastructure to exists... like SP... almost.
Phil: No. I think the Policy Manager will only actually need 2 things: first it needs to handle the configure event and then it needs to poke the AMQueue in the sense that it picks which packet will be sent instead of the currently round-robin approach.
Rodrigo: Then it becomes more reasonable and interesting I think. Instead of requiring all this thing to be built it will be something simple to experiment.
Phil: Yeah, basically the Policy Manager will decide which packet will be send and how to configure the settings for that packet.
Rodrigo: And it will forward the current AM, right?
Phil: You'll might need to change a little some components but you could pretty easy have just to include a certain directory to have the Policy Manager.
Rodrigo: I think that make more sense.
Phil: Does it make sense Arsalan?
Arsalan: Yes. Now my question is: we are building this Policy Manager agnostic to whether a link abstractions exists on not. This is what you say?
Phil: Well, there is a link abstraction today and there are a lot of things you can do like packet acknowledgments and the C2420 specific things.
Rodrigo: To make this more concrete could we select some scenarios, a couple of scenarios, maybe two, in which we don't need a Policy Manager and say, here are the two protocols that are sharing this, this is our goal, this is where a Policy Manager would do something. 'Cause is quite fuzzy for me right now. Sorry... Then it would probably guide, whatever the decision or discussion we have, much better. Do people have some scenario in mind?
Phil: From the packet scheduling stand point I can give you a very simple scenario: I have protocol A and B and we want A to get the lion-share of the channel when needed. This is very application specific thing.
Om: It could also be: I have CTP running and I have the routing engine generated traffic, which is control traffic, and I have data traffic. Can I play with this two to make sure that my control traffic gets through?
Phil: Or has higher priority. David Moss gave this example: hey, in my application I definitely have packet priorities, I want some packets to get ahead of others. Currently, to do that in TinyOS you need to pull apart o lot of stuff. AMQueue is kind of limiting. Everything is fine for for just a basic policy but people want to be able to build more application-specific things. More fundamentally, you can imagine wanting to be able to change the scheduling order of packets... Policy Manager being a way to abstract that. Arsalan, about the configure event, can you think about some scenarios where the Policy Manager would give a tangible benefit?
Arsalan: It would be meaningful if you have two kinds of traffic but the Policy Manager can also be beneficial when for example running the same CTP library on a normal library and in a low-power setting by simply changing the policy with the Policy Manager.
Rodrigo: Would be outside the scope of the Policy Manager to do the batching of the packets for a certain destination or would it not?
Arsalan: I think that is outside the scope of the Policy Manager, I think that would the link abstraction.
Phil: Really?
Arsalan: The Policy Manager dictates the policy, the mechanism for actually doing it is the link abstraction. High level: what I want to do is the Policy Manager, how you do is the link abstractions.
Phil: C'mon... Show us the line? If batching packets is a link abstraction then that's immediately packet scheduling? Right? Then link abstractions are responsible for packet scheduling.
Arsalan: Yeah... When I initially proposed the Policy Manager the packet scheduling was handled by the core and the Policy Manager was specifying what rules or constrains to be used.
Phil: How would you do that?
Arsalan: For example the fairness argument: if I say 70% to go to protocol A and 30% to protocol B and when I'm figuring what packet to send I'll use this weighting scheme to determine who gets to send it. It's not the Policy Manager to determine who is going next but just to specify the general rule.
Phil: Who determines who goes next?
Arsalan: The packet link layer...
Phil: I'm just trying to understand what kind of interface you envision between the two such that the Policy Manager knows the 70-30 and then can control the link layer scheduling to make sure that is happening. I don't quite understand...
Arsalan: I guess the line can be shifted. Initially I imagined the Policy Manager being a passive entity, you can stick in a module that would say here I my requirement, I want a 70-30 split but I'm hey, I'm not going to enforce it. The enforcement and the actual use of that information as part of the packet scheduling would be done by the link abstraction itself. Now, if you want to move that capability over tot the Policy Manager so that it would be transparent to the link layer that's another way of doing it. You just need to decide which one.
Phil: I agree. I just want to understand. So the Policy Manager has rules and requirements but he needs a way to express them to the packet link layer and I'm trying to understanding what the interface would be. Maybe that's the core challenge in figuring out what the interface would be and that might be the part that will fall out when we start building it.
Arsalan: Yes... That's a way of looking at it. 'Cause I don't have a clear answer for that right now.
Phil: Ok.
Om: My question is: do we expect David Moss to be involved in this? I think it should be.
Phil: I don't know what he thinks.
Om: Arsalan, what do you think?
Arsalan: I think his input is pretty valuable. I kept up with things to some extend but most of my development was in TinyOS 1. Having him at the lower level would make the integration tighter and smoother. Obviously, it has to be something he is willing and wanting to do.
Phil: My only last though for the effort is keep wary of the code size. If you have a very simple policy, you want to do what AM does today, doing so should not introduce extra ROM. Clearly, having a complex policy that ends up taking up code it's ok but doing really very simple things should remain lean so that the full packet layer should become the limiting factor for small platforms.
Om: CTP 4B updates. My task from last time was to do some experiments on our testbed here and look at the usefulness of the unidirectional estimates and the white bit. The conclusion based on the data that I have is that they are not that useful. So this is TelosB motes, CC2420, experiment was done on 5 nodes.
Phil: So this is on Tutornet. On Mirage was very helpful but on Tutornet seems not to be helpful.
Om: It could be even harmful. Some further updates: this morning I did two settings, one is the 4bit estimator and one without the white bit. I believe the results are similar. I didn't have the chance to pull the data yet. I'll sent it out shortly.
Rodrigo: One difference in the testbeds is the density, right?
Om: This is less dense, right?
Rodrigo: Mirage was pretty dense, we number of neighbors could get up to 25-30 vs approximately 10 when is limited and that made a big difference in the tree formed.
Phil: Because of the NSDI I haven't follow all the discussions about what was going on and probably other people are also in the dark. Can you please give some overview about what do mean by "seems to be harmful", under what condition, what are the phenomena that was observed and that kind of things.
Om: There is not a whole of a lot of conclusions yet but one we know is that is not clear what we want to show in that topology figure. What is that figure number? The figure in which we saw that with unidirectional estimates the in-degree is high... probably there is some error in that figure.
Phil: Why is an error in that figure?
Om: Because we are not even sure if that is the right graph we want to present. Our conclusion at that time was that if you have a constrained neighbor table size it will limit the degree. It turns out that you can form an estimate and you can be evicted from the neighbor table and you can still maintain that parent. So you can actually see a high degree in the experiments I did even with a limited neighbor table size.
Phil: Oh... you say that because of the way it works, if you are ever in that person's table you can form an estimate ... and even if you are evicted it will continue to work.
Om: We saw that phenomena on Tutornet. My hypothesis is to start when the churn is high... because the churn was much lower than we observed on Mirage. Rodrigo, do you remember? ... Anyway, if the churn is lower then it obviously it limits the degree.
Phil: Right... so if you need churn then you have to assume a certain level of churn.
Om: That is the only concrete thing that came out of this... Rodgrido, do you have anything to add?
Rodrigo: In my view, the concrete thing that came out from the analysis is that the limit is not that hard or tight as we have previously thought but I think is still obviously there. It stills constrains the degree somewhat.
Om: But is not as dramatically as we thought it is, right?
Phil: We are looking at a very specific experimental setup. The question is: what would be the right thing to do? Let's say you are not sending any data packets... and you are sending beacons... and you are hearing beacons from this other node but he doesn't seem to report what number of beacons he is hearing from you. Should you continue keeping that node as your parent?
Rodrigo: Eventually the quality will go to zero, right?
Phil: Right. The question is: what if you don't have a stream of data packets? Or what about alternative parents? If it works in this particular setting it doesn't mean it will always work. So the fact that failed in one particular setup it doesn't mean it always fails.
Om: But the conclusion in the paper and that diagram were based on the same settings...
Phil: Different testbeds, different setups.
Om: By experimental setting I mean the traffic pattern.
Phil: Just because it succeeded on Mirage on a particular packet rate or traffic pattern it doesn't mean it will succeed on Tutornet with a different one.
Om: Correct... I agree. So that's one... which is maybe we need to re-config that figure or better explain it... maybe it's a more nuanced explanation, maybe that's the change. Another thing is getting a lot of duplicates, retransmissions and low delivery ratios. We are talking about 90%, 90 to 95%, nothing like 99% before.
Phil: This is from the head of the tree of the 2.0.2?
Om: This is, I think, 2.0.2.
Phil: I checked in that bugfix which causes queue drops.
Om: I need to check which one is it.
Phil: So there is a bug, which I fixed about a week or two ago, which was that under some duplicates suppression cases you would leak a packet. With lots of duplicates suddenly your queue depth is 2.
Om: Ok... I need to check.
Rodrigo: On these 95% cases, what is the cause of the drops?
Om: I haven't look at that.
Om: Let's see if there is anything else... So that was channel 26... the experiments I did this morning were on channel 16. That's all my updates I think.
Phil: These are really good results because it shows that it works great in one environment but it's not working in another. There is something on Tutornet that is causing problems and the question is if there is some way for the protocol to address that. I'm sure there are a lots of other place like Tutornet. One difference is the 802.11 traffic. This might be a good experiment to run: there is RssiSample application in the tinyos-2.x-contrib which generates 1kHz sample of the observed RSSI. Run that application on some of the nodes and we'll see how the interference looks like.
Om: You can compare with what you seen somewhere else.
Phil: I have tons of samples from Mirage. I can show you how Mirage looks like. The fact that these nodes are plugged into Stargates that are 802.11 that could be a big deal.
Om: Yeah, it could be.
Phil: ... or it might not be. We don't know. Running that app will give you a good way to figure it out. Star figuring it out...
Om: So the plan for me is to look at that bugfix and send looked at the results from this morning. That's my plan. Anything else Rodrigo?
Rodrigo: Not on this side.
Phil: Kaisen is making some good progress on dissemination. I'll start asking him to call in. He's shooting for IPSN. The high level idea is to disseminate lots of different objects and do it efficiently. One of the latest breakthrough was using the Bloom filters.
Om: Ok. Maybe we should end the net2 part of the meeting.
