Re: [core] block1 size negotiation with 4.13 Request Entity Too Large

[Achim Kraus <[e-mail]>]

Hi Carsten
Hi List,

sorry for that late follow up of that question from last summer.
Currently I try to cleanup that code in Californium.
Doing so, I'm not sure, what the intended behaviour in the following
scenario should be:
- the client starts with a request "GET block2(num=5, size=256)".
- the server is configured to send blocks only up to 64 bytes.

If that exchange would happen at num=0, it works fine to send just a
smaller response, but with "num=5", I'm not sure, what is intended.
So, does this result in:

- the server respond with "CONTENT block2(num=?, size=64)"
   the issue with that is in my opinion, that either the "num" must
   be changed, or the offset can not longer calculated by
   option.num * option.size. To change the "num" may cause issues,
   though that "num" seems to be used to ACK the blocks.

- the server respond with an error; but which one should be used?

best regards
Achim

Am 22.07.20 um 15:23 schrieb Carsten Bormann:
> On 2020-07-22, at 15:20, Achim Kraus <[e-mail]> wrote:
>>
>> Hi Carsten,
>>
>> thanks a lot!
>>
>>> So it is not forbidden to request a smaller block size later.
>>
>> My point is,
>> - was this intented or
>> - just not considered and therefore not explicitly forbidden?
>
> This was intended.  A Stateless server may simply not know what it did before.  It might of course simply give up if the block number is ≠ 0, but we gave it a little more freedom, at the cost of maybe causing a bit more coding for clients that want to cope with these highly stateless servers.
>
>> All examples and some text points more into the direction, that it is
>> intended to be negotiated only in the 1. exchange. I'm still not
>> convinced, I think to forbid this is the better approach.
>
> I don’t know why the server would keep its preferences secret up to a few blocks into the transfer unless it is of the above kind and faces a sudden resource shortage.
>
> Grüße, Carsten
>
>
>>
>> Sure, if no-one else has doubts, go for it.
>>
>> best regards
>> Achim Kraus
>>
>> Am 22.07.20 um 13:08 schrieb Carsten Bormann:
>>> Hi Achim,
>>>
>>> Good questions.
>>>
>>>> On 2020-07-22, at 09:56, Achim Kraus <[e-mail]> wrote:
>>>>
>>>> Dear list,
>>>>
>>>> I would really appreciate, if the detail questions about the 4.13
>>>> failover could be answered!
>>>>
>>>> Without answers, I'm still afraid, that implementations will became
>>>> "overcomplicated" and "less interoperable".
>>>>
>>>> 1. is it intended to change the block size only in the first exchange?
>>>> Or on other exchanges? (Additionally, if changing later is considered as
>>>> failure, how should that failure be handled/processed?)
>>>
>>> RFC 7959 says (Section 2):
>>>
>>>     In most cases, all blocks being transferred for a body (except for
>>>     the last one) will be of the same size.  (If the first request uses a
>>>     bigger block size than the receiver prefers, subsequent requests will
>>>     use the preferred block size.)  The block size is not fixed by the
>>>     protocol. […]
>>>
>>> Simon cited some more text, but this is about too many blocks, not about too big blocks.  So it is not forbidden to request a smaller block size later.  I would expect that this is a rather unusual case, so I would not be surprised if a client gives up if this happens in mid-transfer.  On the other hand, it is also not hard to enable a client to adapt.
>>>
>>>> 2. is it intended, that a 4.13 response without block1 option to a
>>>> request also without block1 option, should also use/try a failover with
>>>> a request with block 1 option?
>>>
>>> That’s what RFC 7959 says:
>>>
>>>     The error code 4.13 (Request Entity Too Large) can be returned at any
>>>     time by a server that does not currently have the resources to store
>>>     blocks for a block-wise request payload transfer that it would intend
>>>     to implement in an atomic fashion.  (Note that a 4.13 response to a
>>>     request that does not employ Block1 is a hint for the client to try
>>>     sending Block1, and a 4.13 response with a smaller SZX in its Block1
>>>     Option than requested is a hint to try a smaller SZX.)
>>>
>>> This is phrased as a note, because the response contains a hint; there is no requirement that Block1 is supported.
>>>
>>> Simon also asked:
>>>
>>>>    2) What exactly should send the server ? 4.13 or 4.13 + block1 with szx option ? is size1 should be used to guess the correct block size ?
>>>
>>> I would expect that the server should send the desired block size if it wants the client to change from the block size it used, so 4.13 + Block1.  Size1 is not about block size, but about the size of the whole body - if the server has a limitation there, it might want to error out on a 4.13 (without a Block1 option).
>>>
>>> Grüße, Carsten
>>>
>>
>