Subject: [core] Combined 4.13 response with Block Option?

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 6 Apr 2011 16:11:52 +0200

Dear all / authors of block-02,

looking at the core-block-02 draft; a server can indicate a preferred (e.g. smaller) block size to a client in response to a blockwise PUT (see Figure 9). This is nice but the examples (i.e. Fig 9) show only the case that the server was capable of processing the  entire first block (of 128 bytes, which is larger than the server's preference) correctly. What about a case where the server is only willing to process smaller blocks e.g. max 64 bytes at a time?  Of course the server can respond with error code 4.13 as indicated in the draft. However, the client could understand 4.13 as "no resources at this moment to support any more block operations" and then give up. What the server maybe wants to tell is "I can process 64 byte blocks at most at a time, if you want retry this with a block size <= 64".

Question is: is it allowed for the server to optionally include a Block Option in a 4.13 error response, to indicate the max block size that is supported ?

I assume here that, even though a PUT request was correctly received, the server for some implementation reason is unwilling to process a block that large in one go.

best regards,
Esko Dijk

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Likepeng <[email-masked]>
Date: Thu, 07 Apr 2011 01:06:23 +0000

>What the server maybe wants to tell is “I can process 64 byte blocks at most at a time, if you want retry this with a block size <= 64”.
If the server can’t accept 64 byte, which is part of the resource, what is the use case to receive an even smaller part of the resource?

>Question is: is it allowed for the server to optionally include a Block Option in a 4.13 error response, to indicate the max block size that is supported ?
Currently the draft supports the indication of preferred block size in the response, which seems to be enough.

Kind Regards
Kepeng
发件人: [email-masked] [mailto:[email-masked]] 代表 Dijk, Esko
发送时间: 2011年4月6日 22:12
收件人: [email-masked]
主题: [core] Combined 4.13 response with Block Option?

looking at the core-block-02 draft; a server can indicate a preferred (e.g. smaller) block size to a client in response to a blockwise PUT (see Figure 9). This is nice but the examples (i.e. Fig 9) show only the case that the server was capable of processing the  entire first block (of 128 bytes, which is larger than the server’s preference) correctly. What about a case where the server is only willing to process smaller blocks e.g. max 64 bytes at a time?  Of course the server can respond with error code 4.13 as indicated in the draft. However, the client could understand 4.13 as “no resources at this moment to support any more block operations” and then give up. What the server maybe wants to tell is “I can process 64 byte blocks at most at a time, if you want retry this with a block size <= 64”.

best regards,
Esko Dijk

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 8 Apr 2011 09:58:08 +0200

Dear Kepeng,

there are probably not many use cases that would require this feature. However my thinking was that because implementation of this feature (“respond 4.13 with Block Option”) is fully optional at both client and server sides, it would not hurt to include it in the spec ?

And I have a use case in mind: a wireless constrained server S that is connected via a slow serial link to a legacy device, say 1200 bps similar to the DALI protocol. The firmware of the legacy device is to be updated in blocks via CoAP, where S relays the data then on to the serial line using a custom protocol. Now a client might foolishly decide to send a PUT request to S with a 1024 byte block. S does have memory to temporarily buffer the large 1024 byte block, but it takes up too much resources for a too long time. To get a simple implementation and guaranteed reliable operation of S during the firmware update, S prefers 64 byte blocks and does not want to keep large blocks in memory.  In the current CoAP-block draft, there is no way for S to indicate this; currently if I’m correct S can either 1) respond error 4.13 or 2) ACK with a success code after it has processed the entire 1024 byte first block. (as in Fig 9)

Of course another, easier, solution here is that all my CoAP clients are pre-configured to only use 64-byte blocks in the first place. But in a multi-vendor situation, one can not be sure that this type of configuration is possible ;)

best regards,
Esko

From: Likepeng [mailto:[email-masked]]
Sent: Thursday 7 April 2011 3:06
To: Dijk, Esko; [email-masked]
Subject: Re: Combined 4.13 response with Block Option?

Kind Regards
Kepeng

best regards,
Esko Dijk

---

From: Likepeng <[email-masked]>
Date: Mon, 11 Apr 2011 03:29:12 +0000

Personally I don’t think it is quite useful. But let’s hear other’s opinion.

Kind Regards
Kepeng
From: Dijk, Esko [mailto:[email-masked]]
Sent: Friday, April 08, 2011 3:58 PM
To: Likepeng; [email-masked]
Subject: RE: Combined 4.13 response with Block Option?

Dear Kepeng,

best regards,
Esko

Kind Regards
Kepeng

best regards,
Esko Dijk

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 19 Apr 2011 11:29:10 +0200

Dear Kepeng, all, authors,

a simpler alternative to what I proposed (“4.13 response with Block Option”) is for the server, who does not wish to accept a large block (even if it is the first block of a sequence only), to use the 4.13 error response as specified in the coap-05 I-D, section 3.1.1.  This could be interpreted by the client as “the request I sent was too large” so the client may decide to try a smaller request message (i.e. decrease the block size by some self-chosen amount).

No protocol changes are required here, it’s already in. To avoid confusion as to what the 4.13 response means in this case (this case kind of falls between coap-05 and block-02 currently – the interpretation of 4.13 upon first block request depends on which I-D you refer to!), a sentence could be added in block-02 ;

<original text>
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 PUT or
POST transfer that it would intend to implement in an atomic fashion.

<proposed additional text >
The error code 4.13 (Request Entity Too Large) MAY also be returned by a server in response to a first block request to indicate that the block size is larger than it is currently willing to handle, or that the first block request payload was truncated, even though the server does currently have the resources for completing the intended block-wise transfer. The client MAY then retry the first block request using a smaller block size.

best regards,

Esko

From: Likepeng [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday 11 April 2011 5:29
To: Dijk, Esko; [email-masked]<mailto:[email-masked]>
Subject: RE: Combined 4.13 response with Block Option?

Kind Regards
Kepeng
From: Dijk, Esko [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, April 08, 2011 3:58 PM
To: Likepeng; [email-masked]<mailto:[email-masked]>
Subject: RE: Combined 4.13 response with Block Option?

Dear Kepeng,

best regards,
Esko

From: Likepeng [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday 7 April 2011 3:06
To: Dijk, Esko; [email-masked]<mailto:[email-masked]>
Subject: Re: Combined 4.13 response with Block Option?

Kind Regards
Kepeng
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> 代表 Dijk, Esko
发送时间: 2011年4月6日 22:12
收件人: [email-masked]<mailto:[email-masked]>
主题: [core] Combined 4.13 response with Block Option?

best regards,
Esko Dijk

---

From: Likepeng <[email-masked]>
Date: Wed, 20 Apr 2011 00:54:00 +0000

Hi Esko,

You proposed text excludes one situation: during the transmission, for example, after several blocks, the recipient finds out that it has no storage for the rest of the blocks, then it returns 4.13: Request Entity Too Large.

>The error code 4.13 (Request Entity Too Large) MAY also be returned by a server in response to a first block request to indicate that the block size is larger than it is currently willing to handle
In this case, the server can return a smaller block size in the response, instead of an error code.

>or that the first block request payload was truncated, even though the server does currently have the resources for completing the intended block-wise transfer.
It is fine for the server to truncate the first block request payload. This is not an error.

Kind Regards
Kepeng
From: Dijk, Esko [mailto:[email-masked]]
Sent: Tuesday, April 19, 2011 5:29 PM
To: Likepeng; [email-masked]
Subject: RE: Combined 4.13 response with Block Option?

<original text>

best regards,

Esko

Kind Regards
Kepeng

Dear Kepeng,

best regards,
Esko

Kind Regards
Kepeng

best regards,
Esko Dijk

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 20 Apr 2011 13:20:23 +0200

Hello Kepeng,

> You proposed text excludes one situation: during the transmission, for example, after several blocks, the recipient finds out that it has no storage for the rest of the blocks, then it returns 4.13…
This case is indeed not covered by my text, but by the original text (I propose to leave that in!)

> In this case, the server can return a smaller block size in the response, instead of an error code.
That’s true, but in the current definition (“In the response for a PUT or POST, the Block option indicates what block number is being acknowledged.”) the block option also serves as an acknowledgement. If the server is not willing to handle/acknowledge this first block, it follows that the Block Option can’t be used in the response either.  In any case my  proposed text should be made more clear.

> It is fine for the server to truncate the first block request payload. This is not an error.
If a server receiving a (first) block finds that the message in its receive buffer is truncated (truncation case I took from coap-05), the problem is it can’t acknowledge the block because part of the data is missing. Hence, it cannot send a Block Option to indicate a smaller block size is necessary. It can only respond with error 4.13 in this case?  Then the issue is that the client receiving the 4.13 respond may not know what the server exactly means by that; there are two ways of  interpretation, one derived from coap-05 and one derived from coap-block-02.

best regards,
Esko

From: Likepeng [mailto:[email-masked]]
Sent: Wednesday 20 April 2011 2:54
To: Dijk, Esko; [email-masked]
Subject: RE: Combined 4.13 response with Block Option?

Hi Esko,

Kind Regards
Kepeng

<original text>

best regards,

Esko

Kind Regards
Kepeng

Dear Kepeng,

best regards,
Esko

Kind Regards
Kepeng

best regards,
Esko Dijk