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

[Carsten Bormann <[e-mail]>]

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