[net2-wg] notes for march 2 call

Thu Mar 2 09:52:51 PST 2006

Notes attached and inline.

Notes for 3-2-2006

Rodrigo: Joe, do you want to talk about Boomerang and its implications
for TinyOS2, net2, etc.?

Joe: I can try. Question 1: Should T2 do AM or SP? Answer: No SP for
now, so go with AM. I think that AM is OK for single packet stuff, but
SP is good underneath. But now I have SP on the CC2420, Drip, Deluge,
Drain, MultiHop, etc. All of this is low power, etc. You can compile
any 1.x code.

Rodrigo: How does GenericComm work?

Joe: Adapter above, takes a standard TOS_Msg, turns it into an
sp_message, etc. GenericComm allocates a few sp_messages.

Phil: So GenericComm can have multiple outstanding?

Joe: Yes. We also have a simple SendMsg as well as a SendMsgAdvanced.
In this implementation, you can't access the sp message struct.  You
pass flags, and then you access fields through the send interface.

Rodrigo: So the send has all the parameters needed to fill the struct?

Joe: Yeah. E.g., one has four parameters, another has a few more. If
you download the Moteiv RPM, there's documentation describing all of
this stuff.

Ohm: The documentation was really helpful. What's the situation with
the license?

Joe: The Apache basically says that if you include this code in a
product, you have to include a nod to Moteiv in the end-user
documentation. Rob is working with the alliance WG to figure out the
licensing situation. Download the code and have fun with it.

Rodrigo: Apart from putting code up there, would you be willing to
put time into changes to make it part of net2?

Joe: To a limited extent. My time is really limited. You are allowed
to take the code and modify it.

Ohm: High level question: how is this implementation is different than
others. What are the differences?

Joe: We have a lot of experience using the interfaces in real world
stuff, but that doesn't mean they're not going to evolve.

Ohm: So this is as much an interface as an implementation.

Joe: Yeah, we have timestamping, network interfaces, time synch, etc.

Ohm: So we should think this is a completely different SP.

Joe: No.

Rodrigo: What does it mean to have timesynch? There's information
carried from the application all of the way down, in the form of a
flag?

Joe: There's a flag of whether you want to timestamp, like the urgent
bit and the reliability bit. There's a new interface, SPUtil, that has
a bunch of utility functions that were sorely needed. Consider this
version 2, started from scratch. I've been telling the Berkeley people
to do that, but they wouldn't listen to me.

Phil: Flags are runtime, not compile-time. What's the motivation?

Joe: You're going to have multiple versions, so you're going to have
to do versioning numbering. You can request acks on a per-packet
basis.

Rodrigo: Collection and dissemination status?

Gil: Found a few bugs in dissemination, should be checked in by the end
of the day.

Phil: I can read over it on Sunday.

Rodrigo: There's a question of multiplexing. Multiple AM types:
control traffic, data traffic. But then you have multiple trees, a
collection ID, and you choose which one you route up. And if you want
multiple applications, there's app-level dispatch as well.

Phil: That's another level of dispatch. Is the extra byte worth it?

Rodrigo: There are some apps that need multiple trees. So we need
the tree dispatch.

Ohm: Do we really need the multiple application?

Rodrigo and Phil: Yeah.

Rodrigo: It seems clear that we need app-level formats. The tougher
question is whether we need multiple trees. I think there are
definitely situations when you do: drip vs. mint route.

Phil: It's just a question of where the dispatch is. At AM, at the
tree, at a tree payload.

Rodrigo: What are people's opinions on the need for multiple forests?

Gil: Are you thinking anycast or "pick-one"?

Rodrigo: Anycast within a forest.

Gil: Ah, multiple *forests.* That almost sounds like completely
different routing implementations.

Phil: But BVR has multiple forests.

Gil: Ah, the beacons for BVR. So what's the cost?

Rodrigo: Having a forest is no cost. Having *multiple* forests is a
cost.

Gil: Is there a way to say "send up any tree?" Does Send take an
argument
for which tree?

Ohm: Yes, it takes an argument.

Phil: Sending up any tree is an interesting idea. That's an anycast
over the trees...

Ohm: How do nodes discover the destinations in that case? The
applications?

Rodrigo: You mean which forest to send the message to? That would be
wired. Configured at compile time.

Ohm: So you can't materialize a forest on the fly.

Rodrigo: You can always create a new forest, drop down a base station.

Gil: But how would you ever send data up this tree if it's
parameterized?

Phil: You could theoretically wire to the entire parameterized set...
but
if a routing table is independent of the set

Kyle: We've gotten a bit off topic.

Rodrigo: A forest is just anycast to any root of a given tree.

Kyle: So the question was never which forest, but which tree?

Rodrigo: No, anycast. So if you send up a forest, it will end up at
one of the roots, you can't control. But what happens if you have
multiple independent forests? The question is whether we need them.

Kyle: Right, and I haven't heard a good reason for them.

Rodrigo: Well, there's BVR and DCS. But they're not collection.

Kyle: So it sounds like two motivations: 1st is research platform, the
2nd is practical. It sounds like we have #1.

Rodrigo: I would say then that adding multiple forests adds too much
complexity then we should leave it out for now.

Ohm: Joe, how many do you use?

Joe: One forest. We collect, nothing more.

Rodrigo: We have 5 minutes, sounds like there's consensus.

Phil: For initial implementaiton being a single tree?

Rodrigo: Yes.

Ohm: So there will be one level of dispatch, at the app level.

Rodrigo: Yes.

Rodrigo: So I am going to invite Sukun, that was the consensus.
Anything else?

Joe: On dispatch, in our distribution there's a generic dispatcher.
It seems to work pretty well for having nested AMs.

Rodrigo: So you specify which level?

Rob Sz: So the idea is simple. I want a dispatcher on a message type.
"I want to be dispatching on the field of this name." It creates another
interface.

Joe: Could come from any networking protocol. Could also work well
with Drip.

Gil: Sounds cool.

Rob: And it is available under apache.

Rodrigo: OK, sounds good, goodbye everyone.

Phil

-------------- next part --------------
Notes for 3-2-2006