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

From: Simon Bernard <[email-masked]>
Date: Thu, 2 Jul 2020 13:14:54 +0200

Hi all,

   I have several questions about block1 size negotiation.
   The specification <https://tools.ietf.org/html/rfc7959#section-2.9.3> 
says :

    The present specification allows the server to return this response
    code (4.13) at any time during a Block1 transfer to indicate that it does
    not currently have the resources to store blocks for a transfer that
    it would intend to implement in an atomic fashion.  It also allows
    the server to return a 4.13 response to a request that does not
    employ Block1 as a hint for the client to try sending Block1.

    Finally, a 4.13 response to a request with a Block1 Option (control
    usage, seeSection 2.3  <https://tools.ietf.org/html/rfc7959#section-2.3>) where the response carries a smaller SZX in
    its Block1 Option is a hint to try that smaller SZX.

   So if a client send a block1 request and server can not handle a so 
big block it can answer with 4.13 + block1 with szx option. This means 
sends me smaller block (size is given in szx option).

   1) Could this kind of negotiation happen in a middle of a block1 
transfer ? or any block size negotiation (even negotiation which does 
not use 4.13) should always be done on first exchange ?

    Now Imagine a client which sends a normal (not block1) request with 
a too large payload and server want this payload be sent by block1.

   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 ?

    The more straightforward way seems to be "4.13 +block1 with szx 
option" this way this is clear that server support block1 and it gives 
the exact size of block it want. But the rfc sounds to consider this way 
only if original request is block1 too.

Thank you,

Simon

---

From: Achim Kraus <[email-masked]>
Date: Wed, 8 Jul 2020 10:24:47 +0200

Hi list,

over the last 3 years the two eclipse open source projects leshan
(LwM2M) and Californium (CoAP/DTLS) have received a couple of request to
implement a blockwise failover for 4.13.

Simon prepared now a PR to close this GAP. Doing so, he found, that
changing the blocksize in the middle of a transfer is easy as well.

But there my concerns have started. I don't want to create a gap in the
interoperability!

RFC 7959, section 2.0, page 7

"(If the first request uses a bigger block size than the receiver
prefers, subsequent requests will use the preferred block size.) "

section 2.3, page 11

"(The effect is that, if the server uses the smaller of (1) its
preferred block size and (2) the block size requested, all blocks for a
body use the same block size.)"

section 2.5, page 14

"Note that any reduction in the block size may mean that the second
request starts with a block number larger than one, as the first
request already transferred multiple blocks as counted in the smaller
size."

FMPOV, that are all indicators to change the blocksize only with the
first exchange. But I also miss the concrete statement about that.
So, did I overread something? What was the intention, at which exchange
should the blocksize be adapted?

For the other question about using block1 in the response without using
it in the request, I found:

section 2.5, page 15

"(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.)"

Thanks in advance!

Best regards
Achim Kraus

Am 02.07.20 um 13:14 schrieb Simon Bernard:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Achim Kraus <[email-masked]>
Date: Wed, 22 Jul 2020 09:56:57 +0200

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?)

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?

best regards
Achim Kraus

-------- Weitergeleitete Nachricht --------
Betreff: Re: [core] block1 size negotiation with 4.13 Request Entity Too
Large
Datum: Wed, 8 Jul 2020 10:24:47 +0200
Von: Achim Kraus <[email-masked]>
An: [email-masked] WG <[email-masked]>

Hi list,

section 2.3, page 11

section 2.5, page 14

section 2.5, page 15

Thanks in advance!

Best regards
Achim Kraus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jul 2020 13:08:19 +0200

Hi Achim,

Good questions.

> On 2020-07-22, at 09:56, Achim Kraus <[email-masked]> wrote:
> 
> Dear list,
> 

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.

> 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

---

From: Simon Bernard <[email-masked]>
Date: Wed, 22 Jul 2020 14:43:14 +0200

Thx Carsten for the answer.

This is clearer to me.
Some last point which is still not clear to me.

If a client send a request and a server answer with 4.13 without any 
option (no block1 no size1).
Should the client try to send the same request using block1 ? or as 
there is not a block1 option in the response it should not try to do 
that and just consider the request as a failure.

---

From: Achim Kraus <[email-masked]>
Date: Wed, 22 Jul 2020 15:20:03 +0200

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?

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.

Sure, if no-one else has doubts, go for it.

best regards
Achim Kraus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jul 2020 15:23:21 +0200

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

> 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

---

From: Simon Bernard <[email-masked]>
Date: Wed, 22 Jul 2020 15:33:51 +0200

It seems to me that the "normal" use case is to negotiate on first block.
Later negotiation could almost be consider as kind of bug. I can not see 
what could be the purpose of this ?

In another hand, supporting later negotiation sounds to not so hard to 
implement (maybe easier than rejected it). This also avoid the need to 
define how to behave if foreign peer try to do this kind of late 
negotiation.

Le 22/07/2020 à 15:20, Achim Kraus a écrit :
>> 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.
>>
>> 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
>>
>

---

From: Achim Kraus <[email-masked]>
Date: Wed, 22 Jul 2020 15:36:51 +0200

Hi Carsten,

thanks again!

 > This was intended.

OK, then go for it.

best regards
Achim Kraus