[Tinyos-devel] Message_t thoughts: max_mpdu (mtu) and alignment

[Eric Decker]

On Thu, May 7, 2009 at 5:59 PM, Vlado Handziski
<handzisk at tkn.tu-berlin.de>wrote:

>
> As for (2), if we agree that we should always be prepared to handle a
> MPDU, there is no difference in the amount of memory the two
> proposals have to allocate for the H,P,F part of the buffer,
> i.e. MSG_MAX_LENGTH in Miklos' proposal has to be >= Jan's
> MAX_MPDU_SIZE. However, because in Miklos' proposal the metadata is
> included in the "formating" stage, the MSG_MAX_LENGTH will be <= than
> the MAX_MPDU_SIZE + uniqueCount(METADATA_BYTE) in Jan's proposal.


Not sure of the terms being used here.  MPDU vs. MSG_MAX_LENGTH vs.
MAX_MPDU_SIZE.

With respect to  the receive side there will be a maximum size packet that
can be accepted by an instance.  At the h/w level this is determined by what
the physical interface is capable of receiving.  On a telosb, this is
limited by the radio cc2420 and is 128 bytes.  This includes any headers,
payload, and trailers (CRC, etc).  The tinyos2 code base allows this to be
restricted to minimize how much memory is consumed/allocated for message
buffers.  This is currently specified by TOSH_DATA_LENGTH which sets payload
length.

One issue is dynamic vs. static layout.  Do we want to allow flexibility and
dynamic encapsulation or do want to specify explicitly which encapsulation
are allowed?  If dynamic then space must be allocated for the maximum of
possible headers/encapsulations for layers that can be concatenated.  If
static then we only need to allocate header space for those layers that a
given complilation is invoking.

Given the lack of resources in the nodes we are working with, I would argue
for the static approach.  But one of the questions becomes how to we specify
things so we get the desired behaviour.


An associated issue is how do the encapsulations work.  With Jan's mechanism
the wrapping and unwrapping is dynamic as a packet moves down or up the
protocol stack.  Information must be embedded in the packet that tells a
given layer where the next layer starts.  Usually knowledge of how big the
header is and packet length etc.  Access of data at any layer requires first
figuring out what state the packet is in, namely obtaining where the current
position is, what is the current encapsulation, and how to access the data
we are interested in.

Is there an approach where when coupled with static determination of what
headers are allowed and in what order can we access the information we are
interested in with out the overhead that the dynamic approach costs?   This
is what I mean by alignment.

eric


Vlado
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>


-- 
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090524/65ee88ce/attachment-0001.htm