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

[[e-mail]]

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: [e-mail]] 
Sent: 21 May 2021 19:39
To: [e-mail]
Cc: John Scudder; [e-mail]; [e-mail]; The IESG; [e-mail]; [e-mail]
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 <[e-mail]> 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:[e-mail]] 
Envoyé : vendredi 21 mai 2021 18:28
À : John Scudder <jgs=[e-mail]>
Cc : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; [e-mail]; [e-mail]; The IESG <[e-mail]>; [e-mail]; [e-mail]
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=[e-mail]> wrote:

Hi Med,

Your current working copy looks good. I’ve cleared my discuss.

—John

> On May 21, 2021, at 8:41 AM, [e-mail] 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:[e-mail]]
>> Envoyé : vendredi 21 mai 2021 00:03
>> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
>> Cc : The IESG <[e-mail]>; [e-mail];
>> [e-mail]; [e-mail]; [e-mail]
>> 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, [e-mail] 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.