Use of Request-Tag for handling multiple Block2 responses

[mrdeep1]

I have run into an issue where multiple CoAP requests (not needing Block1) to the same resource trigger potentially different responses that require the use of Block2. If the responses overlap, then there is confusion as to how to pull back the correct response to match the request. For example (grossly simplifying things) POST /api//read payload = { 'offset': 0, 'count': 1200 } POST /api//read payload = { 'offset': 2000, 'count': 1300 } Or FETCH /api//read payload = { 'offset': 0, 'count': 1200 } FETCH /api//read payload = { 'offset': 2000, 'count': 1300 }

RFC7959 2.4 rightly states

The Block2 Option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise response payload transfer (e.g., GET) operations to the same resource. This is rarely a requirement, but as a workaround, a client may vary the cache key (e.g., by using one of several URIs accessing resources with the same semantics, or by varying a proxy-safe elective option).

Which then brings in the possible use of Request-Tag option in the request as a proxy-safe elective option. However. draft-ietf-core-echo-request-tag -14 3.2 states

The Request-Tag option is only used in requests that carry the Block1 option, and in Block2 requests following these.

Which implies that the examples above need to contain the Block1 option in the first instance if there is any suspicion that Block2 is needed in the response.

Then draft-ietf-core-echo-request-tag -14 3.4 states

Note that Request-Tag options can be present in request messages that carry no Block option (for example, because a Request-Tag unaware proxy reassembled them), and MUST be ignored in those.

Apart from being hard to parse (what does “those” refer to?), this tells me that Servers MUST ignore requests that have no Block option – so, I cannot just add the Request-tag option to a request on the off-chance there may be a Block2 needed response.

Is there a good reason for this MUST?

If it is too late for the draft to be updated, the only easy way forward that I can see is to add in an unneeded Block1 to the request, or to add in a Block2 option to the request so the Request-Tag can be used even if the response fits into a single payload.

[chrysn]

I don't have the whole set of block mechanisms on the top of my head right now, but don't you need to send the request payload again and again when fetching the subsequent response blocks, thus giving the server all the information needed to match the requests?

[mrdeep1]

Yes, the request payload (with just the different Block2 num) needs to be repeated until the whole of the body comes in - in effect, the cache-key needs to be the same for all the individual payload requests.

Here, I have 2 different payloads being returned (which are being transferred in the same time frame). Unless there is a varied proxy-safe elective option (unique the 2 different requests), it is not possible to request the next block specific to a particular returning payload.

Hence, If I could use different Request-Tag (so different effective cache-keys) in the initial different requests (but to the same resource), I can ask for a specific block out of a specific response and match it up with the individual request.

But, as I am not allowed to use Request-Tag if there is not a Block[12] option in the request, I cannot go down that path. Hence the question about why the MUST should be ther.

[cabo]

See also: https://mailarchive.ietf.org/arch/msg/core/P0NB_Trjcg-DfLDAr9lj6GgZkwo

[boaks]

Maybe adding some examples also for the "request-tag" part will bring additional clarity.

• block1 only transfer
• block1 / block2 transfer
• block2 only transfer

[cabo]

On 2021-12-20, at 18:49, Achim Kraus @.***> wrote:

adding some examples

If we don’t want to delay the RFC editor process (*), we could start a new document with these now.

Grüße, Carsten

(*) There are a few people ready to do unspeakable acts if you do that. https://www.rfc-editor.org/cluster_info.php?cid=C280 Please note the date of the first document in that cluster…

[boaks]

Please note the date of the first document in that cluster…

:-). It was just a "maybe".

[chrysn]

For the record, this is being addressed in AUTH48, pending approval of the authors and AD:

I support that change. The concrete text change I suggest is:

OLD: Note that Request-Tag options can be present in request messages that carry no Block options (for example, because a proxy unaware of Request-Tag reassembled them) and MUST be ignored in those.

NEW: Note that Request-Tag options can be present in request messages that carry no Block options (for example, because a proxy unaware of Request-Tag reassembled them). Clients may set them for purposes not further discussed in this document.

(The "MUST" was also slightly inexact; the server would still have used them as part of the block-wise key in any later Block2 phase, but it must not do anything more with it, as 3.3 already describes).

OLD: The Request-Tag option is only used in requests that carry the Block1 option and in Block2 requests following these.

NEW: The Request-Tag option is mainly used in requests that carry the Block1 option and in Block2 requests following these.

(The reader might follow with a thought like "although it may later turn out that the operation was not as block-wise as the client had anticipated", or even "and if it's only to disambiguate with a request that is still ongoing and known to be block-wise", but that does not need to be put in the document IMO).