Subject: [core] Separate response + Block2 = non-empty ACK by client?

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 22 Apr 2012 16:45:54 +0000

Hello

I just hit the use-case where a request with separate response requires Block2 transfer.

While figuring out that my transfer layer set the type to ACK instead of CON, I noticed this in the block draft:

Figure 10, after a POST with separate response:

     | <------   CON [MID=4712], 2.01 Created, 37a, 2/0/1/128   |

     |                                                          |

     | ACK [MID=4712], 0, 2/0/1/128                     ------> |

     |                                                          |

     | <------   CON [MID=4713], 2.01 Created, 37a, 2/1/1/128   |

But this means that the client sends an empty ACK with block option! I was in the understanding that empty ACKs are empty?

Anyhow, I think this breaks all layered applications (or makes them unnecessarily complex).

Am I wrong assuming that this (Block2 with request-depending response) also only works for servers that cache the body for the clients? Maybe the document should advise to use resource state and point there via Location?

Assuming caching, the CON should be ACKed (empty) and then the client repeats his request for the next block to have a “normal” Block2 transfer.

Ciao

Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 22 Apr 2012 18:59:30 +0200

Yes, I don't think we really have tested the concepts demonstrated in Figure 10, which is about the interaction between Block1 and Block2 (see also ticket #203).  Good to revisit this.

If we go forward with #210, much of this will become simpler.
With #210, there is no need to send back Block2 options just for disambiguating them.
This would solve the problem you note with an ACK 0 suddenly carrying options.

> But this means that the client sends an empty ACK with block option! I was in the understanding that empty ACKs are empty?

Right, let's fix that.

> Anyhow, I think this breaks all layered applications (or makes them unnecessarily complex).

"this" = ?

> Am I wrong assuming that this (Block2 with request-depending response) also only works for servers that cache the body for the clients?

Well, the specific use case was POST, and this is for sending back the (atomic) POST response.

> Maybe the document should advise to use resource state and point there via Location?

That would be the preferred way to send back information that is already represented in a resource.  Maybe not so useful for SOAP.

> Assuming caching, the CON should be ACKed (empty) and then the client repeats his request for the next block to have a “normal” Block2 transfer.

Well, what exactly would who repeat?

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 22 Apr 2012 17:17:21 +0000

> With #210, there is no need to send back Block2 options just for

But how will the client request the next block? (see "what to repeat" below)
 
> > Anyhow, I think this breaks all layered applications (or makes them

That ACKing CONs (no piggybacking) is entangled with block transfer control. 

> > Assuming caching, the CON should be ACKed (empty) and then the client
> repeats his request for the next block to have a "normal" Block2 transfer.
> 

The client sends again a POST with the same token, Block2 with increased block number.
In my implementation, the POST would not be executed again because the transfer layer handles it out of its cache and does not pass it up to the resource.
The problem is now, that I use the token to identify this request (so for me the token was always a session/transaction ID (just like MID, only for a "session" (the unpopular word..) of multiple messages). With ticket #210, however, the server can only guess from the block number, what the client wants (num=0 or no Block2: new transaction, num>0 continue transfer).

At the moment, I can only think of actually introducing sessions (or overall transactions) by more definitions on how to use the token or, second, somehow forbid these ambiguous actions that need the notion of a session...

Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 22 Apr 2012 20:44:12 +0200

> But how will the client request the next block? (see "what to repeat" below)

It wouldn't (see below).

> That ACKing CONs (no piggybacking) is entangled with block transfer control. 

OK, let's get rid of that.

> The client sends again a POST with the same token, Block2 with increased block number.

That was what I was trying to avoid with the scheme in Figure 10, and what we need to nail down to close #203.

Essentially, the idea is that a Block2 with PUT/POST would be "turned around" in the spirit of a separate response, similar to the way observe works with Block2:
The server takes the initiative to send the blocks.
(There is no point in trying to be stateless here, so from my point of view, leaving the initiative with the server is OK.)
The only thing that the client does at this point is send ACKs, and these might as well be ACK/0s.

The only thing that is missing when we take the Block2 options out of the ACKs is the block size negotiation.  The best way to do this might be for the client to send a Block2 request option early.  There is no way left to do late negotiation in this scheme.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 22 Apr 2012 19:06:09 +0000

> Essentially, the idea is that a Block2 with PUT/POST would be "turned around" in
> the spirit of a separate response, similar to the way observe works with Block2:

Okay, I wondered whether this was implied by the example... probably something else we need text on.

Oh, I missed that observe + Block2 should work that way.
There I also used a client-initiated GET for further blocks. This would also leave more control to the client. Maybe it does not want to receive the complete representation right away or is already happy that he is still on the list. What should he do in this case with this turn-around scheme? Wait until the retransmissions time out? Send a RST? But that also cancels the observe relationship...

> (There is no point in trying to be stateless here, so from my point of view,
> leaving the initiative with the server is OK.) The only thing that the client does at
> this point is send ACKs, and these might as well be ACK/0s.
> 
> The only thing that is missing when we take the Block2 options out of the ACKs is
> the block size negotiation.  The best way to do this might be for the client to
> send a Block2 request option early.  There is no way left to do late negotiation in
> this scheme.

At the moment, I have the same problem with GET and blockwise separate response.
Odd, to also waive late negotiation here...
Only way I see is to force the programmer of the resource handler to take care of this caching and so only have a separate response from time to time.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 22 Apr 2012 21:23:02 +0200

> Okay, I wondered whether this was implied by the example... probably something else we need text on.

Yes, we do, as part of resolving #203, I think.

> Maybe it does not want to receive the complete representation right away or is already happy that he is still on the list. What should he do in this case with this turn-around scheme? Wait until the retransmissions time out? Send a RST? But that also cancels the observe relationship...

Well, if you are an observer, you *want* the data (otherwise there won't be eventual consistency).  If you don't want the data, canceling the observation relationship is exactly what you want to do.
(But maybe I'm missing the use case.)

> At the moment, I have the same problem with GET and blockwise separate response.

But that is not a problem -- with block-wise GET, you get the separate response for that block only.
The "turn-around" (server initiative for sending Block2 blocks) would be needed for PUT/POST and observe, not for GET.
Actually, with GET, nothing stops the server from sending half of the blocks in separate responses and the other half piggy-backed on the ACKs.

In other words, the decision to "turn around" is not at all following from the decision to do a separate response.  (Once you do turn around, of course, everything behaves like separate responses.)

Grüße, Carsten