Subject: [Dtls-iot] 32 bit alignment with IoT

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Dec 2013 21:42:28 +0100

Hi,

Regular data structure in kernel (at least Linux) need a 32 bit alignment.
As a result IPsec/ESP packet must be padded for example. UDP for example is
32 + 32 bits and transport header of 8, 16, 24, 40  bits could hardly be
handled by kernels.

Is there any requirements for IoT?

If there is not be such requirements, then for IPsec/ESP this would mean,
for example, that we could remove the padding.  For UDP we could possibly
compress it to a single byte.

Just to clarify, we took the example of UDP to illustrate our question on
32 bit alignement. We do not work on UDP, but rather on IPsec/ESP.

BR,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Hauke Mehrtens <[email-masked]>
Date: Tue, 17 Dec 2013 22:37:49 +0100

On 12/17/2013 09:42 PM, Daniel Migault wrote:
> Hi,
> 
> Regular data structure in kernel (at least Linux) need a 32 bit
> alignment. As a result IPsec/ESP packet must be padded for example. UDP
> for example is 32 + 32 bits and transport header of 8, 16, 24, 40  bits
> could hardly be handled by kernels.

Alignments is not a problem of the kernel, but it is used to circumvent
a restriction by some processors. Some 32 Bit processors have problems
or are unable to read or write bytes at an offset which is not aligned
by 4 bytes (address % 4 != 0). Normally your compiler takes care of that
stuff and adds padding bytes to your c structs when needed.

When the Linux kernel does an unaligned access on a MIPS CPU the CPU
will send a exception to the kernel handler and this unaligned read will
be emulated in software, which is way slower then an aligned read done
by the CPU.

The GCC for the MSP430 (16 Bit CPU) for example adds a 2 byte alignment
to all data structures and extends the size to a 2 byte alignment as
well by default.

You should probably read this:
http://en.wikipedia.org/wiki/Data_structure_alignment

A UDP Package is nicely aligned when it starts at an aligned address,
but when there is an aligned Ethernet frame header in front, which is 14
or 18 bytes long, then it is not aligned at an 4 bytes boundary any
more, this is probably the problem your are talking about.

> Is there any requirements for IoT?

You could have the same problems in IoT, it depens on your processor.

> If there is not be such requirements, then for IPsec/ESP this would
> mean, for example, that we could remove the padding.  For UDP we could
> possibly compress it to a single byte.
> 
> Just to clarify, we took the example of UDP to illustrate our question
> on 32 bit alignement. We do not work on UDP, but rather on IPsec/ESP.
> 
> BR,
> Daniel

---

From: Daniel Migault <[email-masked]>
Date: Tue, 17 Dec 2013 22:53:46 +0100

thanks a lot, that is the problem we were talking about.
BR
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Robert Cragie <[email-masked]>
Date: Wed, 18 Dec 2013 09:38:53 +0000

I don't think that is quite right. The issue I have come across is some 
32-bit processors have problems reading or writing 16, 32 or 64-bit 
values which are not aligned accordingly, i.e. address & 1 != 0, address 
& 3 != 0 and address & 7 != 0 respectively and generate an address error 
exception. This is the reason a compiler adds padding bytes. Any 
processor should be able to read an 8-bit value at any location and 
therefore packed structures can be used safely if accesses are done on a 
byte-by-byte basis, although this is inefficient of course.

Robert

On 17/12/2013 21:37, Hauke Mehrtens wrote:
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>

---

From: Hauke Mehrtens <[email-masked]>
Date: Wed, 18 Dec 2013 12:54:57 +0100

> byte-by-byte basis, although this is inefficient of course.

Yes you are right.

Hauke

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Dec 2013 10:23:34 -0500

As was said, the alignment goals in IPv6 (64-bits), are not related
to a specific kernel requirement, but rather the result of optimizations
in various processors.  It's just faster to access 32-bit data on 32-bit
alignment.  This is true on x86 where unaligned access causes no exception,
as well as on MIPS where it has to be emulated.  The processor architect
made a decision to favour the fast path at the cost of a very slow
exceptional case.

The origin of this has to do with L1 and L2 caches.  They start on 64-bit
(20 years ago) to 256 bit boundaries. When you touch anything on a cache
line, you load everything else, so having structures that fit entirely
in a cache line is a major boon.  That's why we see the IPv6 extension header
structured as it is.

Padding sent as zeroes is pretty easy to compress out if one is compressing
generically.  I've advocated for doing sensible protocol design, leaving
ourselves appropriate places to introduce new values, and look at what the
byte count is after some naive, trivial compression as provided by 6lowpan HC
and GHC.

My experience with MSP470 and freescale ARM devices is that they don't have
L1 or L2 caches or any alignment issues.  While they often support 32-bit
operations, they frequently have 16-bit internal buses, so there is
essentially no penalty for unaligned access.
There is also no penalty for aligned access.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [