Subject: Re: [Roll] unsigned integer MUST be at least 6 octets long?

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Jul 2010 15:11:15 +0200

[posting from gmail gui, no Message-ID, unformatted]

A quick note on this non blocking aspect.

Le 25/07/2010 21:37, Philip Levis a écrit :
>
> On Jul 24, 2010, at 2:32 AM, Alexandru Petrescu wrote:
>
>> Has this nit been solved somehow?  Are there any opinions or
>> reasons to ignore this nit?
>>
>> The nit is the draft to wrongly consider an unsigned integer at
>> least 6 octet long, because this makes impossible to use unsigned
>> integers 4 octet longs (which are a default on many platforms).
>>
>
> The assumption is that you use an unsigned long long (uint64_t).

As stack implementer I rarely work with uint64_t as they are hardly
portable across plaforms.

> If for very tight RAM reasons you don't want to allocate 8 bytes, 6
> is sufficient.

Hmmm...

> I would assume that most simple implementations just use ULL.

Probably(?)

> Making protocol decisions for "int" seems like a poor idea, given its
> non-portable nature.

Hmmm... in my experience int could be widely assumed as 4byte - not
everywhere, but mostly.  On another hand I think there exists no C 6byte
int structure (I think).

> It's worthwhile noting that many LLN platforms (e.g.,
> microcontrollers) have 2 octet, not 4 octet, "int" values. A common
> mistake novice programmers make in this domain. :)

I agree, I find this to be a good note.  A wise specifier would help a
novice implementer by setting most if not all RPL message formats as
2byte or 1byte fields.

> Using 4 bytes is not technically feasible due to the timescales
> required. A 32-bit counter with millsecond granularity wraps around
> after approximately 50 days. We would like networks to last longer
> than 50 days and be protected from replay as well as delay attacks.
> Again, I feel that your concerns are ignoring the actual technical
> problem which the protocol is trying to solve.

Sorry, not ignoring.  I agree with the timescale required 50days.  There
may be however a way to specify it easier to read by implementer.  E.g:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
       |C|T| Rsrvd |Sec|KIM|Rsrvd| LVL |      1st2CounterBytes         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |       2nd2CounterBytes        |      3rd2CounterBytes         |
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Counter value is a timestamp at least 6bytes long.  When the
timestamp is 6bytes long, implementation should concatenate the fields
1st2CounterBytes, 2nd2CounterBytes and 3rd2CounterBytes into a single
6-byte value.  Each CounterBytes field is in network byte order.  The
concatenation should be in host byte order.  Symbolic  example code for
concatenation is the following: [...]

(also one considers that hton functions don't exist for 6byte integers,
making it hard to display and understand a 6byte value)

Alex

> Phil