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

mohamed.boucadair@orange.com Tue, 25 May 2021 12:15 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 7849B3A10CA; Tue, 25 May 2021 05:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=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=unavailable 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 HZ4UVbBtHXLT; Tue, 25 May 2021 05:15:15 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 B02AE3A10C5; Tue, 25 May 2021 05:15:14 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4FqChJ6SQHz8vqb; Tue, 25 May 2021 14:15:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1621944912; bh=lTYis9eDp17asGy81lDPYthMQrdyCZy18SYEfqdsv3c=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=svXbwbIlDPpx6wzqZElaNqkvSdYDjcUxnsqLmBYyfIWHCeB0+s9y4BCYxSUHmORLk Y4rAnkhaMvGbpYrlb89C8zFZIK0wR5/RWL/HMqJYOWAMnvGlJHql5zNFj0X4kVwgJC 8tQiErrYIJW+bFKbQ2CChVGOPvDw+hl+d6TASZtv8+AKHM0qiHENCzEEQRRdk2+tZo 1gSKudF6+JQIKjUyGZFRVJ6X/1GXz6CG0IRIgbaLHelqRPPDp89qUC7H4CUw43mhuE paV51+LGnlDyrdr2ryAf5schR6rrCU7lHMMtUDo2XCtjtmduDIKB5qn0/OXmDu58J+ qjALr4jlfUePA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4FqChJ4XhNz5vN9; Tue, 25 May 2021 14:15:12 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Martin Duke <martin.h.duke@gmail.com>, "supjps-ietf@jpshallow.com" <supjps-ietf@jpshallow.com>
CC: "core-chairs@ietf.org" <core-chairs@ietf.org>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>, "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>, The IESG <iesg@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/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMIAAmAIAgADwZ6CAAEEXAP//4bcAgAAsbMD///f2gIAACoAAgAAutwCABbJJoA==
Date: Tue, 25 May 2021 12:15:11 +0000
Message-ID: <4815_1621944912_60ACEA50_4815_29_1_787AE7BB302AE849A7480A190F8B93303538E781@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> <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> <CAM4esxSv1=pbnDhTMX1_Q8eO9srUUg9DGW-bPgF7UWTbRYR_+g@mail.gmail.com>
In-Reply-To: <CAM4esxSv1=pbnDhTMX1_Q8eO9srUUg9DGW-bPgF7UWTbRYR_+g@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303538E781OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/8CQ4tYMiXQ4tPwDMLdWr0XPmHSE>
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: Tue, 25 May 2021 12:15:22 -0000

Hi Martin,

Thank you for the follow-up.

Please see inline.

Cheers,
Jon & Med

De : Martin Duke [mailto:martin.h.duke@gmail.com]
Envoyé : samedi 22 mai 2021 00:03
À : supjps-ietf@jpshallow.com
Cc : BOUCADAIR Mohamed TGI/OLN <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
Objet : Re: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

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?

First, please note that some natural randomness will be observed by peers (including the effect of probing-rate locking/unlocking and traffic exchange profile of each peer). Please remember that PROBING_RATE is defined in RFC7252 as ** an average ** data rate let alone this assumption in the applicability scope:

  “Concretely, this mechanism primarily
   targets applications such as DDoS Open Threat Signaling (DOTS) that
   cannot use CON requests/responses because of potential packet loss
   and that support application-specific mechanisms to assess whether
   the remote peer is not overloaded and thus is able to process the
   messages sent by a CoAP endpoint (e.g., DOTS heartbeats in
   Section 4.7 of [RFC8782]).”

So, the full sync case to happen requires many conditions that might be difficult to satisfy.

Back to your question: If there is ** any response ** (which can be during or just after the second burst), such responses will come serially out of the slow link, so having different timestamps and hence the third and subsequent triggered bursts of the same body will now be out of phase. There is also a chance if jitter is added that there may be a timing equality on a subsequent burst if the initial burst is closely aligned.

However, if there is ** no response ** at all over multiple bursts of a body, then the scenario you raise is problematic.

We added this note:

      Note: Randomness may naturally be provided based on the traffic
      profile, how probing-rate is computed (as this is an average), and
      when the peer responds.  Randomness is explicitly added for some
      of the congestion control parameters to handle situations where
      everything is in sync when retrying.

and other changes that you can see at: https://tinyurl.com/new-block-latest.

(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?

As the ‘request missing’ going back to the transmitters will come out of the slow link serially with different timestamps, the transmitters are unlikely to resend the missing packets at the same time.

We do have the following in the spec:

   It is likely that the client will start transmitting the next
   MAX_PAYLOADS_SET before the server times out on waiting for the last
   of the previous MAX_PAYLOADS_SET.  On receipt of a payload from the
   next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity
   Incomplete) Response Code indicating any missing payloads from any
   previous MAX_PAYLOADS_SET.  Upon receipt of the 4.08 (Request Entity
   Incomplete) Response Code, the client SHOULD send the missing
   payloads before continuing to send the remainder of the
   MAX_PAYLOADS_SET and then go into another NON_TIMEOUT delay prior to
   sending the next MAX_PAYLOADS_SET.

or

   It is likely that the server will start transmitting the next
   MAX_PAYLOADS_SET before the client times out on waiting for the last
   of the previous MAX_PAYLOADS_SET.  Upon receipt of a payload from the
   new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any
   missing payloads from any previous MAX_PAYLOADS_SET.  Upon receipt of
   such request, the server SHOULD send the missing payloads before
   continuing to send the remainder of the MAX_PAYLOADS_SET and then go
   into another NON_TIMEOUT delay prior to sending the next
   MAX_PAYLOADS_SET.
which will add in another degree of randomness depending which payload gets through to the receiver.

We don’t think that a change is needed here other than updating the quoted text to refer to NON_TIMEOUT_RANDOM instead of NON_TIMEOUT.


Martin

On Fri, May 21, 2021 at 12:17 PM <supjps-ietf@jpshallow.com<mailto: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

_________________________________________________________________________________________________________________________

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.