[net2-wg] Net2-wg notes for April 13th, 2006

Rodrigo Fonseca rfonseca at cs.berkeley.edu
Thu Apr 13 10:22:36 PDT 2006


Net2-wg notes for April 13th, 2006

Participants: Phil, Rodrigo, Sukun, Kyle, Om
Notes: Phil and Rodrigo (minor)

----------------------------
Rodrigo: Collection is the blocking item.

Phil L.: I think a few of us have a clear period now, SenSys has passed,
maybe now is the time to sit down and do it. I can lend a hand.

Om: I've started working with TOSSIM to get a link estimator up and runnning.

Rodrigo: The conclusion has been that the link estimator should not
generate traffic. Instead, it puts additional bytes in the packet.
Different link estimators can send different sorts of data.
I think this decomposition is important, as it looks like there's
a bit of recent research in link estimation, and so we want to
remain flexible to future efforts. Any comments?

Om: That sounds right to me.

Phil L.: It sounds like you're putting a layer inbetween the data link
and network layers. It's a layer 2.5. It can have different headers, etc.
Put in that light, is this a good architectural step, to introduce

Rodrigo: How do I know how to parse the packet? Depending on the link
estimator, I'm going to have different packet formats.

Kyle: Another approach is to squish it into the routing protocol.
That way, the data link identifier specifies both.

Rodrigo: That's what MintRoute did.

Kyle: I don't think we want to go in that direction.

Phil L.: If this were a pure layered approach, then 2.5 would have
an identifier that specifies 3.

Rodrigo: The current TinyOS approach is that AM identifiers are
private to an application. Unless we want to consider interoperability,
where you have separate patches that work together, this would require
some kind of IANA structure.

Phil: TinyOS has resisted doing this so far.

Rodrigo: And once you specify the active message space, it's hard to
manage the global namepsace, especially if they represent combinations
of things.

Kyle: I don't see a compelling case for interoperability. A more
important issue is this clean layering. Can anyone think of any
other reasons, besides saving space in packets, why we don't use
a strictly layered architecture.

Phil: What do you mean by layered?

Kyle: Each layer has its own dispatch identifier.

Phil: The reason historically was saving bytes. E.g., lib/Route.

Kyle: I think that a clean layered approach is much better. The earlier
approaches seem to have been some early optimization attempts.

Phil: So what can I do, to make this collection effort happen?

Kyle: If someone would organize the effort, that would be great.

Phil: OK, I can do that, and lend coding help where needed.

Kyle: We've also added some new people. Do we want to incorporate
them into the effort?

Phil: Is this Mythical Man Month, or is it going to be good help?

Sukun: I can just help Rodrigo a bit on the side.

Phil: Martin Turon, also in the TinyOS 2 WG, is the chair of the
zigbee working group on bringing zigbee to wireless networks. On the
t2 wg, he shares a view with Joe that we need zigbee on sensor nets.

However, the conclusion at tech exchange, and telecons, is that there
isn't a lot of interest i n the working group of actually doing it.
Zigbee 1.1 is coming out, there are some issues, not a lot of
interest. Seems like people would like to see this happen but no one
is really willing to do it.

It can be a good direction for net2 to go down to protocol
specification, go down to logical specification. In OSI terms, we are
doing service and api specification, but not protocol.

We can specify the state machine in the protocol, the logical packet
contents, the physical header layouts. this would allow different
implementations to interoperate, as well as things as tinyos packet
sniffers, for example.

Rodrigo: There are different levels of specification. We've specified the
service and the interface, but not the state machine, the logical wire
format, or the wire format itself.

Phil: In the OSI model, we've specified the Service and the Interface,
but not the Protocol. Is that step something which people are interested
in? Kyle and Om?

Kyle: I think it's the right thing to do.

Sukun: Once we have a specification, then we can verify that other
implementations are interoperable.

Om: I'd agree with what Kyle said.

Kyle: It will be interesting to see the line of what is specified and
what is not specified is the same or different than the Internet.

Rodrigo: A couple of paralllels with TCP. TCP does not specify how
congestion control works. It just says "there should be some." There
are some header fields that are options, and they are specified by
IANA and such. One thing is that the header format changes by these
options, just because they need different information. The other
parallel is interoperability. When you start creating a new
TCP flow algorithm, one thing you have show is that the new algorithm
is TCP-friendly, in that flows using the two different algorithhms
will cooperate in the network. So two levels of interoperability,
one being between end hosts, one being in the network itself.

Phil: So the IETF is OK with new TCPs that don't interoperate.

Rodrigo: No, they need to play nice.

Sukun: Sensornets are more a closed system. We care more about
how we interact with layers than interoperability.

Rodrigo: So it sounds like specifying the protocol is important.
We don't know exactly how we want to do so, how tightly we want to
do so, but that's something we're going to need to explore.

Phil: this makes the net2-wg different. t2: is mostly concerned with
interfaces. alliance: how to get money, contributuons in time, effort.
net2: protocols: interfaces, next level, interoperability, etc.

It will be interesting to see where the fine line of specification lies.

Rodrigo: So, just before we part, it sounds like Arsalan has been
approved. I'll let him know today, and we can start coordinating
collection.

Sukun: I wonder if I can volunteer for protocol specifiction.

Phil: That sounds great. You can read what people are coding and
try to describe it, that will be an excellent check on "that's not
what I meant to do!"




More information about the net2-wg mailing list