[net2-wg] Meeting Notes 01/12/2006

[Jonathan Hui]

Active Messages and Virtualization

Phil: In TinyOS 1.x, there's a send queue and there wasn't much
visibility into it. Is it a show stopper if we don't provide much
visibility into the queue?

Om: We build our own queues. Important to have feedback.

Rodrigo: Important to have a queue (e.g. BVR), but didn't have to
interact with other protocols at the time.

Phil: There's a queue and a sender gives you a single entry on the
queue. Can incur some congestion due to queue length, but then
requires keeping other state like time. Om, how is the information on
the queue critical?

Om: Give feedback on how fast to send. Change rate based on queue
length.

Phil: If only time notification is if queue is full, it might be too
late.

Om: Yeah.

Phil: Important to know depth of the queue or where the packet is in
the queue?

Om: More important to look at the size.

Phil: This is a very strange queue in that you only have one entry.

Om: Any other uses for queue size? Maybe allowing the lower layers to
optimize for certain things. Possibly like the batch mode for some
radios. Can make it easier for the lower layers to optimize.

Phil: This is similar to where SP goes, giving information on how many
packets with futures. Seems like there's consensus: If there is a
queue from the data-link layer, it also needs to have info (e.g. get
queue depth). These things are pretty cheap.

Om: These things are important.

Gil: Cost is relatively low, so put them in.

Phil: Position of packet in the queue can be non-zero cost. Either store
state for every packet or search the queue.

Rodrigo: What is the real use of knowing where your packet is? Can
infer this info by querying queue depth before submitting packet.

Gil: If there's a different policy on the queue, then just knowing
queue depth may not be enough. But still can't think of a reason why
knowing queue position is important.

Phil: Consensus on needing to know queue depth, knowing packet
position is more questionable.

Om: Just knowing depth might be enough.

Rodrigo: Idea of virtualization can be an approximation of fair queueing?

Phil: Purpose isn't as much of fair queueing rather than providing
isolation. But does impose a form of fair queuing.

Phil: Consensus is that virtualization is a good thing, need to know
depth of queue, and unclear whether other information is required.

Jon: Could possibly use arbiters to provide the queueing.

Phil: Is virtualization the way to go? Or should it be physical and
shared like?

Gil: In favor of virtualiztion.

Om: What kind of control messages can it allow?

Phil: Policy of who gets the resource next is outside of your control.

Om: Not much different from how it works now (i.e. using queued send).

Phil: Consensus is on virtualization.

Rodrigo: Important to also swap out arbiters.

Phil: Does a client get more than one entry in the queue? Able to
specify how many spots in the queue at compile time?

Gil: Can make it an argument to the generic. And essentially put
queues on top of the data link queue.

Dissemination

Phil: Checked in some code for maintaining dissemination timers and
other building blocks. Do other people think we *won't* have working
code by this Sunday?

Gil: Yes.

Om: I agree. Have some discussion, but no where close to putting out
code.

Phil: TTX is on February 10th. Plan is to start filling in rest of
code over the weekend. What is a reasonable time frame?

Om: Thinking that 2 weeks is about right for collection.

Gil: 2 weeks is also a reasonable time frame for dissemination.

Phil: February 1st?

All: We agree.

Collection

Om: Undecided on the exact interface name and the actual
implementation (functional decomposition). Thinking that it should
look something like MintRoute. Most of it should be reorganization of
the code rather than writing code from scratch.

Phil: If you can do it with just Send, then try to do it with Send.

Om: Send interface is a datagram protocol. It might be advantageous to
send ADUs rather than a whole message_t.

Phil: What's that mean for allocation?

Om: Will probably need to do copies at the network layer interface.

Phil: How about the receive side?

Om: Application would need to copy it before returning from the event.

Phil: So it's easier to just call send on some structure?

Om: Seems like it would be. We've seen this pattern a lot (e.g. sensor
readings).

Gil: The ADU interface is very forward looking, but might want to just
use send to get something out quickly.

Phil: The problem with doing ADUs is that it's all or nothing. Once we
need to do copies, every layer above will also need to do copies if
you want to keep the ADU style interfaces.

Protocols vs. systems

Phil: Do we just want to talk about systems? or also talk about
protocols (i.e. write a document that describes interfaces, packet
format, and state machine for how the protocol works). Think about
that for next week.

--
Jonathan W. Hui
jwhui at cs.berkeley.edu
http://www.cs.berkeley.edu/~jwhui/