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

[Carsten Bormann <[e-mail]>]

Hi Achim,

On 2020-04-07, at 21:04, Achim Kraus <[e-mail]> wrote:
> 
> FMPOV, the first thing to ensure is, that the "large payload" gets split
> into "application blocks", which could be processed even when other
> application blocks are missing.

Indeed, “application layer framing” comes to mind here; that is always a good idea if it cannot be ensured that all messages make it or if it is good to be able to process messages while still waiting for others.

                     .oOo.

I’m trying to understand the very specific network environment that we are targeting here.
Are we assuming packets are way more likely to make it from the server to the client than the other way around?
That indeed would call for additional capabilities that base CoAP does not have.
We also may not really care about congestion control much in a situation of massive (attacker-induced) congestion (although that might be misdiagnosed, so some care is still required); which would be another reason to maybe deviate from base CoAP.

I don’t have a design in mind at the moment.  It would need to cater for the fact that sending the other response messages for the request would be on the initiative of the server.
So observe (with non-confirmable responses) is maybe a good model indeed; what’s missing is some way to ask for gaps.

I just resubmitted a draft that we have been discussing for a while in T2TRG:
The Series Transfer Pattern (STP)
https://www.ietf.org/id/draft-bormann-t2trg-stp-02.html

This has some discussion that may be relevant here, although it does not address the specific DOTS problem.  I think it would be great if whatever we come up with to solve this problem would also be a step forward on the larger class of applications needing the series transfer pattern.

Grüße, Carsten