[Tinyos Core WG] Fwd: [Tinyos-devel] message_t

[Philip Levis]

On May 6, 2009, at 12:10 PM, culler wrote:

> There are indeed several distinct issues here.
>
> Inclusion of AM_ID and group in the frame format.  Yes, I do think  
> that it is time we got beyond that.  AM_ID and Group are really  
> layer 4 concepts that are being encapsulated in a layer 2 position.   
> They identify the service endpoint.  The encapsulation should be
> [link address [routing endpoint [ service end point [payload ]]]]

I disagree -- they are very clearly layer 2 concepts. Most link layers  
(802.15.4 is broken in this regard) have a dispatch field. 802.15.4  
has a PAN identifier -- this maps to an AM group. It might have been  
that, as originally intended for parallel processors, AM ids were an  
application layer mechanism, but once you go to networking, they are a  
layer 2 dispatch. Or is the argument that MintRoute, CTP, PSFQ,  
CentRoute, and MultihopLQI, are layer 5-7 protocols? If someone wrote  
an IPv6 encoding different than 6lowpan's on top of AM, wouldn't it be  
layer 3? It happens that some TinyOS services were single hop.

I'm trying to distinguish "applications should move beyond AM to use  
layer 3 and 4 APIs" from "there should be no access to the link  
layer." The former is a perfectly reasonable argument, the latter  
seems tenuous.


> Programming interface.  Our use of destination addresses treats them  
> as small integers, rather than as an addressing structure.  It is  
> critical to maintain the event driven interface, so traditional  
> sockets is not right.  Explicit notification of completion is key to  
> determining when resources can be reused.  It is more natural with a  
> datagram abstraction, like AM and UDP, than a sockets abstraction.

Technically, UDP traditionally uses sockets, albeit SOCK_DGRAM rather  
than SOCK_STREAM.

That being said, why is explicit notification of completion  
inappropriate to stream sockets? I assume such an event would be when,  
in a traditional OS, the kernel can reclaim the memory storing the  
data to transmit. If the stream is reliable, this will be in response  
to an end-to-end acknowledgement, rather than link layer transmission  
or delivery, and so have much higher latency. But that is the time  
when resources can be reused.



> Fixed format packets: the goal of message_t and mx structs was to  
> eliminate error prone runtime parsing and to avoid copies.  The  
> challenge is that it is extremely difficult to represent a series of  
> TLVs or the analogous sequence of fields is very difficult to fit  
> into the struct static parsing model.  We are seeing this at layer 2  
> with short and long mac addresses, layer 2.5 with lowpan, layer 3  
> and 4 with IP, and layer 7 as soon as you include a sequence of  
> attribute/values like in almost all the industrial instrumentation  
> protocols.  You need at least an iterator to run down the sequence  
> of fields.  I would love to not reproduce the tons of broken code  
> that exists outside tinyos with all the broken htons and noths and  
> bogus parsers.  But I don't see how just nested structs is enough.

Exactly -- hence Miklos' and Jan's proposals, which discard using  
nested structs and instead rely on a fixed size byte buffer with  
dynamic offsets.

Phil