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

[Philip Levis]

On Thu, 2006-01-05 at 10:56 -0800, Omprakash Gnawali wrote:
> December 05, 2006, 9:17 PST
> 

> Om:	Should Intercept interface provide msg ptr as well as
> 	payload ptr ?
> 
> Gil:	To provide payload pointer will require fragmentation.

Assuming a datagram service, you can include the message pointer as well
as payload pointer (e.g., as Receive does now). Not clear from the notes
whether this conclusion was reached.

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

Creating new interfaces that have the same basic semantics as Send has
drawbacks and benefits.

Benefits: It's clear from the interface itself what the component does.
If there are important and unique semantic points about its operation,
then being specific will prevent incorrect wirings.

Drawbacks: It limits composition flexibility. If collect/collectDone and
collectSink/collectSinkDone act exactly like Send, then enabling
components to easily change whether they send to the UART, broadcast, or
up a collection tree is desirable.

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

There's a bit of confusion in the notes here between collection and
arbitrary routing. The latter is of course more general: if all nodes
use a one-to-one routing scheme to transmit to a single node, that forms
a tree. 


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

Is the address a tree identifier? Is it a runtime (function) or compile-
time (wiring) parameter?

Phil