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

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 29 Apr 2011 15:34:57 +0000

Dear Carsten, dear CORE list

The block sizes have a strong impact on how to dimension the buffers of the application, OS, and network stack.
I figured that the current scheme, using powers of two, does not provide many useful choices for the implementation.
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.

Although it would ruin the beauty of the current calculation and require more bits, maybe multiples of 32 or even a lookup table with "reasonable values" might be a better option.
What do you think?

Best regards
Matthias

---

From: "Charles Palmer" <[email-masked]>
Date: Fri, 29 Apr 2011 17:33:05 +0100

Hi all

Matthias makes a reasonable point.

Could I suggest that the block number field NUM is considered at the same time. 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. (Of course, if the SZX field takes more bits then the arithmetic changes...)

Regards - Charles Palmer

-----Original Message-----
From: [email-masked] on behalf of Kovatsch  Matthias
Sent: Fri 29/04/2011 16:34
To: [email-masked]
Subject: [core] CoAP block sizes: power of two might not be optimal

Best regards
Matthias
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

--------------------------------
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.
--------------------------------