[net2-wg] Meeting notes, 01/05/06

[Omprakash Gnawali]

December 05, 2006, 9:17 PST

Present: Jon, Gil, Om, Kyle

Jon chaired the meeting.




Kristin Wright

Jon:	She is interested in joining the group. She does
	meeting notes, website, managing code repository for TinyOS
	and she is interested in doing the same here.

Gil:	Sounds good.

Kyle:	Great.

Om:	Good.

Jon:	Phil won't have any objection. She is in.



Collection components

Jon:	Om sent out the collection interface.

Om:	Sources call collect when they want to send data to the
	sink. The multisink collect call, collectSink, lets you
	specify the sink. On the receiver (sink), you get collectReceive
	when data for you has arrived from the network.

Kyle:	Lets make the method/interface names more descriptive/less
	confusing.

Om:	Should we have one interfaces that has both collect and
	collectSink calls, or should we have two interfaces - one
	for single sink collection and one more multi sink collection ?

Gil:	Two interfaces. Having the multisink call silenty fail
	when called on a single sink collection seems bad.

Kyle:	Two interfaces.

Gil:	Should we put address in the front to make it look like
	rest of the TOS2 interfaces ?

Om:	Sure.

Om:	Should Intercept interface provide msg ptr as well as
	payload ptr ?

Gil:	To provide payload pointer will require fragmentation.

Om:	I think the decision was to assume collection interface
	provides a simple datagram service where payload fits
	in a single packet.

Gil:	Message ptr allows applications to get lower level
	information about the packet.

Om:	Depends on who is intercepting. If we consider this
	a high level interface and an application is
	intercepting for application level packet processing
	then we would not need a msg ptr. But providing
	both seems better.

Gil:	Should collect receive also return msg ptr ?

Jon:	Return msg ptr.

Gil:	Not sure about the usage scenario yet for msg ptr
	in collect receive because it is a high level interface.

Om:	Right, the idea here is you call collect and you can
	forget about the data.

Jon:	Should collect be splitphase to make sure resources are
	managed properly ?

Om:	Lets do that.

Jon:	Lets do that.

Kyle:	Lower layers on which this is implemented are also split phase.

Jon:	Conclusions are we will have two interfaces for collection.
	First will have collect and collectDone. Second will have
	collectSink and collectSinkDone. We will stick with the
	current Intercept interface.

Kyle:	Buffer swap or copy model for collect receive ? How long is
	the data valid ?

Gil:	As it is in the current mode: not valid after event returns.
	Buffer swap might be error prone.

Gil:	Should addr_t be general so that it can support other types
	collection addresses ? Beacon vector.

Om:	Geographic routing.

Gil:	Dissemination, for example, does not mention addr_t. Is it
	necessary in collection ? What if there is a collection
	protocol that has a different idea about what an address is.
	That collection protocol would not be able to implement the
	collection interface.

Om:	For dissemination, there is no need to specify the address
	because the destination is the whole network. For single
	sink version of collection, we would not need an
	address because the address is the single sink. For multiple
	sink version, there are two cases: One, the collection
	protocol decides which sink to use, for redundancy, clustering,
	etc. In this case, the users of collection have no input on
	to which sink should the packet go so we would not need
	an address. Certain multi-sink collection protocols
	might allow the users of collection to specify the destination
	sink because it might have constructed multiple trees,
	for example. High level applications might take advantage
	of this feature because they are doing application-level
	clustering. In this last case we would need an address.

Gil:	Lets have a fixed address type for now to expediate the
	implementation.

Gil:	result_t should be error_t, name should capitalized.


Development plans/deadlines

Jon: 	Lets discuss the timeline for initial collection
	implementation. TinyOS Technology Exchange is
	coming up in a month so we don't have a lot of time.
	Should we have discussions on what the implementation
	ought to look like or just hack it ?

Gil:	Just hack it.

Jon:	Just hack it.

Om:	Lets make high level decisions that can be made quickly
	For example, LQI vs. beacon based link estimation, high
	level things like that. Also, will the implementation
	look similar to MintRoute ?

Jon:	Lets decide how to do link quality estimation. Most
	of us are more familiar with beacon based link
	estimation. We need to support CC1000 as well as
	CC2420, so lets do beacon based link estimation.

Om:	Sounds good.

Om:	How about neighbor table. What will it look like ?

Gil:	SP has its own notion of what neighbor table looks like,
	what the interfaces look like. So, if we are thinking
	about collection on top of SP at some time in the future,
	lets separate the neighbor table functionality in
	MintRoute.

Om:	This sounds like reorganization of MintRoute rather
	than writing code from scratch.

Jon:	Yes. And probably also Drain. The plan for dissemination
	is also similar -- start with the existing code.

Om:	Do we need to worry about the router/forwarder interaction
	and interface ? I remember having a lot of discussion
	on this topic but don't remember the decision.

Jon:	I don't think we should worry about that aspect of collection
	for now. It looked too much into how collection is
	implemented. What is important is now we have a top level
	interface and we should start working on implementing it.

Jon:	Subgroups can decide further details on their own. No need
	to consult the larger group. From what I remember,
	Rodrigo, Kyle, and Om are in the collection subgroup. Phil
	and Gil are working on dissemination. They will check
	the skeleton by this weekend and have a version of
	dissemination by next week. Should we follow similar
	timeline for collection ?

Om:	Sure.

Kyle:	Sure.

Jon:	Ok, lets try to have a basic version of collection
	by next week.



Virtualization

Jon:	The idea here is to hide a queue behind an interface.
	Every instance of the call is guaranteed one successful
	call. If you call collect before collectDone, for example,
	it will fail because you only have one slot.

	The advantage of this approach is properly written
	applications will always work. The downside is memory
	management.

Kyle:	Can this be an ifdef ?

Jon:	Some components might assume they are running on the
	virtualized interface and those components might no
	longer work.

Gil:	Standard and generic components to implement the
	non-virtualized and virtualized interfaces will make
	that distinction clear.

Jon:	Lets do non virtualized componenets first, if we decide
	virtualize, we will do that on top.

Gil:	Agree.


The meeting ended at 10:00 PST.