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

Hi Achim,

I hear you.

How about extending the NonBLock2 option to contain more information.  E.g. 

   o  the size of the block (SZX);

   o  whether more blocks are following (M);

   o  the relative number of the block (NUM) within a sequence of blocks
      with the given size.

   o  the block set id (like the IPv4 fragment id field) for re-assembly.

Thus making the nonblock2 option length 0 to, say, 7 bytes long. 

Regards

Jon 

> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Achim Kraus
> Sent: 09 April 2020 12:02
> To: Jon Shallow; 'Carsten Bormann'; mohamed.boucadair@orange.com;
> dots@ietf.org; core@ietf.org
> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS:
> New BLOCK Option?
> 
> Hi Jon,
> Hi Med,
> 
>  > (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.
> 
> The point will be, how this relaxation actually looks like.
> FMPOV, the hard thing will be:
> The server MUST not make assumptions about the token, except that it is
> copied from the clients request into the response.
> 
> Currently the followup blocks considered to have a empty token (Jon's
> last note). That will hit any pending client requests with such a empty
> token. The matching is considered to be done via the etag. But RFC 7252
> defines the etag with:
> "An entity-tag is intended for use as a resource-local identifier".
> Though it's an resource local identifier, in my opinion, you can't use
> that to relate your blocks. The right blocks may have that etag, but
> others responses may have it as well (therefore "resource-local
> identifier").
> So, in my opinion, to know, to which resource the etags belongs to, the
> related request is required. Usually matched by the token, but that
> token is missing, because the client's request is missing.
> 
> 
> best regards
> Achim
> 
> Am 09.04.20 um 11:27 schrieb Jon Shallow:
> > Hi Carsten,
> >
> > I stand corrected - a token with 0 length.
> >
> > Regards
> >
> > Jon
> >
> >> -----Original Message-----
> >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Carsten
> Bormann
> >> Sent: 09 April 2020 10:23
> >> To: Jon Shallow
> >> Cc: mohamed.boucadair@orange.com; dots@ietf.org; core@ietf.org;
> Achim
> >> Kraus
> >> Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS:
> >> New BLOCK Option?
> >>
> >> On 2020-04-09, at 11:20, Jon Shallow <supjps-ietf@jpshallow.com> wrote:
> >>>
> >>> With the new nonblock2 option, the non-head blocks can have no token
> >>
> >> CoAP messages always have a token.
> >>
> >> Grüße, Carsten
> >>
> >> _______________________________________________
> >> Dots mailing list
> >> Dots@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dots
> >
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots