[Tinyos-devel] Current status of the message buffer discussion

[Jan Hauer]

>> While a component "owns" the packet (after it has received it via
>> send() and before it has passed it to some other component via some
>> other send(), i.e. the send() commands typically differ in the control
>> parameters), it can use any remaining unused memory inside the packet
>> to store temporary variables/addresses, component state, etc., because
>> at protocol layer N a packet never includes any information belonging
>> to the layers < N, which it could override. So even if layer N calls
>> send() on layer N-1 and passes/tunnels control information for layer
>> N-2, then layer N-1 could typically temporarily store them in front of
>> its own header inside the packet.
>
> This is the main difference between our proposals! I think at layer N
> the packet has a payload and a valid header which consists of the
> header segments of the layers below at layer N-1, N-2, etc.

Why should an outbound packet at layer N already include all
headers/footers of all the lower layers < N? Their header/footer
layout can still change while the packet propagates down the stack.
What if you have two different send-paths, e.g. two alternative
protocols at layer N, and layer N+1 chooses dynamically where to pass
the packet to -- how could you decide in advance, at the time the app
writes its payload in the packet, whose headers (layouts) you put in
the packet?

> You want
> to put all header information of the lower layers into the send
> command.

Ideally I'd like layer N to pass to N-1 only the parameters relevant
to the service provided by N-1, nothing else (e.g. transport layer
shouldn't ask for link layer acknowledgments). I'm not sure how
realistic this is with the current implementations, maybe net2 people
can speak up.

> However, if you add a new layer between N-1 and N which adds
> some extra header info, then suddenly you cannot handle that with your
> proposal without changing the code of layer N.

If the service (interfaces) provided by the new layer N-1 changes,
then: yes, you have to adapt to it. Otherwise: no, layer N wouldn't
notice.

> Of course there are mixed in layers that require metadata info (like
> PacketLink), but you correctly realize that those parameters (even
> though they are just message parameters) cannot be included into the
> send command so you have to handle the metadata section separately
> (that is why your flat buffer does not include the metadata section
> and mine does) exactly the same way I want to do the header info too.
>
> With your proposal it would be impossible to write an ActiveMessage
> layer which just adds a single am_type header byte and works both with
> IEEE 802.15.4 packets that require 32-bit addresses in the send
> command, and with the compact header used for CC1000 which uses 16-bit
> addresses. Just because the lower layers are different and take
> different parameters you HAVE TO handle all those parameters at the
> ActiveMessage layer or AMSenderC, store then, retrieve them and pass
> them down, and in effect you need to rewrite the ActiveMessage layer.

AM is mainly a dispatcher, it should be part of the link layer, rather
than justify a separate "layer". In fact, a dispatcher should be a
generic library component (put in tos/lib), so it can be used by
protocols at different layers of the protocol stack. Something else
that AM does at the moment is provide a single-hop communication
abstraction to the net2 protocols. Whether and at what layers there
should be such communication abstractions, and how they should look
like is an interesting question ...

Jan

> I am NOT saying that the user cannot use the familiar AMSend.send
> command that is dear to him. But in my opinion the AMSend interface is
> just a syntactic sugar at the application layer.
>
> Miklos
>