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

[Carsten Bormann <[e-mail]>]

I apologize in advance for chiming in before having digested the whole thread.

I think that the idea of using observe with a modified block-wise protocol (1 below) can work.

I also think that application-layer framing (3 below) is useful.

I don’t see a contradiction between the two; they might be used together.

I would like to know how to handle two sub-problems here:

(a) using non-confirmable responses without additional requests brings us into PROBING_RATE territory.  What is actually the rate at which this exchange is supposed to happen?  Do we have other ways to manage capacity of the response path (a.k.a. congestion control)?  I.e., how does the server know which rate (e.g., for pacing) it should use for sending further messages?

(b) the semantics of observe is that a notification is the whole new state of the resource.  Proxies will implement it that way.  Of course block2 modifies this semantics a bit, so nonblock2 might do that too.  Still, I think we need to consider what proxies (or client caches) will make out of the mechanism we devise.

Grüße, Carsten


> On 2020-04-09, at 09:01, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Achim,
> 
> First, I was not looking to "make your example buggy". I was trying to understand how this would work without requiring changes to the base specs. Your feedback is highly appreciated and very useful. Thank you.
> 
> So far we have three approaches:
> 
> (1) The use of nonblock2 option with a "relax" of the behavior at the server to send the fragments with the same token and without waiting for GETs. 
> 
> (2) The use of a shim application as you suggested, which requires an update on the server side but also on how clients on how to fill the gaps (use of PUT/FETCH). 
> 
> (3) A DOTS specific approach to build its own chunks and signal blocks as part of the CBOR. These blocks are handled as atomic notifications. If a block is missing, the client can use GET+Query to retrieve the gap. We don't require any modification at the base CoAP specs. The issue with this one is to decide what data to put in the blocks to avoid that when a block is passed to other layers, the overheads won't lead to fragmentation.
> 
> It seems to me that (2) is a little bit more complex vs (1). 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Achim Kraus [mailto:[e-mail]]
>> Envoyé : jeudi 9 avril 2020 08:00
>> À : BOUCADAIR Mohamed TGI/OLN; Carsten Bormann
>> Cc : Jon Shallow; [e-mail]; [e-mail]
>> Objet : Re: [core] [Dots] Large asynchronous notifications under DDoS:
>> New BLOCK Option?
>> 
>> 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
>>> 
>