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

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:
> 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
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>