Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

mohamed.boucadair@orange.com Fri, 21 May 2021 12:42 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C113A0CB0; Fri, 21 May 2021 05:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY9c3WX0m4uk; Fri, 21 May 2021 05:42:03 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E543A0CA8; Fri, 21 May 2021 05:42:02 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4FmmT309MjzFqsJ; Fri, 21 May 2021 14:41:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621600919; bh=fhuJk/dQsHwWg9aIg2ysiCwrAkQP+GjX74uKHzg7Z2U=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=cykoZzPGKQ6RSBhZ7Wmfl47rMvROjNpFSGK14Qbf7l8Krj6jpNmDx04hOwmMOKchb Tfz7TxywV+4OQibafleTts/iCw8SUBriGRMXxVhk53Ze95mHey32wObisqWqx2zInT v50AUktFSbBGv27Wm7Xf9y6K4fVOFxE7d6P+i4iuXSw1BHgvMYO+0LDfNuKJ35y+WX 9TeCUmWBlY6P9bx/sS2xMuY5Rc74ZX03QZwBwTl/jL/08G+kwS3Pvnx08tIPRJSyhl Oe4nMXQhl/M3N8H7lo3TiTIEc2omEu73ttClw8x08va98KlSltlBdS0di3ioHocrDL 5/Gx5wc4vXVhw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4FmmT25lmLzCqkZ; Fri, 21 May 2021 14:41:58 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: John Scudder <jgs@juniper.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>, "marco.tiloca@ri.se" <marco.tiloca@ri.se>
Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMIAAmAIAgADwZ6A=
Date: Fri, 21 May 2021 12:41:57 +0000
Message-ID: <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <B7CF0ABB-4AE4-4D13-979B-A3242EDF5C9D@juniper.net>
In-Reply-To: <B7CF0ABB-4AE4-4D13-979B-A3242EDF5C9D@juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ythcqiSNVOp-67Cu6KzP5mUwd8E>
Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 12:42:08 -0000

Hi John,

As you can see in https://tinyurl.com/new-block-latest, we went with the following changes to better address your latest comment on the jitter:

(1) be explicit about the formula used for default values: 

OLD: 
   NON_PROBING_WAIT is used to limit the potential wait needed when
   using PROBING_RATE.  By default, NON_PROBING_WAIT has the same value
   as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).

   NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
   By default, NON_PARTIAL_TIMEOUT has the same value as
   EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).

NEW:
   NON_PROBING_WAIT is used to limit the potential wait needed when
   using PROBING_RATE.  By default, NON_PROBING_WAIT is computed in the
   same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with
   ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and
   NON_MAX_RETRANSMIT, respectively:

      NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) *
      ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT

   NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
   By default, NON_PARTIAL_TIMEOUT is computed in the same way as
   EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).  This default value
   is calculated in the same way as NON_PROBING_WAIT.

(2) We don’t see a need to apply a jitter when a value is explicitly configured (these are expected to be large numbers, we don't care that much on the jitter). We added this text to be clear about the intent, and which BTW reflects the current implementation:  

NEW:
      When explicit values are
      configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
      values are used without applying any jitter.

We also adopted your proposed edits in the message below. 

Thank you again for the careful review. This is highly appreciated. 

Cheers,
John & Med

> -----Message d'origine-----
> De : John Scudder [mailto:jgs@juniper.net]
> Envoyé : vendredi 21 mai 2021 00:03
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : The IESG <iesg@ietf.org>rg>; draft-ietf-core-new-block@ietf.org;
> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se
> Objet : Re: John Scudder's Discuss on draft-ietf-core-new-block-11:
> (with DISCUSS and COMMENT)
> 
> Hi Mohamed,
> 
> I think we are converging. My comments in line. I’ve snipped agreed
> points for brevity, indicated by […].
> 
> > On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote:
> 
> […]
> 
> >>>> 11. General
> >>>>
> >>>> By the way, none of the timers specify jitter (and indeed, if
> read
> >>>> literally, jitter would be forbidden). Is this intentional?
> >>>
> >>> No +/- tolerances have been defined. When a timer expires, then
> the
> >> next action takes place.
> >>
> >> I notice that RFC 7252 jitters its timers, for example:
> >>
> >>   counter.  For a new Confirmable message, the initial timeout is
> set
> >>   to a random duration (often not an integral number of seconds)
> >>   between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see
> >>   Section 4.8)
> >> …
> >>   ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD
> >> have
> >>   a value that is sufficiently different from 1.0 to provide some
> >>   protection from synchronization effects.
> >>
> >> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A
> >> number of your introduced parameters
> >>
> >>   This document introduces new parameters MAX_PAYLOADS,
> NON_TIMEOUT,
> >>   NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
> >>   NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
> >>
> >> appear at least superficially similar to the timers the authors of
> >> RFC 7252 deemed important to jitter to prevent synchronization
> >> effects. Did you specifically consider jittering them, and decide
> >> that jitter was unnecessary? If so, can you explain what is
> different
> >> about your specification, compared to the base spec, that
> eliminates
> >> the concern?
> >
> > RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter
> for multicast responses (which is not relevant here).
> >
> > The ACK_RANDOM_FACTOR is there for when re-transmitting a packet
> that has not been acknowledged for some reason by its peer.
> NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start
> transmission (not re-transmission) assuming a 'Continue' has not
> arrived in the interim, and so was not thought necessary to add in
> ACK_RANDOM_FACTOR style jitter here.
> >
> > For NON_RECEIVE_TIMEOUT, what is important is that
> NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spec a
> minimum of one second) so that a peer does not fire off a re-
> transmission request before the local agent has a chance to start to
> transmit the next MAX_PAYLOADS_SET.  NON_RECEIVE_TIMEOUT is
> exponentially scaled for each retry to make sure that stability is
> preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to be
> necessary here.
> >
> > NON_MAX_RETRANSMIT is a fixed count.
> >
> > NON_PROBING_WAIT is used to put a limit on the potential delay that
> could incur when obeying PROBING_WAIT when there is no peer response.
> If the implementation goes with the default EXCHANGE_LIFETIME
> computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in the
> math.
> >
> > NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIFETIME
> includes ACK_RANDOM_FACTOR.
> 
> Thanks for taking the time to explain. You don’t comment regarding
> whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered
> or not, you just explain that if they use the default they get jitter
> “for free”. The missing detail is that if they don’t use the default
> they don’t get jittered, so I think some consideration is still
> called for regarding whether having them not be jittered is OK.
> 
> […]
> 
> >>>> 15. Section 10.2.3
> 
> […]
> 
> >> One concern related to that: waiting NON_TIMEOUT isn’t actually
> >> required, it’s only RECOMMENDED, therefore this isn’t actually a
> >> guarantee. From §7.2:
> >>
> >>   As the sending of many payloads of a single body may itself
> cause
> >>   congestion, it is RECOMMENDED that after transmission of every
> >>   MAX_PAYLOADS_SET of a single body, a delay is introduced of
> >>   NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage
> >>   potential congestion issues.
> >>
> >> I am curious why you made this a RECOMMENDED instead of a MUST. In
> a
> >> situation like this it would be preferable for you to explain to
> the
> >> implementor what situation they can ignore the RECOMMENDED in and
> >> what they should do instead, or of course to make it into a MUST.
> >
> > Because a continue signal may be received from the peer and then
> continue without waiting for the timeout to expire.
> >
> > This is to be linked with this text:
> >
> >      A response using this Response Code SHOULD NOT be generated
> for
> >      every received Q-Block1 Option request (Section 7.2).  It
> SHOULD
> >      only be generated when all the payload requests are Non-
> >      confirmable and a MAX_PAYLOADS_SET has been received by the
> >       server.  More details about the motivations for this
> optimization
> >
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >      are discussed in Section 7.2.
> >      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > We could use **MUST unless a 'Continue' is received**, e.g.,
> >
> > OLD:
> >   As the sending of many payloads of a single body may itself cause
> >   congestion, it is RECOMMENDED that after transmission of every
> >   MAX_PAYLOADS_SET of a single body, a delay is introduced of
> >   NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage
> >   potential congestion issues.
> >
> > NEW:
> >   As the sending of many payloads of a single body may itself cause
> >   congestion, after transmission of every MAX_PAYLOADS_SET of a
> single
> >   body, a delay MUST be introduced of NON_TIMEOUT before sending
> the
> >   next MAX_PAYLOADS_SET to manage potential congestion issues.
> >   However, if a 'Continue' is received from the peer for the
> current
> >   MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can start
> >   transmission immediately.
> >
> > ... but I know that many would argue this is a SHOULD.
> 
> I would be OK with either your proposed new text, or a SHOULD/MAY
> pair as in
> 
> NEW:
>   As the sending of many payloads of a single body may itself cause
>   congestion, after transmission of every MAX_PAYLOADS_SET of a
> single
>   body, a delay SHOULD be introduced of NON_TIMEOUT before sending
> the
>   next MAX_PAYLOADS_SET to manage potential congestion issues.
>   However, if a 'Continue' is received from the peer for the current
>   MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start
>   transmission immediately.
> 
> If you want to stick with MUST I think you can clear up the pain with
> something like
> 
> NEW:
>   As the sending of many payloads of a single body may itself cause
>   congestion, after transmission of every MAX_PAYLOADS_SET of a
> single
>   body, a delay MUST be introduced of NON_TIMEOUT before sending the
>   next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer
>   for the current MAX_PAYLOADS_SET, in which case the next
>   MAX_PAYLOADS_SET MAY start transmission immediately.
> 
> (To my eye presenting the option in this way makes it clear when the
> MUST does, and doesn’t, apply. This is my preferred form but I don’t
> insist.)
> 
> […]
> 
> >> 17. Section 1:
> >>
> >>   This document introduces the CoAP Q-Block1 and Q-Block2 Options
> >> which
> >>   allow block-wise transfer to work with series of Non-confirmable
> >>   messages, instead of lock-stepping using Confirmable messages
> >>   (Section 3).  In other words, this document provides a missing
> >> piece
> >>   of [RFC7959], namely the support of block-wise transfer using
> Non-
> >>   confirmable where an entire body of data can be transmitted
> without
> >>   the requirement for an acknowledgement (but recovery is
> available
> >>   should it be needed).
> >>
> >> As far as I can tell the spec does not really remove the
> requirement
> >> for acknowledgement,
> >
> > These are not required. They were added as an optimization to avoid
> the non-timeout if the peer decides to use it.
> 
> As I mentioned below (“awfully close parsing”), I think that although
> you can find some justification for this reading, it’s debatable.
> Transmission of the acknowledgement (at least the final
> acknowledgement of the entire body, in the form of a Response Code)
> is required, is it not? Reception isn’t required though. Without the
> verb, I’m not sure whether I can say whether acknowledgement is, or
> isn’t, required.
> 
> I don’t insist that you change this, but I do think you could improve
> the clarity of the document, if you edited the above to read “…
> without the requirement that an acknowledgment be received from the
> peer"
> 
> >> it just amortizes the acknowledgements by only sending them every
> >> MAX_PAYLOADS_SET. Response Code 2.31 is essentially an
> >> acknowledgement, and it gets sent that frequently, right? There’s
> >> also (if I recall correctly) some flavor of acknowledgement that
> is
> >> sent when the entire body has been transferred. So, I think the
> new
> >> paragraph isn’t accurate.
> >>
> >> This observation also applies to this claimed benefit in §3:
> >>
> >>   o  They support sending an entire body using NON messages
> without
> >>      requiring an intermediate response from the peer.
> 
> And similarly, “… without requiring that an intermediate response be
> received from the peer.”
> 
> […]
> 
> >> 18. Section 2:
> >>
> >>   MAX_PAYLOADS_SET is the set of blocks identified by block
> numbers
> >>   that, when divided by MAX_PAYLOADS, they have the same numeric
> >>
> >> Remove “they”
> >
> > Fixed. Thanks.
> >
> >>
> >>   result.  For example, if MAX_PAYLOADS is set to '10', a
> >>   MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc.
> >>   Depending on the data size, the MAX_PAYLOADS_SET may not
> comprise
> >> all
> >>   the MAX_PAYLOADS blocks.
> >>
> >> I don’t understand the last sentence ("Depending on the data size,
> >> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS
> blocks.”)
> >> Are you trying to say that if the body size isn’t evenly divisible
> by
> >> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than
> >> MAX_PAYLOADS blocks in it?
> >
> > We meant that the last set may include fewer blocks than
> MAX_PAYLOADS. Changed to:
> >
> > " Depending on the overall data
> >                    ^^^^^^^^
> >   size, the final MAX_PAYLOADS_SET may not comprise all the
> >             ^^^^^
> >   MAX_PAYLOADS blocks. "
> >
> > Better?
> 
> Improving. The word “comprise” is prone to misinterpretation in my
> experience, I would suggest something like “… there could be fewer
> than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.”
> 
> Thanks,
> 
> —John

_________________________________________________________________________________________________________________________

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.