Subject: [core] Question about the block options

From: Linyi Tian <[email-masked]>
Date: Tue, 09 Nov 2010 10:10:23 +0800

Hi, Z. Shelby and C. Bormann

I am not sure whether this has been discussed since I am new to this group.
If it was discussed, please point to me the previous thread then I can have
a review myself. 

My question is related to the block size and length of block numbers.
1. Why the maximum for the block is 2048? How it is decided? Since in the
charter we also mentioned that even though CoAP is designed for constrained
environment it may also be used in general IP environment. Do you think we
can increase this size?
2. Do you think that the NUM filed is too long? Is there real scenario the
data will be divided into 2^20 pieces? Do you think that in most cases the
below first two options would be enough? If that is the case, is it
reasonable to further reduce the length of NUM field?

          0 1 2 3 4 5 6 7
          +-+-+-+-+-+-+-+-+
          |  NUM  |M| SZX |
          +-+-+-+-+-+-+-+-+

           0                   1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |          NUM          |M| SZX |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           0                   1                   2
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                   NUM                 |M| SZX |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 1: Block option

Cheers,
Linyi

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Nov 2010 10:44:45 +0800

Hi Linyi,

thanks for looking into the document.

> 	• Why the maximum for the block is 2048? How it is decided? Since in the charter we also mentioned that even though CoAP is designed for constrained environment it may also be used in general IP environment. Do you think we can increase this size?

This came out because of the simple fact that we allocated three bits to the size, so in a power-of-two regime we can span a size range of 1:2^7 or 1:128.  Less than 16 didn't seem very useful, so the largest size became 16*128 = 2048.  I don't see a use case for that value; 1024 is the more likely upper bound given that we don't have Path MTU discovery.

(Note that the current layout of the option allows you to compute the start address in bytes simply as (block & ~0xf) << (block & 0x7) once you have decoded the option as a variable-length unsigned integer; changing the layout might make this decoding slightly more complex.)

> 	• Do you think that the NUM filed is too long?

No.  12 bits seemed somewhat limiting, so we did allow for the next higher size (24 bits, of which 20 bits are the block number) as well.  I don't think anybody will transfer a million blocks in a row using CoAP, though...

In a constrained implementation, you would likely only implement as much as your largest resource would need.
If no resource is 64 KiB or larger, the first two sizes will suffice.  But if you plan to use this for firmware updates, the third byte might find use.

Gruesse, Carsten

> Is there real scenario the data will be divided into 2^20 pieces? Do you think that in most cases the below first two options would be enough? If that is the case, is it reasonable to further reduce the length of NUM field?
> 
> 
>            0 1 2 3 4 5 6 7
>           +-+-+-+-+-+-+-+-+
>           |  NUM  |M| SZX |
>           +-+-+-+-+-+-+-+-+
> 
>            0                   1
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Linyi Tian <[email-masked]>
Date: Tue, 09 Nov 2010 11:21:56 +0800

Hi, Carsten Bormann

Ok. Now I understand. I misunderstood this block as application layer
fragmentation. 

So this design will make each CoAP block fits one UDP package (e.g. MTU
1480). Then the block size makes perfect sense ranged from 16 to 2048.

I agree with you 2^12 NUM would not be enough for firmware update case.

Thanks a lot for your prompt response.

Cheers,
Linyi

On 10-11-9 上午10:44, "Carsten Bormann" <[email-masked]> wrote:

>> ・ Why the maximum for the block is 2048? How it is decided? Since in the
> This came out because of the simple fact that we allocated three bits to the
> size, so in a power-of-two regime we can span a size range of 1:2^7 or 1:128.
> Less than 16 didn't seem very useful, so the largest size became 16*128 =
> 2048.  I don't see a use case for that value; 1024 is the more likely upper
> bound given that we don't have Path MTU discovery.
> 
> (Note that the current layout of the option allows you to compute the start
> address in bytes simply as (block & ~0xf) << (block & 0x7) once you have
> decoded the option as a variable-length unsigned integer; changing the layout
> might make this decoding slightly more complex.)
> 
>> ・ Do you think that the NUM filed is too long?
> 
> No.  12 bits seemed somewhat limiting, so we did allow for the next higher
> size (24 bits, of which 20 bits are the block number) as well.  I don't think
> anybody will transfer a million blocks in a row using CoAP, though...
> 
> If no resource is 64 KiB or larger, the first two sizes will suffice.  But if
> you plan to use this for firmware updates, the third byte might find use.
> 
> Gruesse, Carsten
> 
> 
>> Is there real scenario the data will be divided into 2^20 pieces? Do you
>> think that in most cases the below first two options would be enough? If that
>> is the case, is it reasonable to further reduce the length of NUM field?
>> 
>> 
>>            0 1 2 3 4 5 6 7
>>           +-+-+-+-+-+-+-+-+
>>           |  NUM  |M| SZX |
>>           +-+-+-+-+-+-+-+-+
>> 
>>            0                   1