Net2WG/Notes/20060608

Rodrigo, Martin, Phil, Sukun, Arsalan, Joe, Om

Notes by Rodrigo. (Feel free to edit if you think I misrepresented something)

There was an initial discussion about how to share control bits across all protocols. There is a tension between completely composable protocols and more standardized headers. It is interesting for interoperability reasons to have the packet formats specified.

Standardizing control bits.

P: Where are we? Code freeze is tomorrow. What the status is in terms of testing?

S: Test Dissemination on Omega, 28 node test. Collection testing tried with two nodes, I had some issues: root was receiving packets, but there was a problem forwarding to the uart.

P: how so?

S: no packet coming.

P: I can take a look.

P: Anyone else?

O: upgraded nesc, there was a problem.

P: 1.2.5?

O: yes.

P: using tag test1 or test2?

O: test1

P: try test2

P: there was a bug. Once you forwarded a message you couldn't send properly. Rate limiting wasn't quite right. That's all fixed now. O: will try with test2.

P: Don't worry about mig for now.

R: will finish a little script to plot the topologies. I could only get mirage for tomorrow evening.

P: Testing strategy: small number of nodes at low rate, large number of nodes a low rate, large number of nodes at a high rate. ... (Rodrigo had to step out for a second, lost the remainder of this thought)

S: It would be great to have an interface such as RouteControl to collection. Could be helpful to see what's happening, like getParent, getDepth. R: I can add these, at least for the testing P: It will be nice to determine what level of exposure to offer users once this is working.

P: Talking about the code freeze. It is tomorrow, 06/09. My thought is if we can change the structure of things slightly. Adding a byte to the data packet: uniform control field over the two packet types. Would be nice that the packet that the link estimator generates itself uses a separate AM type: right now the routing engine is receiving packets it did not send.

Om: I committed a fix. I use a bit in the header to indicade whether it's the link estimator's own packet. R: a cleaner solution perhaps is indeed to use a different AM type for the link estimator's packets. As if it were its own client. this is better especially if there are many sources of packets using the Link Estimator.

Om: are the AM types standardized anywhere? P: No. I would suggest you use a lower number.

Om: Can I use 1?

P: Not 1. We can talk about this on email.

R: Phil, are you suggesting that we do something similar to the Internet situation with port numbers? There they "reserved" lower numbers (<1024) to be for defined protocols, and higher numbers for non-standard, user level, or ephemeral uses. We could do something similar, suggesting that if applications want to use their own numbers they should use something above 32, for example.

M: is there a single place stating the pre-alocated AM types? e.g., is it upstream collection, downstream, single-hop pass-through? at xbow we ended up defining at least 4 AM types for services, and a different one for data packets of those services. It's really helpful if these are defined in a single header file.

P: Currently in lib/net we use 13/14 for dissemination, 20/21 for collection. Rodrigo's comment of getting the lower 32 or lower 64 to be protected is probably a good one.

R: going forward it would be good to have a registry.

P: One thing: it'll be useful to put the link estimator header in a header file. The shared byte should be the first one.

O: If currently has addr, seqno, flags. flags should be the first.

O: keep the enumerations in the same file or in the header?

P: if they are internal, keep in the same file.

O: timer rate and table size are possible parameterization values, right now they are defines.

R: Playing Devil's advocate, do we really need to define this common byte for control? The packets that use the link estimator control byte are never the same that use the forwarding engine control byte. Even if each has its own header, they would not be duplicated.

P: Our implementation doesn't mix them, but it could. It is still possible though that unicast packets go through the link estimator. Of course, there are issues in that not all platforms allow snooping of unicast traffic, and writing the protocol to not depend on that is good.

O: Given this, do we need a bit allocation table somewhere?

P: Given we are not using the bits, we can do a rough partition: the first four bits are for the link estimator (telling how many entries there are in the footer), and the higher four bits are reserved for the forwarding engine.

O: Once we pre-allocated AM types, that goes into standardizing protocols as well.

P: once we solidify on that, BestCommonPractices TEP would be great.

R: Talking about TEPs, we should go and revisit the TEPs now we have the implementations. There should be TEPs for the interface of collection, dissemination, and TEPs for their implementations. Phil, are these the same types of TEPs?

P: These are to be documentary TEPs.

Martin: is there a roadmap for a TEP on fragmentation? Basically breaking large data items on sending and reassembly afterwards. Bulk transfer?

R: we haven't looked at transport issues yet

P: Sukun has some experience. This can be a very interesting direction to look at.

M: certainly need the underlying layers to be solid. It's probably useful for something in a few months.

P: next steps: Sukun, Om: working through some issues. Rodrigo: mirage next evening. Will check the uart thing today.

P: On another note, I met with people from SUN on the sunspot, an arm based mote with cc2420 they are developing. (...more detailed spec I missed). They are writing their own protocols. They have a full java environment, if we specify the protocols we could have them interoperate, they are quite powerful nodes.

Joe: you're talking about the reason people define standards. what's the motivation?

P: motivate sunspots to talk to motes.

J: are you trying to create another standard? Why not 15.4? that's the role of a stardards body.

P: They can interoperate at the data link level, can they interoperate at the network layer? They are implementing Zigbee.

J: What's the technical reason?

P: technical reason: they could interoperate. here's a non-tinyos platform interoperating with a tinyos device.

O: stargate does that

J: I can use tinyos in a mote to do that, use it as an interface card on some other platform.

P: The point is I was talking to the sun guys, this is interesting to them. They said: if you guys write down the protocol we can interoperate.

M: I think you are creating a standard of sorts, and making it interoperable. This is fine, since the net2wg is not influential in the zigbee alliance and vice versa.

J: There was strong pushback in [Expo (Chicago)] in having tinyos create a competing standard.

M: Zigbee is amoving target, it's highly complex, doesn't fold in basic knowledge that this community has. I can see you guys making the argument that this standard is lacking in different aspects. The motivation to implement and influence the standard is a valid one.

J: worried between the disconnect between industry and academia, and before going down the road of protocols specification, get more industry involvement. We live in our Berkeley centric world

P: this came up in emnets. david clark academia versus industry, as it related to the establishment of TCP as the defacto standard. If we build a protocol that works, and allows people to experiment, and becomes the defacto standard, that is good. We also have Martin, who can go back to the zigbee alliance and point out some aspects of the protocol.

M: that's not exactly how it works... :)

J: what's the goal of this group. create a standard or not?

O: create a protocol that works and write it down. If others want to use it, great.

M: Are you guys going to zigbee openhouse next week in San Jose?

P: can you send info to the group?

M: sure

P: this is a very good discussion on what the role of this group is as it relates to standards.