Net2WG/Notes/20090206

From TinyOS Wiki
Jump to: navigation, search

Contents

Net2 Meeting Notes from 02/06/2009


Agenda


* Sponsor for telecon
* Point-to-point communication

Participants


* Kaisen, UCSD
* Om,  USC
* Mike, JHU
* Razvan, JHU
* Phil, Stanford

Discussion Notes


Om: Intel might not be able to sponsor after a few months. If we cannot find a new sponsor we'll have to talk less often or maybe switch to Skype. Any chance for JHU to sponsor it?

Razvan: I don't know. We'll have to ask.

Om: Ok. We'll ask Phil also. Perhaps Stanford could do it. You guys got the codes till beginning of May, right?

Razvan: Right.

Point-to-point communication

Om: Did you give gave it some thought in terms of it this should be out next focus? God idea, bad idea? Any thoughts? If you look at the mailing list there are people that would use something like this.

Mike: I think it would be a good idea.

Razvan: I think there are two directions: one is to come up with a new way for doing p2p and the other is to make CTP detect where is everybody and do some sort of source-routing. In this second case all the p2p traffic will go through the basestation, like in a access-point type of communication.

Om: This is the way Koala works, right?

Razvan: No. The most similar thing I think would be the Berkeley ipv6 (blip).

Om: But Koala would potential also do it, right?

Razvan: Yes. That is true.

Om: I don't know much about ipv6 yet.

Razvan: That might be another direction we should consider more seriously. Moving to ipv6 might be the thing we'll have eventually do anyway. We also didn't try it yet. But we will.

Om: Let's put that aside for now and let's go over Tenet and Koala for now.

Razvan: Let's hear Tenet first.

Om: So in tenet the basestations, which we calls masters, does not have the ability to send a packet to a specific node. This is because the data that is sent by the nodes sets up a gradient in the network that the master can then use to reach the node.

Razvan: How persistent is the state?

Om: In out case is pretty persistent. It can be updated, but it cannot be flushed it.

Razvan: So you can either have a bad route and the node is node is node there or is a fresh one. Right?

Om: We do have timeouts but they are not very aggressive. If you have some periodic data pattern then you could be be more aggressive.

Razvan: If a node moves from one node to another and creates a new gradient some pieces of the old one might still be in the network but this will not disrupt the new one?

Om: Right.

Razvan: and for each p2p communication we'll have to go through root?

Om: Right. Otherwise you'll end up using some of the stale routes.

Om: In terms of integration, we already have it. It's a simple extension to CTP. We are mainly using it to sending acks. The gradients are maintain the forwarding engine. There is a bit that indicates if the packet is upstream or downstream. If it's and upstream the CTP routing is used, if it's a downstream then the gradient is used. In terms of software engineering, I haven't give much though yet. The changes are directly in CTP for now.

Razvan: One more question: how is the state kept at the root? Is on the mote or on the PC program?

Om: Master only knows about the next hop in term of its immediate neighbors. In our implementation this happens on the PC. The basestation is a transparent bridge. The PC is generating the CTP beacons.

Om: Now the disadvantages: this only works when the basestation sends data as a response for a packet sent by a node.

Razvan: It would be great to have this in the main tree but avoiding code duplication.

Om: Yes, it should be possible. Conceptually this can sit on top of CTP by using the Intercept mechanism. Let's hear about Koala.

Razvan: So, the most importat part of Koala that relates to the p2p is something we call FCP, Flexible Control Protocol. This consists of a small header that packs as much information as possible in order to make possible as many things as possible. What we want to be able to do is source routing and then, after a route is already established, use some small identifiers to push data through it. So the initiator (usually the basestation) will send a packet that will contain the path (hence smaller payload) while the subsequent packets, either from the destination or from the source, will be able only have to pay the price of a few bytes and not the full path. This is basically it. We use this to make the basestation query its one hop neighbors and then use the collected information to do the same for 2nd hop and so on. All the logic of picking a path is on the PC. That's the place where we have all the neighborhood information. Because you know the whole network there is a lot of flexibility in finding paths.

Om: What if a node has 50 neighbors?

Razvan: After a wakeup we have some code that will send some beacons to allow the nodes to learn about each other. The space in the neighborhood table is limited so a you will not be able to remember all 50 nodes. It's probabilistic so for sch dense and big network the nodes missing from one nodes neighborhood table should appear in somebody else's neighborhood table.

Razvan: From p2p point of view: if you know the path to the node you want to talk you can do it. On top of FCP we several abstractions: unrealiable datagram, reliable datagram, unreliable stream and reliable stream. We never actually implemented the reliable stream because we didn't really need it.

Om: Before we get into that: how often do you wake up the nodes? What's you model?

Razvan: We wake them every 6 hours. We envision do it less frequently but we started with this one and stuck with it.

Razvan: About the abstract: as I said we don't have the reliable stream. We didn't do it because we didn't really need it and because is also a little more tricky. FCP does have provision for it though. One idea is: if we didn't need reliable stream we could go back and redesign the system without it. This will make things even more simpler. One more thing: all the state in the network is soft-state. Everything will timeout in a few seconds if there's no activity. We have signals that tells the upper layers when this happens.

Om: So what is the overall model? A mote has to talk to the basestation at least once?

Razvan: No. A mote can talk to anybody if it knows the path to it. This is tricky for the nodes in a network but it's easy for the basestation because it has all the state. In order to implement p2p the basestation could periodically poll the nodes and tell them how to reach the nodes that they are interested in. Or, as in Tenet, it can relay the data for them.

Om: Is there a benefit of you model?

Razvan: It is for a network in which the node will never take the initiative of talking to the basestation. They will always act as service providers.

Om: They will require less memory then in Tenet?

Razvan: Right. And they will sleep more. I think is good that Tenet and Koala deals with two different scenarios that people might find useful.

Mike: In Koala we can also make the basestation tell the node: here is the path from you to me. Use it if you want to reach me.

[Phil joins]

Om: We were talking about p2p communication in Tenet and Koala. Tenet uses gradient while Koala is using source routing.

Om: Btw, Phil: Intel might not be able to sponsor the telecon after a few months.

Phil: We could still get conference calls but the downside is the numbers will not be toll free. If the people can call long-distance then it should be fine. It's a bigger issue for european participants.

Om: Back to p2p. There are also the solutions like Tymo and TinyAODV that don't use trees. That would be another approach.

Mike: Are we going to pick one p2p protocol?

Phil: Let's back up. Tymo and TinyAODV do the non-compact way. Hence S4. And then you also have hierarchical routing which will give you log(n) routing state but unbounded stretch. But there is a difference in unbounded in theory and unbounded in practice. Theory is based on any type of graph topology and wireless doesn't follow that. The IPSN 2009 paper shows that is around 1.1. So there are lots of way to do it but there are not that many implementations.

Om: We were looking at things that already have some implementation.

Phil: Here at Stanford we have an S4 implementation.

Om: How does it work?

Phil: Pretty well. It's in contrib. We also have there BVR. Both for tinyos-2.x.

Om: In BVR, how complicated from user's perspective is to use node IDs as routing destinations?

Phil: BVR does not have a lookup server. So it doesn't work. That is true for all compact routing schemes.

[...]

Razvan: I have two more things to ask. First: there is this logging mechanism in CTP. When I was benchmarking the LPL/LPP I did in a more simpler and global way. That I did I followed the printf way but I replaced the format string with some fixed fields: a local timestamp, a sequence number, a string tag and then some 32-bit numbers. The numbers at the end can vary in a small range (up to 6 depending on the packet size). This was something that proved to be very useful. I used it to print stuff like number of packet sent and received, number of beacons, acks, etc.

Phil: How do you arbitrate between those identifiers?

Razvan: I don't use identifier but a 12-byte string. The API is something like: logger("tag"), logger1("tag", number1), logger2("tag", number1, number2) and so on.

Phil: I would not call it a logger because we have the Log interface for flash.

Razvan: What would you like then?

Phil: I don't know.

Om: So the difference from the CTP logging is the tag?

Phi: You also have a fixed number of counters.

Razvan: You can use a logger1 if you only have one counter to sent. It's always 32-bit so it is somewhat wasteful. One advantage is that you don't have to wire to some components to use it. If I want to log something in the radio stack I can just call I there.

Phil: Oh, so it's a C functions. Very bad.

Razvan: Why?

Phil: There was a long discussion about this some time ago. 2004-2005... It was about having some utility function that don't require the wiring interface. The problem is where the code lives. In order for a component to be loaded it needs to be named. That's the only way code if brought into the system. So it has to be in #include tos.h. The code elimination will take it out if it's not used but you still have the issue of hidden dependencies. If somebody leaves by accident a logger statement it will mean you'll pull the serial stack.

Razvan: I have a way of disabling the logging. There is a master switch.

Phil: Where is the master switch?

Razvan: A defined for LOGGER_DISABLE for example.

Phil: The conclusion of some long discussions was that the code that is included should not be done using #defines but rather using components. You can do constants with #defines. Things gets tricker with CC2420 though where breaking in components would be weird.

Razvan: How about this: there is a lib/logger directory and if you don't include that you don't have any logging.

Phil: So why not printf?

[...]

Phil: Let's talk about this next time.