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

[Philip Levis]

On Jan 7, 2006, at 12:45 AM, Omprakash Gnawali wrote:

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

Sounds good to me.

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

For some of those -- e.g., SendData and SendVarLenPacket -- the  
multiplicity is basically just a mistake with cleaning up after  
naming changes. If you look at the two, they have identical comments,  
etc. Additionally, SendData/SendVarLenPacket were intended only for  
UART use, as it doesn't have to be a packet-based medium. That leaves  
Send and SendMsg, the distinction those two being addressing,  
reflected in 2.x Send and AMSend.

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

There's a distinction between consequence and calling semantics.  
Sending a packet to a loopback address has a very different  
consequence (it never leaves memory) than to a distant address.  
However, semantically it can be the same. Compare that with, say,  
sending a unicast packet and a broadcast packet. While you *can* make  
them look semantically the same, this requires removing some  
information (e.g., acks).

I agree that there are situations in TinyOS 1.x where the semantics  
of an interface depend on the component that implements it. For  
example, with AMStandard, if you do this:

call SendMsg.send(...);
call SendMsg.send(...);

then the second call will almost always fail (one exception being if  
an interrupt turned the component on between the two, another being  
if the parameters to the first, such as length, were invalid,). In  
contrast, if you call SendMsg on QueuedSendC, then the second send  
will succeed if there's space in the queue.

I'll argue that these semantic distinctions were a mistake. The  
acceptable calling patterns of an interface should (for the most  
part) be independent of the component that calls them. In the 1.x  
case, it's easy to say that SendMsg.send sits on top of a queue and  
in AMStandard that queue happens to be of length 1. The problem is  
that many components (e.g., those written before QueuedSendC) then  
assumed that the queue was length 1.

Hence my comment: if the interfaces have the same parameters and  
calling semantics as Send, then they probably should just be Send. If  
they have different calling semantics, then a new interface is the  
right way to go.

Maybe this would be easier for me to understand if I saw the  
interfaces. There's been a good deal of work in the 2.x group to  
define communication interfaces. If they are insufficient, we  
shouldn't feel beholden to follow them. But on the other hand, if  
they are sufficient then using them --- if only for simplicity and  
compatibility reasons --- is probably a good idea.

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

Ah, right. Makes sense.

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

Makes sense. It's always easy to transform between runtime (function)  
and compile-time (wiring) parameters. It sounds like the initial stab  
will be with the latter?

Phil

-------

"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."

- T. S. Eliot,  'Little Gidding'