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

[[e-mail]]

Re,

(1)

We don't have an issue with other CoAP proxies as we use a distinct port number for DOTS.

(2)

For the pure CoAP case, the newBlock options will be marked as critical and unsafe to forward. There is no caching issue for a proxy that does not understand the option. GET with this option will be rejected by the proxy. The server will reject requests with the newBlock if it does not understand it. This is simple. 

For a proxy that supports block options, the blockwise spec does not impose to have all fragments. The spec leaves it open to implementations: if we don't have a loss, all fragments will be present. The proxy can be serve clients with individual blocks. 

We won't require all fragments to be reassembled at the proxy. We just need individual blocks. For example, if the client-proxy leg is lossy, the proxy can serve immediately the client with missing blocks. This will be part of the new behavior (which is fine given that these proxies are assumed to support the option).

Clients can determine the initial block size in initial newBlock. If the server does not like it and wants to send back a reduced size, that would be fine and the client would see one of the newBlock with smaller size and know to ask for the smaller sizes. 

I agree that we need to further assess this carefully but we are not sure yet there is an issue with regards to caching.

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:[e-mail]]
> Envoyé : jeudi 9 avril 2020 11:27
> À : 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?
> 
> Hi Med,
> 
> thank you for updating me on this information!
> 
> On 2020-04-09, at 09:56, <[e-mail]>
> <[e-mail]> wrote:
> >
> >> (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.
> >
> > [Med] Agree for the generic CoAP case.
> >
> > For the particular case of DOTS, sessions are established hop-by-hp
> when a proxy (we called it, gateway) is involved. We have the full
> visibility on what happens.
> 
> So you have application-aware proxies (which may not even be CoAP
> proxies).
> 
> But that doesn’t mean other proxies aren’t involved; there is also the
> matter of client caches, which have similar properties (caching, but
> no multiplexing).  So far, we have tried to keep the proxy/client-
> caching concept valid with extensions on CoAP; this would be the first
> one where we would have to say “no CoAP proxies can be used”.  I was
> wondering whether we can avoid this situation (can = don’t make the
> solution too complex).
> 
> Grüße, Carsten