Subject: Re: [core] CoAP block sizes: power of two might not be optimal

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 May 2011 20:20:49 +0200

Hi Matthias,

thanks for the feedback (and sorry for the delayed response).
Indeed, Block currently is strongly biased towards simplicity, as opposed to ultimate efficiency.
The assumption is that most transfers will be simple, and block-wise is more the exception for special things such as discovery and firmware updates.
So, on a 6LoWPAN device, 64 will indeed be close enough for most applications.

Gruesse, Carsten

(Oh, and:)

> While 64 appears to be a good choice for 15.4 frames, the next larger size 128 might already be too large for devices with very constrained memory. From 256 onwards, it becomes demanding for the IP fragmentation buffer of every hop.

JFYI, the size of the L3 packet is not very relevant for the adaptation layer fragmentation buffers (did you mean these?) of 6LoWPAN routers, as is documented in the LWIG Guidance Internet-Draft soon to be out (or in the 6LoWPAN book).  Excerpt:

3.1.1.  Fragmentation in a 6LoWPAN Route-Over Configuration

   [...]

   6LoWPAN [RFC4944] is an adaptation layer that maps IPv6 with its
   minimum MTU of 1280 bytes to IEEE 802.15.4, which has a physical
   layer MTU of only 127 bytes (some of which are taken by MAC layer and
   adaptation layer headers).  Therefore, the adaptation layer provides
   a fragmentation and reassembly scheme that can fragment a single IPv6
   packet of up to 1280 bytes into multiple adaptation layer fragments
   of up to 127 bytes each (including MAC and adaptation layer
   overhead).

   In a route-over configuration, implementing this adaptation layer
   fragmentation scheme straightforwardly means that reassembly and then
   fragmentation are performed at each forwarding hop.  As fragments
   from several packets may be arriving interleaved with each other,
   this approach requires buffer space for multiple MTU-size IPv6
   packets.

   In a mesh-under configuration, adaptation layer fragments can be
   forwarded independently of each other.  It would be preferable if
   something similar were possible for route-over.  Complete
   independence in adaptation layer fragment forwarding is not possible
   for route-over, however, as the layer-3 addresses needed for
   forwarding are in the initial bytes of the IPv6 header, which is
   present only in the first fragment of a larger packet.

   Instead of performing a full reassembly, implementations may be able
   to optimize this process by not keeping a full reassembly buffer, but
   just a runt buffer for each packet that caches just the datagram_tag
   field (as usual combined with the sender's link layer address, the
   destination's link layer address and the datagram_size field) and the
   IPv6 header including the relevant addresses.  Initial fragments are
   then forwarded independently (after header decompression/compression)
   and create a runt reassembly buffer.  Non-initial fragments (which
   don't require header decompression/compression in 6LoWPAN) are
   matched against the runt buffers by datagram_tag etc. and forwarded
   if an IPv6 address is available.  (This simple scheme may be
   complicated a bit if header decompression/compression of the initial
   fragment causes an overflow of the physical MTU; in this case some
   overflow data may need to be stored in the runt buffers to be
   combined with further fragments or may simply be forwarded as a
   separate additional fragment.)

   If non-initial fragments arrive out of order before the initial
   fragment, a route-over router may want to keep the contents of the
   non-initial fragments until the initial fragment is available, which
   does need some buffer space.  If that is not available, a more
   constrained route-over router may simply discard out-of order non-
   initial fragments, possibly taking note that there is no point in
   forwarding any more fragments with the same combination of 6LoWPAN
   datagram_tag field, L2 addresses and datagram_size.

   Runt buffers should time out like full reassembly buffers, and may
   either keep a map of fragments forwarded or they may simply be
   removed upon forwarding the final fragment, assuming that no out-of-
   order fragments will follow.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 May 2011 20:22:37 +0200

On Apr 29, 2011, at 18:33, Charles Palmer wrote:

> In particular, would there ever be a need for a 3-byte Block Option, with a 20-bit block number field? Two bytes with a 12-bit NUM field supports 64k byte resource representations even with the smallest 16-byte block size.

64KiB may not be enough for one application that is often mentioned: Firmware upgrades.
So we put in the 3-byte version to be on the safe side.  Of course, if all your resources are smaller, you don't have to implement it!

Gruesse, Carsten

---

From: "Charles Palmer" <[email-masked]>
Date: Tue, 3 May 2011 20:27:36 +0100

Hi Carsten

OK - I've re-read the documents. A 3-byte Block Option does not violate the constraint "A CoAP message...MUST fit within a single IP datagram" because we are transferring large "resource representations" rather than large "messages". (Each block has a different Message ID, though the same Token...) With respect to your comment on firmware upgrades, I guess the Block Option is almost providing TFTP. 

Hmmm... Google led me on to the "Sorcerer's Apprentice Syndrome" - which I trust is a problem we don't have ;-) Too late for me to figure this out....
http://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome

Regards - Charles

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tue 03/05/2011 19:22
To: Charles Palmer
Cc: Kovatsch  Matthias; [email-masked]
Subject: Re: [core] CoAP block sizes: power of two might not be optimal

Gruesse, Carsten

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email message may contain confidential and/or privileged information, and
is intended solely for the addressee(s). If you have received this email in     
error, please notify Onzo immediately. Unauthorised copying, disclosure or 
distribution of the material in this email is forbidden.
--------------------------------

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 3 May 2011 19:29:27 +0000

Hello Carsten

Okay, thanks. Yes, for such an implementation only the fragmentation buffer size at the endpoints and border router is affected. In general, I prefer fragmentation over blockwise transfer where possible, as half of the messages can be saved...
More flexible sizes would just allow to make the best out of the message buffer a device can provide. I guess it is one of the most important tweaking parameters to make an application fit the constrained RAM.

Maybe to add another use case: I can imagine configuration updates with multiple JSON-encoded parameters that won't fit the affordable buffer. These might happen much more frequently than the 'famous' firmware updates.

Bye
Matthias

> -----Ursprüngliche Nachricht-----
> Von: Carsten Bormann [mailto:[email-masked]]
> Gesendet: Dienstag, 3. Mai 2011 20:21
> An: Kovatsch Matthias
> Cc: [email-masked]
> Betreff: Re: [core] CoAP block sizes: power of two might not be optimal
> 
> Hi Matthias,
> 
> The assumption is that most transfers will be simple, and block-wise is more
> the exception for special things such as discovery and firmware updates.
> > While 64 appears to be a good choice for 15.4 frames, the next larger size
> 128 might already be too large for devices with very constrained memory.
> From 256 onwards, it becomes demanding for the IP fragmentation buffer of
> every hop.
> 
> JFYI, the size of the L3 packet is not very relevant for the adaptation layer
> fragmentation buffers (did you mean these?) of 6LoWPAN routers, as is
> documented in the LWIG Guidance Internet-Draft soon to be out (or in the
> 6LoWPAN book).  Excerpt:
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 May 2011 21:36:27 +0200

On May 3, 2011, at 21:27, Charles Palmer wrote:

>  I guess the Block Option is almost providing TFTP.

Well, it is solving a related problem, but not using the stateful mechanics of TFTP.

> Hmmm... Google led me on to the "Sorcerer's Apprentice Syndrome" - which I trust is a problem we don't have ;-)

No, the protocol doesn't.
(An improperly done implementation might still have it.)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 May 2011 21:43:51 +0200

> Maybe to add another use case: I can imagine configuration updates with multiple JSON-encoded parameters that won't fit the affordable buffer. These might happen much more frequently than the 'famo…

Can you give me an idea of the Probability Distribution of the size of those representations?

What is your favorite payload block size?

(You could always fragment multiple JSON parameters on the application layer, BTW.  But that, of course, means that you have to add any crypto you may need to each of the fragments.)

Gruesse, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 3 May 2011 19:55:44 +0000

Hi

> > Maybe to add another use case: I can imagine configuration updates with
> multiple JSON-encoded parameters that won't fit the affordable buffer.
> These might happen much more frequently than the 'famous' firmware
> updates.
> 

Sorry, for that I don't have enough different applications so far.

> What is your favorite payload block size?

The 160 B block would be a nice one as it is roughly the buffer size the common 8-10 kB RAM platforms can afford and it roughly maxs out two fragments for 15.4 frames.

> 
> (You could always fragment multiple JSON parameters on the application
> layer, BTW.  But that, of course, means that you have to add any crypto you
> may need to each of the fragments.)

Yes, splitting the parameters is always an option. Keeping the configuration together in one set/file, however, is very convenient.

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 May 2011 22:06:46 +0200

On May 3, 2011, at 21:55, Kovatsch Matthias wrote:

> 160 B 

That's only 25 % larger than 128.

My "premature optimization" warning bell just went off :-)

Gruesse, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 3 May 2011 20:09:46 +0000

> My "premature optimization" warning bell just went off :-)

Ok, fine. Let's see what the future holds! :)