Re: [core] I-D Action: draft-ietf-core-new-block-02.txt

[[e-mail]]

Hi all, 

We raised during the IETF#109 whether (and if so how) it is worth to support an: optimization when MAX_PAYLOADS are exhausted but the network/peer can still handle more blocks without being congested. 

We understood from the discussion that this is left to the authors and the use case that triggered this draft: DDoS case. Here is our assessment from DOTS perspective: 

* Q-Block1: It is likely that these blocks will make it through as the DDoS traffic is in the other direction. No-Response option can be sufficient here, but we are not comfortable to use a normative language for No-Response as this is an ISE and will create a downref. A document in the standards track would be appropriate it. 

* The situation is different for Q-Block2 as the pipe is likely to be saturated. The turnaround to avoid ack-timeout is of less importance. Telemetry data can still fly from the client to the server (Q-Block1) but the one from the server to the client will be subject to losses. 

So, our plan is to leave the note that records the issue without adding any mention to No-Response. Solutions can be considered in the future when the WG reconsiders a replacement of current blocks:       

      Note: A delay of ACK_TIMEOUT after every transmission of
      MAX_PAYLOADS blocks may be observed even if the peer agent is able
      to handle more blocks without experiencing an overload.  This
      delay can be reduced by using CON for the MAX_PAYLOADS packet to
      trigger sending the next set of data when the ACK is received.
      Nevertheless, this behavior is likely to create other timeout
      issues in a lossy environment (e.g., unidirectional loss as in
      DDoS pipe flooding).  The use of NON is thus superior but requires
      an additional signal in the MAX_PAYLOADS packet to seek for a 2.31
      (Continue) from the peer if it is ready to receive the next set of
      blocks.

As this was the only pending issue we identified, and unless there is an objection or other proposals, we request a WGLC on -02.

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail]
> [mailto:[e-mail]]
> Envoyé : jeudi 29 octobre 2020 10:19
> À : [e-mail]
> Cc : [e-mail]
> Objet : RE: [core] I-D Action: draft-ietf-core-new-block-02.txt
> 
> Hi all,
> 
> We published the -02 as per the plan presented in the interim. The
> main changes are to reflect the outcomes of the interim:
> (1) Add a statement that either both or neither options can be
> supported.
> (2) Add an implementation note about how tokens are handled.
> (3) Change the name of the options.
> (4) Add a clarification about the behaviour when multiple instances
> of Q-Block2 are included.
> (5) Remove the "MUST NOT" restriction on 2.31 (Continue) as a
> provision to (9).
> (6) Clarify what is meant by "repeat request". Marco, please check
> if the NEW wording is better.
> (7) Overflow discussion. Michael, please check and let us know if we
> need to say more.
> (8) Update the CDDL and add an implementation note to suggest the
> use of indefinite-length arrays.
> (9) Add a note about the ACK_TIMEOUT delay after MAX_PAYLOADS.
> 
> We are waiting for the feedback from the WG whether (9) is worth to
> be solved at the CoAP level. This is the main pending issue that we
> would like to fix before asking for the WGLC
> (https://mailarchive.ietf.org/arch/msg/core/uoXMI8vcsGoto6fa1GpgftXS
> -cU/).
> 
> Please review and share your comments.
> 
> Cheers,
> Jon & Med
> 
> > -----Message d'origine-----
> > De : core [mailto:[e-mail]] De la part de internet-
> > [e-mail] Envoyé : jeudi 29 octobre 2020 10:01 À :
> > [e-mail] Cc : [e-mail] Objet : [core] I-D
> Action:
> > draft-ietf-core-new-block-02.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Constrained RESTful Environments
> WG
> > of the IETF.
> >
> >         Title           : Constrained Application Protocol (CoAP)
> > Block-Wise Transfer Options for Faster Transmission
> >         Authors         : Mohamed Boucadair
> >                           Jon Shallow
> > 	Filename        : draft-ietf-core-new-block-02.txt
> > 	Pages           : 25
> > 	Date            : 2020-10-29
> >
> > Abstract:
> >    This document specifies alternative Constrained Application
> > Protocol
> >    (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2
> Options.
> >
> >    These options are similar to the CoAP Block1 and Block2
> Options,
> > not
> >    a replacement for them, but do enable faster transmission rates
> for
> >    large amounts of data with less packet interchanges as well as
> >    supporting faster recovery should any of the blocks get lost in
> >    transmission.
> >


_________________________________________________________________________________________________________________________

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.