Re: [Dots] WGLC for draft-ietf-dots-robust-blocks-01

[[e-mail]]

Hi Kaname,

Thanks for the feedback.

The cache-key in general is built from the presented options in the request.
Whether an option and its value is included in the cache-key is initially
determined from whether the Option is either Unsafe or (Safe-To-Forward and
NoCacheKey does not have all the bits set)
https://datatracker.ietf.org/doc/html/rfc7252#section-5.4.6

However, there are exceptions to this.  If you want the cache-key to be the
entire body spanning multiple payloads, then you would exclude BLOCK1 and
BLOCK2 options form the cache-key, but if you want access to specific
blocks, then you could include BLOCK1 and/or BLOCK2 as a part of the
cache-key definition.  This is hinted at in
https://datatracker.ietf.org/doc/html/rfc7959#section-2.10

Q-BLOCK1 and Q-BLOCK2 are also Critical and Unsafe as are BLOCK1 and BLOCK2
respectively.  For a proxy - aka DOTS gateway - for simplicity, it is
expected that the entire body is cached
https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block#section-8
(i.e. Q-BLOCK1 and Q-BLOCK2 are not a part of the cache-key).

I don’t think anything extra needs to be added to dots-robust-blocks
regarding DOTS specific caching requirements as this draft is all about
tuning (should it be needed, but unlikely and not recommended unless you
really know what you are doing and have done lots of robustness testing) how
Q-Blocks work.  There was only one change to the recommended default CoAP
transmission parameters (MAX_RETRANSMIT changed from 4 to 3) as there were
timeout issues on lossy networks
https://datatracker.ietf.org/doc/html/rfc9132#section-4.5.2 

Regards

Jon
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 31 January 2022 07:56
> To: kaname nishizuka; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Dots] WGLC for draft-ietf-dots-robust-blocks-01
> 
> Hi Kaname,
> 
> Thank you for sharing the comments.
> 
> We can't specify what cache key will be used as this will depend on used
> options (and their types). We may consider adding an example and reason
> about it, but still that's just an example and can't be generalized.
That's why my
> current take on this is to make no change, but more opinions are welcome.
> 
> Looking forward to reading more about the Q-Block tests results.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots <[e-mail]> De la part de kaname nishizuka
> > Envoyé : dimanche 30 janvier 2022 14:27
> > À : [e-mail]; Valery Smyslov <[e-mail]>;
> > [e-mail]
> > Cc : [e-mail]; [e-mail]
> > Objet : Re: [Dots] WGLC for draft-ietf-dots-robust-blocks-01
> >
> > Hi,
> >
> > I've reviewed the draft.
> > I found no issue around the specification.
> >
> > The dynamic configuration and negotiation of the values are not
> > implemented yet on my side(go-dots).
> > But it'll be a good candidate for the next interop with Jon.
> >
> > The good news is that in our internal test, it's revealed that QBlock is
> > more robust against certain rate of packet loss compared with normal
> > block option. I will share the test result soon (maybe in the next IETF)
> >
> > One more thing I'd like to mention is about cache behavior.
> > I think it can be stated what the cache key should be based on(how it is
> > distinguished/identified).
> > There is no specific text on draft-ietf-core-new-block (and should not
> > be) If this draft can include a bit sense about DOTS specific cache
> > strategy, it could get more friendly for implementers.
> > I'm not sure it's on CoAP side or DOTS side, still though.
> >
> > Regards,
> > Kaname
> >
> >
> > On 2022/01/24 20:50, [e-mail] wrote:
> > > Hi all,
> > >
> > > I have re-reviewed the draft as well as being one of the Authors and
> > > can find no issues.
> > >
> > > The ability to dynamically configure and negotiate values for the
> > > first 4 parameter values has been implemented.
> > >
> > > libcoap (outstanding PR) has been updated to support the configuration
> > > (the last 2 parameter values are auto-computed based on the other
> > > parameters) as a part of the work for draft-ietf-core-new-block and my
> > > DOTS implement does the negotiation and pushes the resultant
> > configuration.
> > >
> > > Regards
> > >
> > > Jon
> > >
> > >> -----Original Message-----
> > >> From: Valery Smyslov [mailto: [e-mail]]
> > >> Sent: 17 January 2022 15:05
> > >> To: [e-mail]
> > >> Cc: [e-mail]; [e-mail]
> > >> Subject: WGLC for draft-ietf-dots-robust-blocks-01
> > >>
> > >> Hi,
> > >>
> > >> this message starts a two-week working group last call for
> > >> draft-ietf-dots-robust-blocks-01.
> > >> The WGLC will end on Monday, January 31. Please, review the draft and
> > >> send your comments to the mailing list.
> > >>
> > >> Regards,
> > >> Frank & Valery.
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dots
> >
> > _______________________________________________
> > Dots mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dots
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots