[net2-wg] Meeting notes for 2006-06-08

[Rodrigo Fonseca]

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 Spots 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.