Hello Valery
Yes we considered ROHC and also 6LoWPAN, because both include
possibilities for compression ESP.
First, it's definitely an option and remains an option even if Diet-ESP
is going to be used.
We are thinking about Diet-ESP because:
- If I'm right ROHC needs at least one uncompressed packet to be send,
which may be expensive.
- As we want to use IPsec/ESP we have all necessary information in the
SAD/SPD to restore the information of IP/UDP/(partly TCP). The idea is
to use them instead of adding ROHC compressors between the different
layers which 1) adds ROM space (which may be limited) and 2) storage for
an information which is already there.
- In case of Diet-ESP it is really simple to restore the payload headers
and it costs only two bits to send once in the session. This is why we
decided to add this as an option.
BR
Tobias
Am 28.02.2014 07:34, schrieb Valery Smyslov:
Hi Daniel,
However, the ratio computing vs communication in IoT is quite
impressive and there is a high interest in compressing frames before
transmitting them.
- Computing ranges from 0.5nJ per instruction for extremely
energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200
nJ per instruction for high-performance microprocessors (such as
ARM9).
- Communication: from 100nJ to 1uJ per bit transmitted or
received, depending on modulation complexity and transmission power
(we only consider "low-power" radios, with transmit powers lower than
about 10mW).
Roughly speaking, this means that, for the energy cost of exchanging 1
bit, our system can alternatively compute 10-100 instructions.
Yes, it's impressive. Did you consider using ROHC (RObust Header
Compression)?
It will allow you to significantly decrease size of TCP/UDP/IP headers.
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
