Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option?

[Achim Kraus <[e-mail]>]

Hi Med,

maybe, we have a different understanding of the CoAP principles.

RFC 7252:
single request-responses are matched by their tokens, chosen by the
client. The server must include that token in it's response and must not
make assumptions about it.

RFC 7641:
single request - multiple responses are matched by their tokens, chosen
by the client. The server must include that token in all responses and
must not make assumptions about it.

RFC 7959:
multiple request - multiple responses are used to transmit a large
resource using the principals of RFC 7252/7641.
RFC 7252 each single block transfer matches the single block request
with it's single block response by a token chosen by the client. The
server can not assume, that the tokens of several block-requests are
related.
RFC 7641 "single request - multiple responses" applies only to the head.
the download of the left blocks doesn't reuse the token, nor is the
server allowed, to make assumptions about the token.

=> you can't send the follow up blocks, because the token to do so is
not defined. It would have been defined by the (missing) client request.
If the token of the observe is used, the server makes a assumption and
relate request of RFC7959, which are not related by the token.

Therefore I asked also about the usage of observer/notify. If a PUT/POST
is used, then your transfer looks just pretty much as a blockwise with
NSTART-X. The drawback there will be the missing "blocksize" negotiation
at the head. If that is acceptable, it should have a chance comparable
to the proposal.

The NonBlock2 solution is not bad on it's own, but it disrupt the
principals for the tokens on the server side, at least in my understanding.

---------------------------------------------------------------------

 > One clarification question:

 >>             +--------->|   GET /path/ctrl Token 0xf1 { NonBlock2
 >> 1/0/1024 NonBlock2 2/0/1024 }

 > Do existing CoAP implementations (libcoap, for example) support GETs
with a payload?


I know, it looks a little unfair to point on single items of other
example and then make buggy examples on my own :-). But I already admit
"That should be not considered as "precise description of the
application layer framing"".
In fact, there is no outer GET required. The outer request could also be
POST.

              +--------->|   POST /path/ctrl Token 0xf1 { GET /path
Token cde NonBlock2 1/0/1024 NonBlock2 2/0/1024 }


Just to mention, that this request triggers the notifies with the
missing block is "application layer convention". You may use whatever
definition you want to tell the server to (re-)send notifies with
blocks, there is no need of that inner GET request.

---------------------------------------------------------------------

best regards
Achim

Am 08.04.20 um 23:22 schrieb [e-mail]:
> Re-,
>
> Thanks, Carsten.
>
> This would mean that legacy CoAP implems do not support the coap-in-coap proposal without modification (given that rfc8132 support will be required).
>
> Actually, I'm struggling to understand what problem is solved by defining the NonBlock2 option but use it only with an extra coap layering.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Carsten Bormann [mailto:[e-mail]]
>> Envoyé : mercredi 8 avril 2020 23:08
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : Achim Kraus; Jon Shallow; [e-mail]; [e-mail]
>> Objet : Re: [core] [Dots] Large asynchronous notifications under DDoS:
>> New BLOCK Option?
>>
>> On 2020-04-08, at 23:04, <[e-mail]>
>> <[e-mail]> wrote:
>>>
>>> Do existing CoAP implementations (libcoap, for example) support GETs
>> with a payload?
>>
>> That is what FETCH is for.
>>
>> Grüße, Carsten
>