Subject: [core] #334: MUST for in-order block transfer

From: "core issue tracker" <[email-masked]>
Date: Thu, 01 Aug 2013 13:02:37 -0000

#334: MUST for in-order block transfer

 A benefit of fragmentation at the application layer is that the
 application can start to process incomplete messages. This is very useful
 when buffer sizes are limited. 6LoWPAN fragmentation for instance must
 wait for the final fragment until the re-assembled IP packet is handed up
 to the next layer (unless the implementation starts with cross-layer
 optimizations).

 To benefit from fragment-/block-wise processing, they need to arrive in
 order. Currently, this is not assured and could break interoperability.

 The -block draft should make it a MUST to always start with block zero and
 send the following in order.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  [email-masked]   |  [email-masked]
     Type:  protocol     |     Status:  new
  enhancement            |  Milestone:  post-WGLC-1
 Priority:  major        |    Version:
Component:  block        |   Keywords:
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/334>
core <http://tools.ietf.org/core/>

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 7 Aug 2013 07:25:16 +0000

The ticket below indeed describes what I think is most common, i.e. that a block transfer starts with block 0 and delivers the rest of the blocks sequentially.

However, I can see situations where it may be useful to get blocks in an non-sequential way. For example, if the format of the data is well-known, and the client is only interested in a particular part of the data, I don't see why it should download all other blocks just to satisfy the sequential block requirement.

Another example may be block over multicast, where the blocks are initially delivered to a group of clients through multicast. Should a client miss a block due to loss, it can request that particular block trough a unicast request.

When the server is stateless, it cannot remember which block was delivered last, so it can't enforce sequential delivery anyway. It wholly depends on which block is requested by the client.

But the client is controlling the block order right? It includes the block number in its requests. So in this way, the client can enforce sequential delivery of the blocks as it wants. Unless of course when the blocks are sent as a fragmented response to PUT/POST, in which case the client does not send requests, but the server fully controls which blocks are sent when. Similar to Observe. I guess in these cases a MUST for sequential order is on its place.

What do you think?

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of core issue tracker
Sent: 2013年8月1日 21:03
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [core] #334: MUST for in-order block transfer

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Aug 2013 09:43:28 +0200

On Aug 7, 2013, at 09:25, Bert Greevenbosch <[email-masked]> wrote:

(on the cases where the server takes the initiative:)

> I guess in these cases a MUST for sequential order is on its place.

Very good point.

I added to the end of 2.7:

   Blockwise transfers that use server initiative MUST be performed in
   sequential order.

[1451].

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 7 Aug 2013 09:29:37 +0000

> However, I can see situations where it may be useful to get blocks in an non-
> sequential way. For example, if the format of the data is well-known, and the
> client is only interested in a particular part of the data, I don't see why it should
> download all other blocks just to satisfy the sequential block requirement.

Do you have that in use or see a real use case for it?
I played with this and it required padding in all media types (I use) to get a useful format for that. But then, when the data is structured anyway, why not use sub-resources or queries?

> Another example may be block over multicast, where the blocks are initially
> delivered to a group of clients through multicast. Should a client miss a block
> due to loss, it can request that particular block trough a unicast request.

How would this work? Who sends the initial request and how do we configure a multicast return address? Multicast Block1 also sounds a bit broken... :P

> When the server is stateless, it cannot remember which block was delivered last,
> so it can't enforce sequential delivery anyway. It wholly depends on which block
> is requested by the client.

In the normal GET case, the receiver of the blocks can define the order, which is fine. The in-order requirement helps where the receiver cannot, e.g., PUT/POST---and Block2+Observer at the moment.

> Similar to Observe. I guess in
> these cases a MUST for sequential order is on its place.
> 
> What do you think?

Yes. So essentially we need a MUST be in order for the cases where the receiver cannot decide over the ordering. I would also put all Block1 requests into this category. In that case, the random access would also work--- I still cannot see the point, though.

Ciao
Matthias

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2013 10:03:17 -0400

Kovatsch  Matthias <[email-masked]> wrote:
    > I played with this and it required padding in all media types (I use)
    > to get a useful format for that. But then, when the data is structured
    > anyway, why not use sub-resources or queries?

That just seems the best way to do things to me too.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Aug 2013 16:12:00 +0200

> I played with this and it required padding in all media types (I use) to get a useful format for that. But then, when the data is structured anyway, why not use sub-resources or queries?

For the use cases where -block doesn't work anyway, that is fine.
For the ones where -block already does the right thing, this just duplicates code.
(Obviously, the use cases I have in mind have a much tighter coupling between client and server than normal in REST.  So the client will already know it can do non-sequential access to certain resources.  Of course, the fun part is what behavior we deem appropriate for a proxy, which may not be a party to this tight coupling.)

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Aug 2013 10:25:04 +0100

+1. Block should do "what it says on the tin".

Robert

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 8 Aug 2013 09:30:18 +0000

Hi Matthias,

> I played with this and it required padding in all media types (I use) to get a useful format for that. But then, when the data is structured anyway, why not use sub-resources or queries?

Sub-queries indeed is another option. The padding can be problematic, especially when a receiving party doesn't verify whether a block number is reasonable, i.e. when it receives an (erroneously) extremely high block number and it just pads its internal representation, then that representation can become quite large. There may also be the problem that the receiver is just not able to random access files while writing.

> How would this work? Who sends the initial request and how do we configure a multicast return address? Multicast Block1 also sounds a bit broken... :P

Ah yes, the current groupcomm document focuses on multicast to CoAP servers, not to CoAP clients. So this makes it hard to multicast observations to CoAP clients. I probably had some wishful thinking here, as it may be useful to have a constrained server send out only one observation, and then let the multicast infrastructure take care for the delivery to all clients. But that would require extra technologies, as an observation client needs context to interpret observations.

> Yes. So essentially we need a MUST be in order for the cases where the receiver cannot decide over the ordering. I would also put all Block1 requests into this category. In that case, the random ac…

Agree about the MUST for receivers that cannot influence the order, including Block1 requests.

For the Block1 requests, when the client ignores the rule and sends the blocks in non-sequential order, how should the server deal with it? Will it give an error, or will it process it anyway? Or should this decision it be left to implementation? We may need to add some text about this, maybe with SHOULDs. Same for the client behaviour when a server ignores the ordering rule.

For the case that receivers can influence the order - I think of Block2 GET requests - I don't think a MUST is necessary. I believe random access can have its advantages. I use the "seek" function quite often when programming in C, and freedom in ordering in block can provide similar use. But I understand you agree that we do not need to mandate the order in this case?

Best regards,
Bert

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]] 
Sent: 2013年8月7日 17:30
To: Bert Greevenbosch
Cc: [email-masked]; [email-masked]
Subject: AW: [core] #334: MUST for in-order block transfer

Ciao
Matthias

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 12 Aug 2013 13:30:44 +0000

>> How would this work? Who sends the initial request and how do we
>> configure a multicast return address? Multicast Block1 also sounds a
>> bit broken... :P
>
>Ah yes, the current groupcomm document focuses on multicast to CoAP servers, not to CoAP clients. So this makes it hard to multicast observations to CoAP clients. I probably had some wishful thinking >here, as it may be useful to have a constrained server send out only one observation, and then let the multicast infrastructure take care for the delivery to all clients. But that would require extra >technologies, as an observation client needs context to interpret observations.

This reminds me: core-block does not mention multicast at all, which needs to be the case IMO. Since the groupcomm draft mentions (section 3.8) that a server may respond unicast blockwise in response to a multicast request to /.well-known/core, core-block needs to make clear exactly in what (limited?) situations multicast blockwise requests are supported. This use case for responding with a single block (block 0) to a multicast discovery request was discussed some times before on the list, with no objections from anyone.

So I'll create a ticket for this, if there are still no objections ;)

Esko

________________________________
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: Bert Greevenbosch <[email-masked]>
Date: Tue, 13 Aug 2013 01:11:07 +0000

Hi Esko, all,

I guess, when we do nothing, the multicast GET Block request would work in the normal case as follows:

(1) Client requests the resource, with or without Block2
(2) Each server responds with a single message containing block 0 or the requested block

This leads to around the same number of responses as there are servers in the multicast-group, re-transmission and message loss ignored. Seems similar to a multicast GET without Block.

However, when we combine Block with Observe this changes, as then each time a resource changes the associated server will send out multiple messages. This may lead to an unexpected large number of messages.

Multicast observe (without Block) has this issue too, but at least it is limited to a single message per resource change.

So I agree that we need to add some text about multicast and Block, indeed also about in which situations it can be supported.

Best regards,
Bert

-----Original Message-----
From: Dijk, Esko [mailto:[email-masked]] 
Sent: 2013年8月12日 21:31
To: Bert Greevenbosch; Kovatsch Matthias; [email-masked]
Cc: [email-masked]
Subject: RE: [core] #334: MUST for in-order block transfer

Esko

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 13 Aug 2013 08:02:33 +0000

> However, when we combine Block with Observe this changes, as then each
> time a resource changes the associated server will send out multiple
> messages. This may lead to an unexpected large number of messages.

To this end, I have a different solution implemented for a while now: Block with Observe only causes the first block to be sent out as notification. The clients then GET the remaining blocks like for a normal blockwise GET, using the same code. This also avoids sending out a huge number of blockwise notifications to clients that are actually not interested anymore.

This is one of the reasons why I see this server initiative a bit problematic and would like to go for a "always client initiative" instead.

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Aug 2013 10:39:28 +0200

> To this end, I have a different solution implemented for a while now: Block with Observe only causes the first block to be sent out as notification. The clients then GET the remaining blocks like for a normal blockwise GET, using the same code.

Interesting.

> This also avoids sending out a huge number of blockwise notifications to clients that are actually not interested anymore.

If a client is not interested, it should have RST on the first block.

> This is one of the reasons why I see this server initiative a bit problematic and would like to go for a "always client initiative" instead.

With observe (without block), the initiative clearly is with the server.
This is a feature, not a bug -- it allows a sleepy server to send its notifications when it is awake.
So I'm not sure that it is always a win to move the initiative back to the client on the remaining blocks.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 13 Aug 2013 08:46:14 +0000

> So I'm not sure that it is always a win to move the initiative back to the client

Hmm, would the server not have to wait for the ACKs in the same fashion it would wait for subsequent GETs (i.e., with a final deadline where it goes back to sleep)? Clearly the client has to play along and needs to GET the remaining blocks in a timely manner...

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 14 Aug 2013 00:44:34 +0000

It seems that in Matthias's idea, the initiative still lies with the server. After all, it is the server that sends the observation with Block 0.

I like this, as it also reduces the state the server needs to maintain; the server does not need to keep track of which block it has sent to which client. Especially with Observe, where we can expect multiple observation clients, this releaves the server from some bookkeeping. The server would only need to remember to include Block 0 in the observation, and the block size.

Best regards,
Bert