Difference between revisions of "New Message"

From TinyOS Wiki
Jump to: navigation, search
(scenarios added)
 
(added proposals and initial comparison)
Line 1: Line 1:
 +
TinyOS needs a new message buffer abstraction due to the need for variable headers.
 +
 +
== Proposals ==
 +
 +
The following proposals exists.
 +
 +
{| border="1"
 +
| Proposal
 +
| See
 +
|-
 +
| KISS
 +
| https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-August/004518.html
 +
|-
 +
| Jan's
 +
| https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-August/004518.html
 +
|-
 +
| M1
 +
| TODO
 +
|-
 +
| M2
 +
| TODO
 +
|-
 +
| YALP
 +
| https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-August/004524.html
 +
|}
 +
 +
== Comparing Proposals ==
 +
 +
The following table compares the proposals based on bound on number of times a header needs to be copied, bound on the number of time data needs to be copied, memory allocated per packet, radio layer modularity, and how headers of underlying layers are accessed.
 +
 +
{| border="1"
 +
| Proposal
 +
| Bound on header copy
 +
| Bound on data copy
 +
| Memory allocated per packet
 +
| Modularity
 +
| Header access
 +
|-
 +
| KISS
 +
| O(#format)
 +
| O(#format)
 +
| MDPU + metadata
 +
| Limited.  All header data is reset on format, so a layer would have to know how to restore them from the underlying layers.
 +
| Direct.
 +
|-
 +
| Jan
 +
| O(#layers)
 +
| O(1) - if a received packets new headers are unaligned with buffer
 +
| MDPU + metadata
 +
| none, vars passed from layer to layer
 +
| Through layers
 +
|-
 +
| M1
 +
| O(#format or adjust)
 +
| O(#footers) - if footers on received packet are removed and there's not enough space for new headers
 +
| MDPU + MAX_FOOTER_LENGTH + metadata
 +
| Yes, layers can be arbitrary stacked
 +
| Direct
 +
|-
 +
| M2
 +
| O(#format or adjust)
 +
| O(#format or adjust) - whenever a footer is added or removed
 +
| MDPU + metadata
 +
| Yes, layers can be arbitrary stacked
 +
| Direct
 +
|-
 +
| YALP
 +
| O(1) - when copied between metadata and actual header
 +
| never
 +
| MDPU + sum of all layers allocated data (max of metadata and header)
 +
| limited, total order of layers needs to be defined so metadata can be allocated accordingly
 +
| Direct
 +
|}
 +
 +
The proposals needs to be able to handle the scenarios listed below.  The following table summarizes how each proposal handle the scenarios.
 +
 +
{| border="1"
 +
| Proposal
 +
| Scenario 1
 +
| Scenario 2
 +
|-
 +
| KISS
 +
|
 +
|
 +
|-
 +
| Jan's
 +
|
 +
|
 +
|-
 +
| M1
 +
|
 +
|
 +
|-
 +
| M2
 +
|
 +
|
 +
|-
 +
| YALP
 +
|
 +
|
 +
|}
 +
 +
To sum it all up, lets try and keep an overview of why/why not a proposal should be used.
 +
 +
{| border="1"
 +
| Proposal
 +
| Why should we NOT use this?
 +
| Why should we use this?
 +
|-
 +
| KISS
 +
|
 +
|
 +
|-
 +
| Jan's
 +
| Routing layer would have to pass on Ieee154 security parameter
 +
|
 +
|-
 +
| M1
 +
|
 +
|
 +
|-
 +
| M2
 +
|
 +
|
 +
|-
 +
| YALP
 +
| Memory overhead of Scenario 2
 +
|
 +
|}
 +
 +
 
== Scenarios ==
 
== Scenarios ==
 +
 +
Scenarios that the new message abstractions should be able to handle.
  
 
''' Scenario 1'''  
 
''' Scenario 1'''  
Line 18: Line 151:
 
''' Scenario 2 '''
 
''' Scenario 2 '''
  
−
We have a split communication with two radios sending different packet formats.  In this case we have to assume that the routing layer knows about its underlying layers in order to transfer a packet from Ieee154 format to the Proprietary format and vice versa.  This means that the routing layer can choose one of the two underlying formats as its standard one, and expose that interface to the upper layers.  Lets say it chooses Ieee154 as its standard format and for simplicity store all packets internally as Ieee154 packets (alternatively it can use a flag in the metadata to indicate the format of the packet stored).
+
We have a split communication with two different radios sending different packet formats.  In this case we have to assume that the routing layer knows about its underlying layers in order to transfer a packet from Ieee154 format to the Proprietary format and vice versa.  This means that the routing layer can choose one of the two underlying formats as its standard one, and expose that interface to the upper layers.  Lets say it chooses Ieee154 as its standard format and for simplicity store all packets internally as Ieee154 packets (alternatively it can use a flag in the metadata to indicate the format of the packet stored).
  
 
Layers:
 
Layers:

Revision as of 19:06, 16 August 2010

TinyOS needs a new message buffer abstraction due to the need for variable headers.

Proposals

The following proposals exists.

Proposal See
KISS https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-August/004518.html
Jan's https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-August/004518.html
M1 TODO
M2 TODO
YALP https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-August/004524.html

Comparing Proposals

The following table compares the proposals based on bound on number of times a header needs to be copied, bound on the number of time data needs to be copied, memory allocated per packet, radio layer modularity, and how headers of underlying layers are accessed.

Proposal Bound on header copy Bound on data copy Memory allocated per packet Modularity Header access
KISS O(#format) O(#format) MDPU + metadata Limited. All header data is reset on format, so a layer would have to know how to restore them from the underlying layers. Direct.
Jan O(#layers) O(1) - if a received packets new headers are unaligned with buffer MDPU + metadata none, vars passed from layer to layer Through layers
M1 O(#format or adjust) O(#footers) - if footers on received packet are removed and there's not enough space for new headers MDPU + MAX_FOOTER_LENGTH + metadata Yes, layers can be arbitrary stacked Direct
M2 O(#format or adjust) O(#format or adjust) - whenever a footer is added or removed MDPU + metadata Yes, layers can be arbitrary stacked Direct
YALP O(1) - when copied between metadata and actual header never MDPU + sum of all layers allocated data (max of metadata and header) limited, total order of layers needs to be defined so metadata can be allocated accordingly Direct

The proposals needs to be able to handle the scenarios listed below. The following table summarizes how each proposal handle the scenarios.

Proposal Scenario 1 Scenario 2
KISS
Jan's
M1
M2
YALP

To sum it all up, lets try and keep an overview of why/why not a proposal should be used.

Proposal Why should we NOT use this? Why should we use this?
KISS
Jan's Routing layer would have to pass on Ieee154 security parameter
M1
M2
YALP Memory overhead of Scenario 2


Scenarios

Scenarios that the new message abstractions should be able to handle.

Scenario 1

We have a single communication stack where the header size depends on the Ieee154 security mode and addressing length.

Layers: 

App -> Route -> Ieee154 -> Radio

App internals: 

Set Ieee154 security mode on packet
Send to route

Route internals: 

Set Ieee154 addr mode on packet
Send to Ieee154

Scenario 2

We have a split communication with two different radios sending different packet formats. In this case we have to assume that the routing layer knows about its underlying layers in order to transfer a packet from Ieee154 format to the Proprietary format and vice versa. This means that the routing layer can choose one of the two underlying formats as its standard one, and expose that interface to the upper layers. Lets say it chooses Ieee154 as its standard format and for simplicity store all packets internally as Ieee154 packets (alternatively it can use a flag in the metadata to indicate the format of the packet stored).

Layers: 

App -> Route -> Ieee154 -> Radio1
         +----> ProprietaryPacket -> Radio2

App internals: 

Set Ieee154 security mode on packet (from the App it looks like the routing layer sends Ieee154 packets).
Send to route

Route internals: 

if send on Ieee154
    Set Ieee154 addr mode on packet
    Send to Ieee154
else
    Set proprietary addr mode on packet
    Send to ProprietaryPacket
Retrieved from "http://tinyos.stanford.edu/tinyos-wiki/index.php?title=New_Message&oldid=4406"