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 18:38 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 8EF823A1AD5; Fri, 21 May 2021 11:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 taPy2e5BN02g; Fri, 21 May 2021 11:38:48 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 E71083A1ADB; Fri, 21 May 2021 11:38:47 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id e14so19022862ils.12; Fri, 21 May 2021 11:38:47 -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=Rqe4ZP2SbhhLJOPHV0Pwlg7cGchPsWsGmh799bpCy9E=; b=e7CWkQF1ghUuqnIYnRxxRrsHVwPxFfDAeBg8lyiwUiDA7q8t5CGba819s7E8/jOutC USOHJCN0MEw1FyqadkcOvGfswan7mIkDnpruUjqU9LNvJE8R5WaqYsUG6hLfhjv1PvsU 6dOIMXguSDafDXdtiK5rQB+oLWSEChSA8UUO9lCQGknaXy9SeZfZgcotC/4YngzVz303 xW7RR6Pn5sxSYp7gtvy6v8EpRuFN0xm48yylJmizCKmxnqsB4OvApMfKG+AqYIeicJ4y GGGY0Q1a617TR/eF5Aj/n+OM9yOBuxN2XMnc3GxqYE2/O3tIgxUF5HOYfsJkWmgJITNe z8pQ==
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=Rqe4ZP2SbhhLJOPHV0Pwlg7cGchPsWsGmh799bpCy9E=; b=UTNt1yd6zPhM/80FS9GM94soc4CeoSfAs26p+ijVDnRmRsGLue7WD85cS20O7pz/0f jhZKsjiIe+cP79UDnC8hVdNTvZ/Jao+WMWAgk6o8O7bGOsLokqpFi4iKdGOqHc2gAOuZ JaXzppvMtq3bSgpVhWSGqRQisCGGTtsTTU3JSp6ZOCykLpOdx+/WdhRZmaErCh3hdHtM HqspCYR+xYauQdxt5trQGBztn8HFNP/erk6tX3xCUPX5qkLOj4G8q8kZn7vz7YxNjsfJ t2NllwLSfYFvToxDTMxQrTATzbxVPvh6gMgbShzBR5b03vGRSFk7HwYjXhwHtr7UR2ln zIsA==
X-Gm-Message-State: AOAM533FKKCgV54fh9FWZYUxfHmE84rag2PiasPmD7kIhmJcUEICB1w3 RVnKQRiDO2n80krRh3gfTFi8CHHp8BqvsCteBZU=
X-Google-Smtp-Source: ABdhPJx5224YBGIH08YylZJku+GHdnxUhWotkVCZDa1D6jZO0a9Orx1wmRWhH+Xi7RzALRfhk2Sp0Lg2j2IYSwhefeE=
X-Received: by 2002:a05:6e02:2162:: with SMTP id s2mr83162ilv.237.1621622326248; Fri, 21 May 2021 11:38:46 -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>
In-Reply-To: <17420_1621618028_60A7ED6C_17420_17_28_787AE7BB302AE849A7480A190F8B93303538C6AB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 21 May 2021 11:38:35 -0700
Message-ID: <CAM4esxRRKeJB7GK_45Thg4LhmNSh+FG_svaUhwzLvTi7WTEqzA@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, The IESG <iesg@ietf.org>, "core@ietf.org" <core@ietf.org>, "marco.tiloca@ri.se" <marco.tiloca@ri.se>
Content-Type: multipart/alternative; boundary="000000000000b7499d05c2db5e62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/S44d5sOES3KXF0wfXWdtNzsYSVY>
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 18:38:54 -0000

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.
>
>