Difference between revisions of "New Message"
(added stuff to why/why NOT) |
(added scenario 3) |
||
| Line 13: | Line 13: | ||
|- | |- | ||
| Jan's | | Jan's | ||
| − | | https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-August/ | + | | https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2010-August/004519.html |
|- | |- | ||
| M1 | | M1 | ||
| Line 27: | Line 27: | ||
== Comparing Proposals == | == 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, | + | 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, communication stack layer modularity, and how headers of underlying layers are accessed. |
{| border="1" | {| border="1" | ||
| Line 34: | Line 34: | ||
| Bound on data copy | | Bound on data copy | ||
| Memory allocated per packet | | Memory allocated per packet | ||
| − | | Modularity | + | | Modularity in stack |
| Header access | | Header access | ||
|- | |- | ||
| Line 79: | Line 79: | ||
| Scenario 1 | | Scenario 1 | ||
| Scenario 2 | | Scenario 2 | ||
| + | | Scenario 3 | ||
|- | |- | ||
| KISS | | KISS | ||
| The App formats the packet with the desired security mode. Routing layer would need to format the packet when addr mode changes and hence need to know how to restore headers of all layers below (need to be reformatted with the security mode set from App). | | The App formats the packet with the desired security mode. Routing layer would need to format the packet when addr mode changes and hence need to know how to restore headers of all layers below (need to be reformatted with the security mode set from App). | ||
| Routing layer would need to format the packet when it changes communication stack (or when addr mode is changed as for scenario 1). The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | | Routing layer would need to format the packet when it changes communication stack (or when addr mode is changed as for scenario 1). The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | ||
| + | | | ||
|- | |- | ||
| Jan's | | Jan's | ||
| Routing layer would pass on Ieee154 security mode from App to Ieee154 layer. | | Routing layer would pass on Ieee154 security mode from App to Ieee154 layer. | ||
| Routing layer would have to retrieve all sub-layer parameters on receive and them pass them on to the right communication stack on send. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | | Routing layer would have to retrieve all sub-layer parameters on receive and them pass them on to the right communication stack on send. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | ||
| + | | The radio layer has statically allocated space in the metadata field of the message structure and provides a Metadata interface for protocols to access it. The routing layer can access the radios metadata through this interface. | ||
|- | |- | ||
| M1 | | M1 | ||
| Routing layer would adjust the Ieee154 layers addr mode which leaves everything else unchanged. | | Routing layer would adjust the Ieee154 layers addr mode which leaves everything else unchanged. | ||
| Routing layer would need to format the packet when it changes communication stack. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | | Routing layer would need to format the packet when it changes communication stack. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | ||
| + | | The radio layer has statically allocated space in the metadata field of the message structure and provides a Radio interface for protocols to access it. The routing layer can access the radios metadata through this interface. | ||
|- | |- | ||
| M2 | | M2 | ||
| − | | | + | | (same as M1) |
| − | | | + | | (same as M1) |
| + | | (same as M1) | ||
|- | |- | ||
| YAMP | | YAMP | ||
| Routing layer would set the metadata addressing fields of the Ieee154 layer. | | Routing layer would set the metadata addressing fields of the Ieee154 layer. | ||
| The App could set the Ieee154 and PropertaryPacket parameters for the packet when passed to the routing layer, but when the routing layer receives a packet from one communication stack, it would need to set the according metadata of the other communication stack. Again, The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | | The App could set the Ieee154 and PropertaryPacket parameters for the packet when passed to the routing layer, but when the routing layer receives a packet from one communication stack, it would need to set the according metadata of the other communication stack. Again, The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | ||
| + | | | ||
|} | |} | ||
| Line 118: | Line 124: | ||
| M1 | | M1 | ||
| Memory overhead with many footers (thought to be rare) | | Memory overhead with many footers (thought to be rare) | ||
| − | | memmove of data very very rare. Modular architecture, only need to be aware of underlying layers when packet changes | + | | memmove of data very very rare. Modular architecture, only need to be aware of underlying layers when packet changes communication stack. |
|- | |- | ||
| M2 | | M2 | ||
| Data memmove everytime footer added or removed | | Data memmove everytime footer added or removed | ||
| − | | | + | | Modular architecture, only need to be aware of underlying layers when packet changes communication stack. |
|- | |- | ||
| − | | | + | | YAMP |
| Memory overhead. Especially in scenario 2 where metadata for both Ieee154 and ProprietaryPacket needs to be allocated. | | Memory overhead. Especially in scenario 2 where metadata for both Ieee154 and ProprietaryPacket needs to be allocated. | ||
| − | | No need for memmove of data. (Limited) Modular architecture (restricted by a total order of layers), only need to be aware of underlying layers when packet changes | + | | No need for memmove of data. (Limited) Modular architecture (restricted by a total order of layers), only need to be aware of underlying layers when packet changes communication stack. |
|} | |} | ||
| Line 167: | Line 173: | ||
Set proprietary addr mode on packet | Set proprietary addr mode on packet | ||
Send to ProprietaryPacket | Send to ProprietaryPacket | ||
| + | |||
| + | ''' Scenario 3 ''' | ||
| + | |||
| + | We have a single communication stack where the Radio layer adds the incoming (and outgoing if ACK is used) RSSI and LQI in the packets metadata. | ||
| + | |||
| + | Layers: | ||
| + | App -> Route -> Ieee154 -> Radio | ||
| + | |||
| + | Radio internals: | ||
| + | Sets its RSSI and LQI metadata fields | ||
| + | |||
| + | Route internals: | ||
| + | Gets the RSSI and LQI metadata information and uses it to update its routing table | ||
Revision as of 21:27, 16 August 2010
TinyOS needs a new message buffer abstraction due to the need for variable headers.
Proposals
The following proposals exists.
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, communication stack layer modularity, and how headers of underlying layers are accessed.
| Proposal | Bound on header copy | Bound on data copy | Memory allocated per packet | Modularity in stack | 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 |
| YAMP | 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 | Scenario 3 |
| KISS | The App formats the packet with the desired security mode. Routing layer would need to format the packet when addr mode changes and hence need to know how to restore headers of all layers below (need to be reformatted with the security mode set from App). | Routing layer would need to format the packet when it changes communication stack (or when addr mode is changed as for scenario 1). The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | |
| Jan's | Routing layer would pass on Ieee154 security mode from App to Ieee154 layer. | Routing layer would have to retrieve all sub-layer parameters on receive and them pass them on to the right communication stack on send. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | The radio layer has statically allocated space in the metadata field of the message structure and provides a Metadata interface for protocols to access it. The routing layer can access the radios metadata through this interface. |
| M1 | Routing layer would adjust the Ieee154 layers addr mode which leaves everything else unchanged. | Routing layer would need to format the packet when it changes communication stack. The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. | The radio layer has statically allocated space in the metadata field of the message structure and provides a Radio interface for protocols to access it. The routing layer can access the radios metadata through this interface. |
| M2 | (same as M1) | (same as M1) | (same as M1) |
| YAMP | Routing layer would set the metadata addressing fields of the Ieee154 layer. | The App could set the Ieee154 and PropertaryPacket parameters for the packet when passed to the routing layer, but when the routing layer receives a packet from one communication stack, it would need to set the according metadata of the other communication stack. Again, The routing layer would have to know how to transfer a packet from Ieee154 (and Radio1) format to PropertaryPacket (and Radio2) format. |
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 | The data is moved every time the header length is changed. A protocol layer needs to be aware if its underlying layers whenever a packet is formatted within a communication stack. | |
| Jan's | Intermediate layers would have to pass on parameters of lower layers from upper layers. | |
| M1 | Memory overhead with many footers (thought to be rare) | memmove of data very very rare. Modular architecture, only need to be aware of underlying layers when packet changes communication stack. |
| M2 | Data memmove everytime footer added or removed | Modular architecture, only need to be aware of underlying layers when packet changes communication stack. |
| YAMP | Memory overhead. Especially in scenario 2 where metadata for both Ieee154 and ProprietaryPacket needs to be allocated. | No need for memmove of data. (Limited) Modular architecture (restricted by a total order of layers), only need to be aware of underlying layers when packet changes communication stack. |
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
Scenario 3
We have a single communication stack where the Radio layer adds the incoming (and outgoing if ACK is used) RSSI and LQI in the packets metadata.
Layers:
App -> Route -> Ieee154 -> Radio
Radio internals:
Sets its RSSI and LQI metadata fields
Route internals:
Gets the RSSI and LQI metadata information and uses it to update its routing table
