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

[Omprakash Gnawali]

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


We decided to provide payload as well as msg pointer.


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


In TOS1, there are a number of interfaces: Send, SendData,
SendVarLenPacket, SendMsg. For the two functionalities that we are
proposing for collection, I am not sure if there can be a single
interface. collect interface will probably look similar to SendData
and collectSink will not look like any of the interfaces above. It
will look like a combination of SendData and SendMsg.

Also to note here is that existing routing protocols implement the
Send interface rather than an entirely new interface with a new name
such as RoutingSend even though the eventual consequence of calling a
Send on components such as radio or uart is different from calling
Send on MintRoute, for example.



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

I think the main point there was depending on the underlying routing
protocol, the addresses might have different format. Probably the
conversation got a bit sidetracked ...





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



I am not sure if the address should be a tree identifier or a compile
time parameter. In a more dynamic scenario where you can not know the
sinks or trees ahead of time, the nodes ought to be able to address a
tree or a sink during runtime. But then, right now, we don't have a
story on how that address/treeid is discovered by an application (user
of the collection interface).