Subject: [Roll] packet size issues

From: "Peter Siklosi" <[email-masked]>
Date: Wed, 9 Dec 2009 16:36:26 +0100

Hi all,

If I understand correctly, RPL is designed to be usable with for
instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even if
1280 byte IPv6 packets are of course supported using fragmentation,
large packets should be avoided at all cost given the low bandwidth and
low packet delivery success rate.

Given this, I do not understand the alignment requirements specified in
draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in IPv6,
these options are aligned in a packet such that multi-octet values
within the Option Data field of each option fall on natural boundaries".
It seems that it would be more important to keep the messages short and
avoid padding options. I am also curious on allocating 16 bits for a
length field of a sub option. If sub option length exceeding 255 bytes
(as could be specified by 8 bits) are needed, it seems that the routing
messages are expected to get very large.

Regards,
Peter Siklosi

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 09 Dec 2009 18:26:32 +0100

Hi Peter,

I totally agree on the goal of minimizing packet sizes, but I would
like to keep alignment requirements since it simplifies implementations.
I also think (as you mention) that we need to question the 16-bit
sub-option length. Is it really needed? Both IPv6 options and ICMPv6 
option lenghts are encoded as 8-bit values. Going down to 8-bits would
also help the alignment of the options.

Best Regards,
-- Joakim Eriksson, SICS

Peter Siklosi skrev:
> draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the convention in IPv6, 
> within the Option Data field of each option fall on natural boundaries”. 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Tim Winter <[email-masked]>
Date: Wed, 09 Dec 2009 18:34:40 -0500

I agree with Peter that we should consider to remove alignment requirements-
including the Pad1 and PadN options.  I would expect that it is often cheaper
(energy/time/processing) to handle the alignment issues in the implementation versus
transporting extra padding over LLN links.

The 16-bit sub-option length is driven by the DAG Metric Container.  Perhaps once we
begin to see some proposed objective functions we can better determine how large the
Metric Container may need to be.  Perhaps the DAG Metric Container could be chained
such that each piece fits into 255 bytes or less...

-Tim

Joakim Eriksson wrote:
>> large packets should be avoided at all cost given the low bandwidth
>> and low packet delivery success rate.
>>
>>  
>>
>> Given this, I do not understand the alignment requirements specified
>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the convention in
>> IPv6, these options are aligned in a packet such that multi-octet
>> values within the Option Data field of each option fall on natural
>> boundaries”. It seems that it would be more important to keep the
>> messages short and avoid padding options. I am also curious on
>> allocating 16 bits for a length field of a sub option. If sub option
>> length exceeding 255 bytes (as could be specified by 8 bits) are
>> needed, it seems that the routing messages are expected to get very
>> large.
>>
>>  
>>
>> Regards,
>> Peter Siklosi
>>
>>  
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 10 Dec 2009 01:09:27 +0100

Tim Winter a écrit :
> including the Pad1 and PadN options.

I disagree.  I suggest to keep them.

The reason is because an IP stack uses them already - why removing them?

Alex

>  I would expect that it is often cheaper

---

From: "Peter Siklosi" <[email-masked]>
Date: Thu, 10 Dec 2009 08:14:59 +0100

Alex,

Short answer, the reason to remove them is that they waste valuable space. I think it may be a challenge in the first place to get the messages short enough that it would work reasonably well in a real system where the radio environment is less than optimal. Messages should preferably travel unfragmented, or else as very few fragments, and this does certainly not leave many bytes for say LoWPAN over 802.15.4.

I do not see so much focus in the draft on making the representations compact, which I think is actually quite important. Padding makes the situation worse, not better. While simplifying implementations is a good thing, I think this is less important, we cannot waste bytes for this reason (running uncompressed IPv6 instead of applying LoWPAN compression would also make implementations easier..). The same goes for representation of IP addresses. They need to be compressed. If used on LoWPAN, I assume that context based compression would be a common case, since I assume that routing would typically be used within a subnet sharing the same prefix.

Regards,
Peter

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Alexandru Petrescu
Skickat: den 10 december 2009 01:09
Till: Tim Winter
Kopia: [email-masked]
Ämne: Re: [Roll] packet size issues

Alex

>>> in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the convention in
>>> boundaries". It seems that it would be more important to keep the

---

From: Matteo Paris <[email-masked]>
Date: Thu, 10 Dec 2009 11:03:30 -0500

I agree that we should remove alignment requirements and reduce the 
suboption length field to 1 byte.

As Peter wrote, if RPL is to work over constrained link layers, we 
have to keep in mind the frame size and bandwidth constraints of 
those layers.  For example, in 802.15.4 after link-layer overhead, 
the usable payload is only 81 bytes (see RFC4944).

Because limited bandwidth and large dense networks are a common use 
case, it is desirable for a DIO message to fit in a single packet. 
The current size of a DIO message not including the DAG Metric 
Container is already 59 bytes (3 6lowpan ip header + 4 icmp header + 
20 base option + 25 dest prefix + 7 dag config).  Padding could 
increase this by tens of bytes.  If the DAG Metric Container is 
longer than 255 bytes I think it will pose serious challenges to RPL 
operation over constrained link layers.

Matteo

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 Dec 2009 11:43:09 +0100

Peter Siklosi a écrit :
> Alex,
> 
> Short answer, the reason to remove them is that they waste valuable 
> space.

Hi, sorry - how much does one gain?  Figures?

For example, I doubt removal of few bytes here and there are any gain in
wireless bandwidth when considering that the base header alone is
40bytes already, the ICMP header is 8 bytes fixed, and so on.

How much would one save compared to one _has_ to always send? (between
using or not using padding).

> I think it may be a challenge in the first place to get the messages 
> short enough that it would work reasonably well in a real system 
> where the radio environment is less than optimal.

Well yes - let's discuss it.

I thought the shortest IPv6 packet could be 41 bytes, i.e. 40bytes of
base header and 1 byte of data (provided a new Protocol number is
defined, but we don't go that way, because ICMP).

41 bytes is not byte-aligned, it would need an additional pad of 8bytes,
making it 48bytes.

Comparing 48bytes to 41bytes, I do not consider eliminating padding
7bytes a significant save in bandwidth.

How do you see things?

> Messages should preferably travel unfragmented, or else as very few 
> fragments, and this does certainly not leave many bytes for say 
> LoWPAN over 802.15.4.

When you say "fragmented" - do you mean IP fragmentation (happening each
1280bytes) or link-layer fragmentation?  Traditionally, IPdoesn't care
about the latter - why should RPL care?

> I do not see so much focus in the draft on making the representations
>  compact, which I think is actually quite important. Padding makes 
> the situation worse, not better.

Well... padding comes from a requirement of matching packet buffers to
chip memory layout.  I believe today's smallest chipsets act like
earlier bigger chipsets, which had those requirements.

I.e. I think a small 8bit micro-controller has strong requirements on
its memory alignment and addressing, i.e. probably 32bits are addressed
only at 32bit edges, and not 8bit.  Thus padded packets may help a lot
when addressing bytes within memory.

> While simplifying implementations is a good thing, I think this is 
> less important, we cannot waste bytes for this reason (running 
> uncompressed IPv6 instead of applying LoWPAN compression would also 
> make implementations easier..).

Hmm... I believe this is wrong, because simplifying must happen on all
fronts not only the wireless communication part (i.e. the computing
power is also restrained).

> The same goes for representation of IP addresses. They need to be
> compressed.

Well I disagree.  If one touches _anything_ in the representation of an
IP address then one will no longer connect that node to the Internet.

> If used on LoWPAN, I assume that context based compression would be a
> common case, since I assume that routing would typically be used
> within a subnet sharing the same prefix.

Thinking over it...

Alex

> 
> Regards, Peter
> 
> -----Ursprungligt meddelande----- Från: [email-masked] 
> [mailto:[email-masked]] För Alexandru Petrescu Skickat: den 10
>  december 2009 01:09 Till: Tim Winter Kopia: [email-masked] Ämne: Re:
>  [Roll] packet size issues
> 
> Tim Winter a écrit :
>> I agree with Peter that we should consider to remove alignment 
>> requirements- including the Pad1 and PadN options.
> 
>> I would expect that it is often cheaper (energy/time/processing) to
>>  handle the alignment issues in the implementation versus 
>> The 16-bit sub-option length is driven by the DAG Metric Container.
>>  Perhaps once we begin to see some proposed objective functions we
>>  can better determine how large the Metric Container may need to
>> be. Perhaps the DAG Metric Container could be chained such that
>> each piece fits into 255 bytes or less...
>> 
>> -Tim
>> 
>> 
>> Joakim Eriksson wrote:
>>> Hi Peter,
>>> 
>>> I totally agree on the goal of minimizing packet sizes, but I 
>>> would like to keep alignment requirements since it simplifies 
>>> implementations. I also think (as you mention) that we need to 
>>> question the 16-bit sub-option length. Is it really needed? Both
>>>  IPv6 options and ICMPv6 option lenghts are encoded as 8-bit 
>>> values. Going down to 8-bits would also help the alignment of the
>>>  options.
>>> 
>>> 
>>> Best Regards, -- Joakim Eriksson, SICS
>>> 
>>> Peter Siklosi skrev:
>>>> Hi all,
>>>> 
>>>> 
>>>> 
>>>> If I understand correctly, RPL is designed to be usable with 
>>>> for instance 6LoWPAN on 802.15.4 with very limiting frame 
>>>> sizes. Even if 1280 byte IPv6 packets are of course supported 
>>>> using fragmentation, large packets should be avoided at all 
>>>> cost given the low bandwidth and low packet delivery success 
>>>> rate.
>>>> 
>>>> 
>>>> 
>>>> Given this, I do not understand the alignment requirements 
>>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following the
>>>>  convention in IPv6, these options are aligned in a packet such
>>>>  that multi-octet values within the Option Data field of each 
>>>> option fall on natural boundaries". It seems that it would be 
>>>> more important to keep the messages short and avoid padding 
>>>> options. I am also curious on allocating 16 bits for a length 
>>>> field of a sub option. If sub option length exceeding 255 bytes
>>>>  (as could be specified by 8 bits) are needed, it seems that 
>>>> the routing messages are expected to get very large.
>>>> 
>>>> 
>>>> 
>>>> Regards, Peter Siklosi
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ Roll mailing 
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>> _______________________________________________ Roll mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>> 
>> _______________________________________________ Roll mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>> 
> 
> _______________________________________________ Roll mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 Dec 2009 11:45:21 +0100

Well - make sure you know how much bandwidth you gain with this removal 
and how much additional computing power you require too.

Matteo Paris a écrit :
> As Peter wrote, if RPL is to work over constrained link layers, we have 
> to keep in mind the frame size and bandwidth constraints of those 
> layers.  For example, in 802.15.4 after link-layer overhead, the usable 
> payload is only 81 bytes (see RFC4944).

Well let 802.15.4 do its fragmentation when it feels so, don't interfere 
with it.

I mean (one should, IMHO, etc),

Alex

> case, it is desirable for a DIO message to fit in a single packet. The 
> current size of a DIO message not including the DAG Metric Container is 
> already 59 bytes (3 6lowpan ip header + 4 icmp header + 20 base option + 
> 25 dest prefix + 7 dag config).  Padding could increase this by tens of 
> bytes.  If the DAG Metric Container is longer than 255 bytes I think it 
> will pose serious challenges to RPL operation over constrained link layers.
> 
> Matteo
> 
> 
>> requirements-
>> Perhaps once we

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 Dec 2009 12:24:50 +0100

Alexandru Petrescu a écrit :
>> short enough that it would work reasonably well in a real system where 
>> the radio environment is less than optimal.
> 

I meant "is not 8byte-aligned" above (and not "is not byte-aligned").

Alex

>> fragments, and this does certainly not leave many bytes for say LoWPAN 
>> over 802.15.4.
> 
>>  compact, which I think is actually quite important. Padding makes the 
>> situation worse, not better.
> 
>>>> like to keep alignment requirements since it simplifies 
>>>>  IPv6 options and ICMPv6 option lenghts are encoded as 8-bit values. 
>>>> Going down to 8-bits would also help the alignment of the
>>>>  options.
>>>>
>>>>
>>>>> instance 6LoWPAN on 802.15.4 with very limiting frame sizes. Even 
>>>>> if 1280 byte IPv6 packets are of course supported using 
>>>>> fragmentation, large packets should be avoided at all cost given 
>>>>> the low bandwidth and low packet delivery success rate.
>>>>>
>>>>>
>>>>>
>>>>> option fall on natural boundaries". It seems that it would be more 
>>>>> important to keep the messages short and avoid padding options. I 
>>>>> am also curious on allocating 16 bits for a length field of a sub 
>>>>> option. If sub option length exceeding 255 bytes
>>>>>  (as could be specified by 8 bits) are needed, it seems that the 
>>>>> routing messages are expected to get very large.
>>>>>
>>>>>
>>>>>
>>>>> Regards, Peter Siklosi
>>>>>
>>>>>
>>>>>
>>>>>

---

From: "Peter Siklosi" <[email-masked]>
Date: Fri, 11 Dec 2009 12:29:10 +0100

Alex,

> I thought the shortest IPv6 packet could be 41 bytes [...]

I would not expect anyone to use uncompressed IPv6 in a low bandwidth radio network. This is what 6LoWPAN is all about, compressing the headers to reasonable sizes. Every byte is valuable. There is certainly no padding there.
 
> For example, I doubt removal of few bytes here and there are any gain

This may be your opinion. I do not agree.

> When you say "fragmented" - do you mean IP fragmentation (happening each 1280bytes) or link-layer fragmentation?
> Traditionally, IPdoesn't care about the latter - why should RPL care?

I mean fragmentation by 6LoWPAN for instance. RPL does not need to care, unless the goal is to get it working in real life.

Regards,
Peter

-----Ursprungligt meddelande-----
Från: Alexandru Petrescu [mailto:[email-masked]] 
Skickat: den 11 december 2009 11:43
Till: Peter Siklosi
Kopia: Alexandru Petrescu; [email-masked]
Ämne: Re: SV: [Roll] packet size issues

How do you see things?

Thinking over it...

Alex

---

From: Matteo Paris <[email-masked]>
Date: Fri, 11 Dec 2009 09:26:15 -0500

At 11:45 AM +0100 12/11/09, Alexandru Petrescu wrote:
>Well - make sure you know how much bandwidth you 
>gain with this removal and how much additional 
>computing power you require too.

Hi Alex, I quite agree.  I can offer my 
experience, which is a decade of working on a 
variety of commercial wireless LLNs.  Bandwidth 
and RAM have always been the dominant bottlenecks 
and computing power not a constraint.  The 
tradeoff may be different on other LLN platforms 
of course.  Are there any where one would trade 
bandwidth and RAM for processing speed?

As for fragmentation, due to medium acess 
overhead (at least in CSMA systems), and link 
layer header duplication, if a common packet like 
DIO goes from fitting into one packet to 
requiring fragmentation, it incurs a substantial 
discrete performance and scalability penalty on 
the lowpan

>Traditionally, IP doesn't care about [link layer 
>fragmentation] - why should RPL care?  ... let 
>802.15.4 do its fragmentation when it feels so, 
>don't interfere with it.

It would be nice if RPL did not need to care 
about the limitations of the link layer, but if 
we had that luxury there would be no need for 
roll and 6lowpan... and maybe that would be nice 
;-).  But in all seriousness, the roll charter 
addresses this issue explicitly:

" - In most cases, LLNs will be employed over link layers with
restricted frame-sizes, thus a routing protocol for LLNs should be
specifically adapted for such link layers."

Matteo

>
>Matteo Paris a écrit :
>>
>>I agree that we should remove alignment 
>>requirements and reduce the suboption length 
>>field to 1 byte.
>>
>>As Peter wrote, if RPL is to work over 
>>constrained link layers, we have to keep in 
>>mind the frame size and bandwidth constraints 
>>of those layers.  For example, in 802.15.4 
>>after link-layer overhead, the usable payload 
>>is only 81 bytes (see RFC4944).
>
>Well let 802.15.4 do its fragmentation when it 
>feels so, don't interfere with it.
>
>>Because limited bandwidth and large dense 
>>networks are a common use case, it is desirable 
>>for a DIO message to fit in a single packet. 
>>The current size of a DIO message not including 
>>the DAG Metric Container is already 59 bytes (3 
>>6lowpan ip header + 4 icmp header + 20 base 
>>option + 25 dest prefix + 7 dag config). 
>>Padding could increase this by tens of bytes. 
>>If the DAG Metric Container is longer than 255 
>>bytes I think it will pose serious challenges 
>>to RPL operation over constrained link layers.
>>
>>Matteo
>>
>>
>>>(energy/time/processing) to handle the 
>>>alignment issues in the implementation versus

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 Dec 2009 18:07:14 +0100

Peter Siklosi a écrit :
> I would not expect anyone to use uncompressed IPv6 in a low bandwidth
>  radio network.

Hmm... I used IPv6 over 2400baud serial lines, worked ok.  That's as low
bandwidth as it can get.

> This is what 6LoWPAN is all about, compressing the headers to
> reasonable sizes.

Well, I think 6LoWPAN is more than just that.  For example there is
6lowpan-nd which doesn't consider this header compression (not that I
know of).

> Every byte is valuable. There is certainly no padding there.

In a sense it makes sense that every byte is valuable.

But I also think there is paramount importance in being able to connect 
one such end-node to the Internet, i.e. to any other Internet node.  And 
that's impossible if you start talking removing padding, shortening IPv6 
addresses, etc.

This is a large topic of discussion and I think it's not currently settled.

> This may be your opinion. I do not agree.

Yes, we have disagreement.

>> When you say "fragmented" - do you mean IP fragmentation (happening
>>  each 1280bytes) or link-layer fragmentation? Traditionally, 
>> IPdoesn't care about the latter - why should RPL care?
> 
> I mean fragmentation by 6LoWPAN for instance. RPL does not need to 
> care, unless the goal is to get it working in real life.

If 6lowpan does fragmentation (a big if already) then why would one 
prefer to eliminate padding, or shorten the IPv6 packet length in the 
base header?

Alex

> 
> Regards, Peter
> 
> -----Ursprungligt meddelande----- Från: Alexandru Petrescu 
> [mailto:[email-masked]] Skickat: den 11 december 2009 
> 11:43 Till: Peter Siklosi Kopia: Alexandru Petrescu; [email-masked] 
>  in wireless bandwidth when considering that the base header alone is
> How much would one save compared to one _has_ to always send? 
> (between using or not using padding).
> 
>> I think it may be a challenge in the first place to get the 
>> messages short enough that it would work reasonably well in a real 
>> system where the radio environment is less than optimal.
> 
> 41 bytes is not byte-aligned, it would need an additional pad of 
> 8bytes, making it 48bytes.
> 
> When you say "fragmented" - do you mean IP fragmentation (happening 
> each 1280bytes) or link-layer fragmentation?  Traditionally, 
> IPdoesn't care about the latter - why should RPL care?
> 
>> I do not see so much focus in the draft on making the 
>> representations compact, which I think is actually quite important.
>>  Padding makes the situation worse, not better.
> 
> Well... padding comes from a requirement of matching packet buffers 
> to chip memory layout.  I believe today's smallest chipsets act like
>  its memory alignment and addressing, i.e. probably 32bits are 
> addressed only at 32bit edges, and not 8bit.  Thus padded packets may
>  help a lot when addressing bytes within memory.
> 
> Hmm... I believe this is wrong, because simplifying must happen on 
> all fronts not only the wireless communication part (i.e. the 
> computing power is also restrained).
> 
> Well I disagree.  If one touches _anything_ in the representation of 
> an IP address then one will no longer connect that node to the 
> Internet.
> 
>> If used on LoWPAN, I assume that context based compression would be
>>  a common case, since I assume that routing would typically be used
>> [mailto:[email-masked]] För Alexandru Petrescu Skickat: den 
>> 10 december 2009 01:09 Till: Tim Winter Kopia: [email-masked] Ämne: 
>> Re: [Roll] packet size issues
>> 
>> Tim Winter a écrit :
>>> I would expect that it is often cheaper (energy/time/processing) 
>>> to handle the alignment issues in the implementation versus 
>>> The 16-bit sub-option length is driven by the DAG Metric 
>>> Container. Perhaps once we begin to see some proposed objective 
>>> functions we can better determine how large the Metric Container 
>>> may need to be. Perhaps the DAG Metric Container could be chained
>>>> question the 16-bit sub-option length. Is it really needed? 
>>>> Both IPv6 options and ICMPv6 option lenghts are encoded as 
>>>> 8-bit values. Going down to 8-bits would also help the 
>>>> alignment of the options.
>>>> 
>>>> 
>>>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 "Following 
>>>>> the convention in IPv6, these options are aligned in a packet
>>>>>  such that multi-octet values within the Option Data field of
>>>>>  each option fall on natural boundaries". It seems that it 
>>>>> would be more important to keep the messages short and avoid 
>>>>> padding options. I am also curious on allocating 16 bits for 
>>>>> a length field of a sub option. If sub option length 
>>>>> exceeding 255 bytes (as could be specified by 8 bits) are 
>>>>> needed, it seems that the routing messages are expected to 
>>>>> get very large.
>>>>> 
>>>>> 
>>>>> 
>>>>> Regards, Peter Siklosi
>>>>> 
>>>>> 
>>>>> 
>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 Dec 2009 18:19:49 +0100

Michael Richardson a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
>>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
>     Alexandru> Hi, sorry - how much does one gain?  Figures?
> 
>     Alexandru> For example, I doubt removal of few bytes here and there
>     Alexandru> are any gain in wireless bandwidth when considering that
>     Alexandru> the base header alone is 40bytes already, the ICMP header
>     Alexandru> is 8 bytes fixed, and so on.
> 
>     Alexandru> How much would one save compared to one _has_ to always
>     Alexandru> send? (between using or not using padding).
> 
>   Padding is only there so that we can have nicely 64-bit aligned items.

Padding is there not only for beautifullness.  There are real 
constraints for computing - Alignment.

A processor trying to read a byte at an (memory) address which is not 
multiple of 4 will spend more cycles - ie more computing power, take 
longer, spend more energy.

If the data in the buffer _is_ aligned at the most common order (I 
believe  it to be 4 bytes now) then reading an arbitrary byte is much 
quicker.

Consider "processor" to not be the current i7, but something similar to 
a 4004 or so, which has strong alignment necessities.

> This is an IPv6 goal --- we can work with it, or work without it.

IPv7 anyone?

> The
> padding doesn't need to be there if the payloads are all multiples of
> 64-bits.

Hmm, in a sense it's very good to have no padding, but I hope the 
important bytes are going to be easy to locate and read, and not 
necessitate expensive shifting on processors having no shifter.

Absent that (please list the proc's on which RPL is going to work) - I 
prefer be conservative and keep padding.

>   The real overhead of the padding is the code space.

To me, the overhead of _not_ using padding is code space, cycles, energy 
consumed.

_Data_ space may be bigger when using padding.

> It's nice to have 
> a way to "NOP" out some pieces, particularly if you want to reuse the
> same memory that you received something (such as a DAO) when you send it
> again upwards.
> 
>     >> Messages should preferably travel unfragmented, or else as very
>     >> few fragments, and this does certainly not leave many bytes for
>     >> say LoWPAN over
>     >> 802.15.4.
> 
>     Alexandru> When you say "fragmented" - do you mean IP fragmentation
>     Alexandru> (happening each 1280bytes) or link-layer fragmentation?
>     Alexandru> Traditionally, IPdoesn't care about the latter - why
>     Alexandru> should RPL care?
> 
>   No, he means 6lowpan fragmentation, below layer-3.

I am not sure what 6lowpan fragmentation is.  I do know what IP 
fragmentation is.  Iprefer to consider the latter.  Avoid cross-layer 
violation.

> 
>     Alexandru> I.e. I think a small 8bit micro-controller has strong
>     Alexandru> requirements on its memory alignment and addressing,
>     Alexandru> i.e. probably 32bits are addressed only at 32bit edges,
>     Alexandru> and not 8bit.  Thus padded packets may help a lot when
>     Alexandru> addressing bytes within memory.
> 
>   Exactly.  32-bit accesses save power, and the only time we care about
> padding if if we create payloads that are not multiples of that...

Well, I agree.

Alex

> 
> 
> - -- 
> ]       He who is tired of Weird Al is tired of life!           |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
>    Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition. 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBSyJSI4CLcPvd0N1lAQKd6Af8CDkKbHctnOYAt7gS8V5jDcbzN2KO5yag
> qqjdwmsQY44WQAXRw942L4UaCq4/XQo1l8b4UdTHb2/nShy1EGkRIcfPHuoYrALd
> yQMsB6KAAfGeLkZK9+9O1hsKgV5U1q3HQxfFhx16p+t3jmwxbAiFS4DM5QehnfOb
> 1lfHrDQy3R/OCph3HNsBGBH8CoyAxUP8hLMAtRsVntGJsW9BgUkowODXMW/7QBGx
> NgnvcPvsdShHAz6t9mvICPJJbebHVUKUKSbqrlU1KIup7J5KL0spIQEViBsGP5oV
> FnozOJGwZa7eMCpN+LyjwCEV8OEQb5XPDddeODkah1MC9mHMXjzNWA==
> =aUlU
> -----END PGP SIGNATURE-----
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 11 Dec 2009 18:31:05 +0100

Matteo Paris a écrit :
>> Well - make sure you know how much bandwidth you gain with this 
>> removal and how much additional computing power you require too.
> 
> Hi Alex, I quite agree.  I can offer my experience, which is a decade of 
> working on a variety of commercial wireless LLNs.  Bandwidth and RAM 
> have always been the dominant bottlenecks and computing power not a 
> constraint.  The tradeoff may be different on other LLN platforms of 
> course.  Are there any where one would trade bandwidth and RAM for 
> processing speed?

Hm... thinking... I agree that bandwidth and RAM are bottlenecks 
(compared to computing power)... but it's also easy to plug a 500Mbit/s 
"n" wifi card on a very low cpu such as a 600MHz pentium, in which case 
the bottleneck is the processor.

I would not dare to eliminate padding and think IPv6 layout designers 
were not _already_ aware of any supposed relationships between 
bandwidth/cpu/ram.

> As for fragmentation, due to medium acess overhead (at least in CSMA 
> systems), and link layer header duplication, if a common packet like DIO 
> goes from fitting into one packet to requiring fragmentation, it incurs 
> a substantial discrete performance and scalability penalty on the lowpan
> 
>> Traditionally, IP doesn't care about [link layer fragmentation] - why 
>> should RPL care?  ... let 802.15.4 do its fragmentation when it feels 
>> so, don't interfere with it.
> 
> It would be nice if RPL did not need to care about the limitations of 
> the link layer, but if we had that luxury there would be no need for 
> roll and 6lowpan... and maybe that would be nice ;-).  But in all 
> seriousness, the roll charter addresses this issue explicitly:
> 

Right.  I take these constraints as indication that RPL packets 
shouldn't be too large.  For example I believe that's satisfied when we 
say we use ICMP instead of http.  But going towards shortening the IPv6 
address, or eliminating the base header, seems too much, IMHO.

Alex

>> Well let 802.15.4 do its fragmentation when it feels so, don't 
>> interfere with it.
>>
>>> increase this by tens of bytes. If the DAG Metric Container is longer 
>>> than 255 bytes I think it will pose serious challenges to RPL 
>>>>> implementations.

---

From: Kris Pister <[email-masked]>
Date: Mon, 14 Dec 2009 16:42:32 -0800

Joakim - can you say more about how important alignment is in 
simplifying implementations?
In my experience, alignment or its absence doesn't have a big impact on 
code complexity.
On the motes that I've used, in the 8 bit processors (e.g. AVR) memory 
access on byte boundaries is what you get.  On 16 bit processors (e.g. 
MSP430), there's support for byte operations.  On the 32 bit embedded 
processors (e.g. ARM7, Cortex-M3), there's a *lot* of support for byte 
and two-byte operations.

Alex - it's worth thinking about your energy question. 
The cost of sending a byte over the radio is on the order of 
(20mW)*(8bits)/(250kbps) = 640 nJ
The cost of a single processor cycle is on the order of (1mW/MHz)/(10^6 
cycles/MHz) = 1nJ
So from an energy perspective, we'd rather spend hundreds of cycles than 
send or receive a single byte.

ksjp

---

From: Joakim Eriksson <[email-masked]>
Date: Tue, 15 Dec 2009 09:20:43 +0100

The thing that can be made when data is aligned is mapping
(type-cast) the incoming data into structs without
risking that the struct is automatically "padded" for
alignment. If we do not have alignment in the packets this
is  impossible on processors above 8-bits.

Best regards,
-- Joakim Eriksson, SICS

Kris Pister skrev:
> Alex - it's worth thinking about your energy question. The cost of 
> sending a byte over the radio is on the order of

---

From: "Peter Siklosi" <[email-masked]>
Date: Tue, 15 Dec 2009 10:35:56 +0100

In general, I think that you can store data in a struct in whatever way you like and then have serialization and deserialization functions taking care of reading the received byte sequence and putting the right data into the struct and the other way around. These routines can also take care of byte ordering and other issues. Getting meshed LLN:s to work well can be a challenge in itself and making sure to keep the packets short helps. The ability to take some shortcuts in serialization/deserialization is a non-issue as far as I see it. It does not make sense to have 6LoWPAN trying very hard to reduce packet size and then waste it in RPL..

Regards,
Peter

-----Ursprungligt meddelande-----
Från: Joakim Eriksson [mailto:[email-masked]] 
Skickat: den 15 december 2009 09:21
Till: Kris Pister
Kopia: Peter Siklosi; [email-masked]
Ämne: Re: [Roll] packet size issues

Best regards,
-- Joakim Eriksson, SICS

---

From: Joakim Eriksson <[email-masked]>
Date: Tue, 15 Dec 2009 11:02:24 +0100

Peter Siklosi wrote:
> In general, I think that you can store data in a struct in 
 > whatever way you like and then have serialization and
 > deserialization functions taking care of reading the
 > received byte sequence and putting the right data into the
> struct and the other way around. These routines can also
 > take care of byte ordering and other issues. Getting
 > meshed LLN:s to work well can be a challenge in
 > itself and making sure to keep the packets short helps.
> The ability to take some shortcuts in serialization/deserialization
 > is a non-issue as far as I see it.

It is not a very big issue but it makes the code smaller and
more efficient (since there is no need for a copy/deserialization).

> It does not make sense to have 
 > 6LoWPAN trying very hard to reduce packet size and then waste it
 > in RPL.

I definitively agree with this. But I think that we can keep
alignment and avoid too much padding if we place the different
options and fields in smart ways.

How much padding would we currently get in a typical case (assuming
that we get rid of the already non-aligned 16-bit lenght of the sub-option)?

Best regards,
-- Joakim Eriksson, SICS

---

From: Paul Chilton <[email-masked]>
Date: Tue, 15 Dec 2009 10:24:12 +0000

My preference would be for byte alignment of all fields (ie bit padding 
if necessary) and serialize/deserialize access to the raw received 
packet.  The overhead of the extra code in my opinion is far outweighed 
by the need to keep the overall amount of redundant data transmitted in 
a frame to an absolute minimum both from the point of view of maximising 
payload space and in the worst case causing fragmentation

Joakim Eriksson wrote:
>> Från: Joakim Eriksson [mailto:[email-masked]] Skickat: den 15 
>> december 2009 09:21
>> Till: Kris Pister
>>> In my experience, alignment or its absence doesn't have a big impact 
>>> on code complexity.
>>> On the motes that I've used, in the 8 bit processors (e.g. AVR) 
>>> memory access on byte boundaries is what you get.  On 16 bit 
>>> processors (e.g. MSP430), there's support for byte operations.  On 
>>> the 32 bit embedded processors (e.g. ARM7, Cortex-M3), there's a 
>>> *lot* of support for byte and two-byte operations.
>>>
>>> The cost of a single processor cycle is on the order of 
>>> (1mW/MHz)/(10^6 cycles/MHz) = 1nJ
>>> So from an energy perspective, we'd rather spend hundreds of cycles 
>>> than send or receive a single byte.
>>>
>>> ksjp
>>>
>>> Joakim Eriksson wrote:
>>>> Hi Peter,
>>>>
>>>> sub-option length. Is it really needed? Both IPv6 options and 
>>>> ICMPv6 option lenghts are encoded as 8-bit values. Going down to 
>>>> 8-bits would
>>>>> option. If sub option length exceeding 255 bytes (as could be 
>>>>> specified by 8 bits) are needed, it seems that the routing

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Dec 2009 21:25:44 +0100

Peter Siklosi a écrit :
> In general, I think that you can store data in a struct in whatever
> way you like and then have serialization and deserialization
> functions taking care of reading the received byte sequence and
> putting the right data into the struct and the other way around.
> These routines can also take care of byte ordering and other issues.
> Getting meshed LLN:s to work well can be a challenge in itself and
> making sure to keep the packets short helps. The ability to take some
> shortcuts in serialization/deserialization is a non-issue as far as I
> see it. It does not make sense to have 6LoWPAN trying very hard to
> reduce packet size and then waste it in RPL..

WEll...

Which part of 6LoWPAN do you refer to to try very hard to reduce packet 
size?

6LoWPAN Header Compression draft-ietf-6lowpan-hc-06.txt?

Does that compress ICMP headers?  I don't think 6LoWPAN HC understands 
ICMP at all.  RPL uses ICMP.

I am not sure 6LoWPAN header compression is of any relevance outside 
802.15.4... whereas RPL sounded as if yes.

I am not sure header compression in general is of any use anywhere 
beyond one hop.  And of course I am not sure RPL subnet structure 
comprises more than one hop.  At which point I am not sure why is this 
about IP at all.  No IP addresses ('short' IP addresses), all within a 
single IP hop, no header alignment requirements - sounds as no IP at all.

I guess I am completely lost.

Alex

> 
> Regards, Peter
> 
> -----Ursprungligt meddelande----- Från: Joakim Eriksson
> [mailto:[email-masked]] Skickat: den 15 december 2009 09:21 Till:
> Kris Pister Kopia: Peter Siklosi; [email-masked] Ämne: Re: [Roll]
> packet size issues
> 
> (type-cast) the incoming data into structs without risking that the
> struct is automatically "padded" for alignment. If we do not have
> alignment in the packets this is  impossible on processors above
> 8-bits.
> 
> 
> Best regards, -- Joakim Eriksson, SICS
> 
> Kris Pister skrev:
>> simplifying implementations? In my experience, alignment or its
>> absence doesn't have a big impact on code complexity. On the motes
>> that I've used, in the 8 bit processors (e.g. AVR) memory access on
>> byte boundaries is what you get.  On 16 bit processors (e.g. 
>> MSP430), there's support for byte operations.  On the 32 bit
>> embedded processors (e.g. ARM7, Cortex-M3), there's a *lot* of
>> support for byte and two-byte operations.
>> 
>> (20mW)*(8bits)/(250kbps) = 640 nJ The cost of a single processor
>> cycle is on the order of (1mW/MHz)/(10^6 cycles/MHz) = 1nJ So from
>> an energy perspective, we'd rather spend hundreds of cycles than

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 16 Dec 2009 21:29:10 +0100

Kris Pister a écrit :
> byte boundaries is what you get.  On 16 bit processors (e.g. MSP430),
> there's support for byte operations.  On the 32 bit embedded 
> processors (e.g. ARM7, Cortex-M3), there's a *lot* of support for
> byte and two-byte operations.
> 
> cycle is on the order of (1mW/MHz)/(10^6 cycles/MHz) = 1nJ So from an
> energy perspective, we'd rather spend hundreds of cycles than send or
> receive a single byte.

Hmm... if so many cycles are available, at some extreme one could 
propose to encode the entire packet with BZIP2 and decode it upon 
reception.  That would save lots of bandwidth space.

What could prevent that from happening so?

And yes, I agree the energy consumption perspective is worth 
contemplating, thanks for the figures showing more energy is spent on 
sending than on computing.

Alex

>> Going down to 8-bits would also help the alignment of the options.
>> 
>> 
>>>  instance 6LoWPAN on 802.15.4 with very limiting frame sizes.
>>> Even if 1280 byte IPv6 packets are of course supported using
>>> specified in draft-ietf-roll-rpl-05 6.1.3.1.1.1 “Following the
>>> option fall on natural boundaries”. It seems that it would be

---

From: "Peter Siklosi" <[email-masked]>
Date: Thu, 17 Dec 2009 09:40:32 +0100

> Which part of 6LoWPAN do you refer to to try very hard to reduce packet size?

Yes.

> 802.15.4... whereas RPL sounded as if yes.

The total length of a frame is the sum of the parts of which it is built. To get a short total length, all parts should be as short as possible. 6LoWPAN takes care of the IP header and tries hard to make that short. The reason to try hard to make it short is that a short frame is important in an LLN. If this was not the case, there would be no need for header compression at all, and IPv6 frames could travel uncompressed.

What I am saying is that a chain is no stronger than the weakest link, if one part is compressed reasonably, while another part wastes bytes, this results in an unnecessary long frame. That is all.

> I am not sure header compression in general is of any use anywhere beyond one hop. And of course I am not sure 
> RPL subnet structure comprises more than one hop.

I do not follow you. The whole point of RPL is to be able to route more than one hop. If you only need only one hop, there is no need for RPL.

Regards,
Peter

-----Ursprungligt meddelande-----
Från: Alexandru Petrescu [mailto:[email-masked]] 
Skickat: den 16 december 2009 21:26
Till: Peter Siklosi
Kopia: Joakim Eriksson; Kris Pister; [email-masked]
Ämne: Re: [Roll] packet size issues

WEll...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 17 Dec 2009 14:13:32 +0100

Peter Siklosi a écrit :
>> Which part of 6LoWPAN do you refer to to try very hard to reduce
>> packet size? 6LoWPAN Header Compression
>> draft-ietf-6lowpan-hc-06.txt?
> 
> Yes.
> 
>> I am not sure 6LoWPAN header compression is of any relevance
>> outside 802.15.4... whereas RPL sounded as if yes.
> 
> The total length of a frame is the sum of the parts of which it is
> built. To get a short total length, all parts should be as short as
> possible. 6LoWPAN takes care of the IP header and tries hard to make
> that short. The reason to try hard to make it short is that a short
> frame is important in an LLN. If this was not the case, there would
> be no need for header compression at all, and IPv6 frames could
> travel uncompressed.
> 
> What I am saying is that a chain is no stronger than the weakest
> link, if one part is compressed reasonably, while another part wastes
> bytes, this results in an unnecessary long frame. That is all.

In a sense yes, if every part of the chain is non-compressed (header 
compression not applied) then the overall message length is longer.

But we couldn't request all protocols to shorten their payloads, could 
we. (ICMP is payload for IP, ICMP has its own payload, etc).

>> comprises more than one hop.
> 
> I do not follow you. The whole point of RPL is to be able to route
> more than one hop. If you only need only one hop, there is no need
> for RPL.

Hmm... but if RPL is about more than one hop, and header compression is 
usually happening over a single hop (ROHC), then I believe RPL and 
header compression are incompatible from the start.

Alex

> [mailto:[email-masked]] Skickat: den 16 december 2009
> 21:26 Till: Peter Siklosi Kopia: Joakim Eriksson; Kris Pister;
> [email-masked] Ämne: Re: [Roll] packet size issues
> 
> Peter Siklosi a écrit :
>> These routines can also take care of byte ordering and other
>> issues. Getting meshed LLN:s to work well can be a challenge in
>> itself and making sure to keep the packets short helps. The ability
>> to take some shortcuts in serialization/deserialization is a
>> non-issue as far as I see it. It does not make sense to have
>> 6LoWPAN trying very hard to reduce packet size and then waste it in
>> RPL..
> 
> WEll...
> 
> Does that compress ICMP headers?  I don't think 6LoWPAN HC
> understands ICMP at all.  RPL uses ICMP.
> 
> comprises more than one hop.  At which point I am not sure why is
> this about IP at all.  No IP addresses ('short' IP addresses), all
> within a single IP hop, no header alignment requirements - sounds as
> no IP at all.
> 
>>> absence doesn't have a big impact on code complexity. On the
>>> motes that I've used, in the 8 bit processors (e.g. AVR) memory
>>> access on byte boundaries is what you get.  On 16 bit processors
>>> (e.g. MSP430), there's support for byte operations.  On the 32
>>> bit embedded processors (e.g. ARM7, Cortex-M3), there's a *lot*
>>> of support for byte and two-byte operations.
>>> 
>>> Alex - it's worth thinking about your energy question. The cost
>>> of sending a byte over the radio is on the order of 
>>> cycle is on the order of (1mW/MHz)/(10^6 cycles/MHz) = 1nJ So
>>> from an energy perspective, we'd rather spend hundreds of cycles