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

Martin Duke <martin.h.duke@gmail.com> Fri, 21 May 2021 22:03 UTC

Return-Path: <martin.h.duke@gmail.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 BC1903A2253; Fri, 21 May 2021 15:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 VbawVVegRDl8; Fri, 21 May 2021 15:03:35 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 076F93A2250; Fri, 21 May 2021 15:03:34 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id a8so13502263ioa.12; Fri, 21 May 2021 15:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qqb7N3AzrAARJmBpfQzmBhqDUSohM0K8FJC8GW2nFoM=; b=lkpwDbkQkUb6zVZ0pD5zTrBijA01jIoM5vBkr5DBOgXIKRHEKyVrEx+mvzbrIfijs1 dAYLP8lg7EPHgQOSk1wWltDWvFvDG0D9bbCDw4xDSlCAbfOE4p5jJ+CQ/XiAtRNhHw9H jI8N6NUoKdallWqll1S5MObfAkl0STdgoNaDA1dHHKqt1dUyzBLOON5kaZYDg+1I++ns /RvIJTGMmpIMZ0VsKMdOa17yPyQoLdkLBAFNjfY9310cfGAkwBRuHNxrbv2ZyzEZ6G/4 uYhY+VGBcpaNNopQTK8JK5PTeZQnU/gCoAQ789Rqcok9aUChJSg/PGbfqqwEfj2mWn54 SREw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qqb7N3AzrAARJmBpfQzmBhqDUSohM0K8FJC8GW2nFoM=; b=QP/rxtwS00udrxRdlLRHJdY2CKuyHF2O4s4uVuOsntOQoEScPQvbwHqt/Xhxn/aAwZ 9SrIP8ogFhkJsurHSvNkpn7XHz5qqIbjE/DMwIldrlfjADRXnporRYmCqUubhuRvzYyW 0uggzpUfPmh+GeoFuTfwFoRmK7tsY5VTYj2t2PLLYKUH+67AUFZCXiDRMqbfXPmxU1c1 Y1M+G/f47fIEzdnERc8h0tIkbHfxz4yaGSO1OgMH81VK08u9ORmfoimC/YJtxeWBB5px 3xTUuKnvjjte7cBmgDOIyFkvK72zXTuy8j3Ylo0qxrk1AM7DNFk4O0UwmTTgoWaF7FbM ioGg==
X-Gm-Message-State: AOAM532lwSswbFRZ+leZZifYhwS5G/YCoqT7weI6b5TgsQ4GXCGmCX5g XJEDWxYRjhcvDpKKMFO5um3twROfq8DCxdaRs2I=
X-Google-Smtp-Source: ABdhPJzMXTumcbdspn2zBntCvH2ThZFvTYTYwCrNqtaLzVk+sxkDXSBGx2Ab2b8dRarEuIVUNPnIwpK48Q01IOnD5UU=
X-Received: by 2002:a02:354c:: with SMTP id y12mr7758063jae.144.1621634613597; Fri, 21 May 2021 15:03:33 -0700 (PDT)
MIME-Version: 1.0
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> <4833_1621600918_60A7AA96_4833_485_3_787AE7BB302AE849A7480A190F8B93303538C272@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <36A5A92C-AD99-4554-8A09-4E76E60BA98A@juniper.net> <CAM4esxRPw=Jk0TiwBV8D-fak6SDYBSRfZVjKSB1bmRLE+8LXOA@mail.gmail.com> <17420_1621618028_60A7ED6C_17420_17_28_787AE7BB302AE849A7480A190F8B93303538C6AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAM4esxRRKeJB7GK_45Thg4LhmNSh+FG_svaUhwzLvTi7WTEqzA@mail.gmail.com> <093901d74e75$c21e6130$465b2390$@jpshallow.com>
In-Reply-To: <093901d74e75$c21e6130$465b2390$@jpshallow.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 21 May 2021 15:03:22 -0700
Message-ID: <CAM4esxSv1=pbnDhTMX1_Q8eO9srUUg9DGW-bPgF7UWTbRYR_+g@mail.gmail.com>
To: supjps-ietf@jpshallow.com
Cc: mohamed.boucadair@orange.com, core-chairs@ietf.org, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, draft-ietf-core-new-block@ietf.org, The IESG <iesg@ietf.org>, core@ietf.org, marco.tiloca@ri.se
Content-Type: multipart/alternative; boundary="0000000000001959af05c2de3bfe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/OScbnmNrMto8UYHLRV7aE0Rbeqg>
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 22:03:41 -0000

Thanks for humoring me as I try to verify that there isn't a problem here!

I think we've collapsed the potential problem to NON_TIMEOUT and
NON_RECEIVE_TIMEOUT.

Some scenarios:
(1) Let's say two senders simultaneously send MAX_PAYLOAD bursts over a
radio medium that causes them to interfere with each other. With no
response from the receiver at all, they both wait for NON_TIMEOUT and send
another burst, causing the same effect.

Can this not happen?

(2) Two receivers send bursts that arrive at a bottleneck at the same time,
causing congestion losses

The receivers will request missing blocks, wait NON_RECEIVE_TIMEOUT, and
trigger retransmission. For these to also collide, that would imply that
(1) the RTTs are similar, and (2) the timing of the first missing packet
signal is roughly simultaneous.

Is that correct?

Martin

On Fri, May 21, 2021 at 12:17 PM <supjps-ietf@jpshallow.com> wrote:

> Hi Martin,
>
>
>
> NON_TIMEOUT has the same default value as ACK_TIMEOUT (Section 7.2 of the
> draft).  RFC7252 Section 4.2 “Messages Transmitted Reliably” has
>
>
>
>    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)
>
>
>
> As mentioned previously in this thread
>
> “
>
> 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.
>
> “
>
>
>
> Does that help?
>
>
>
> Regards
>
>
>
> Jon
>
>
>
> *From:* Martin Duke [mailto: martin.h.duke@gmail.com]
> *Sent:* 21 May 2021 19:39
> *To:* mohamed.boucadair@orange.com
> *Cc:* John Scudder; draft-ietf-core-new-block@ietf.org;
> core-chairs@ietf.org; The IESG; core@ietf.org; marco.tiloca@ri.se
> *Subject:* Re: John Scudder's Discuss on draft-ietf-core-new-block-11:
> (with DISCUSS and COMMENT)
>
>
>
> I agree that those two parameters have no need for jitter.
>
>
>
> However, NON_TIMEOUT and NON_RECEIVE_TIMEOUT would appear to, but derive
> from 7252 formulae that don't have the jitter included.
>
>
>
> On Fri, May 21, 2021 at 10:27 AM <mohamed.boucadair@orange.com> wrote:
>
> Hi Martin,
>
>
>
> The comment about large numbers should be put in the context of the two
> timeouts discussed with John: NON_PARTIAL_TIMEOUT and NON_PROBING_WAIT.
> Consider the example of NON_PARTIAL_TIMEOUT, adding some jitter to it is
> unlikely to have an effect as that timer is about controlling when a
> received partial body will be discarded locally.
>
>
>
> NON_PROBING_WAIT is about limiting the effect of PROBING_RATE when a peer
> does not reply. As a reminder, probing rate is defined as follows:
>
>
>
>    The PROBING_RATE parameter in CoAP indicates the average data rate
>
>    that must not be exceeded by a CoAP endpoint in sending to a peer
>
>    endpoint that does not respond.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Martin Duke [mailto:martin.h.duke@gmail.com]
> *Envoyé :* vendredi 21 mai 2021 18:28
> *À :* John Scudder <jgs=40juniper.net@dmarc.ietf.org>
> *Cc :* BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>;
> draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG <
> iesg@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)
>
>
>
> So I'm not sure that "large numbers" are a sufficient reason to not worry
> about jitter.
>
>
>
> If two hosts simultaneously transmit on a quiet network, and cause losses
> with each other. They both set the same retransmission timeout, and in
> spite of no other traffic around cause the same collision, etc.
>
>
>
> If an explicit configuration doesn't result in common round numbers, it's
> an OK substitute, but I don't see any encouragement of that choice.
>
>
>
> On Fri, May 21, 2021 at 9:17 AM John Scudder <jgs=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> Hi Med,
>
> Your current working copy looks good. I’ve cleared my discuss.
>
> —John
>
> > On May 21, 2021, at 8:41 AM, mohamed.boucadair@orange.com wrote:
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi John,
> >
> > As you can see in
> https://urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6yMaO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$
> <https://urldefense.com/v3/__https:/tinyurl.com/new-block-latest__;!!NEt6yMaO-gk!RlDk7GMcbxlFsT2QGl8ma04s1CggmQZQHcIP9aw2R2EP1rWkfQDAbIpzOgyR6g$>
> , 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>; 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.
> >
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>