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

mohamed.boucadair@orange.com Tue, 04 May 2021 09:01 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 771D43A2C16; Tue, 4 May 2021 02:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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_H2=-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 Yxz4NEoLPY9z; Tue, 4 May 2021 02:01:13 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 5CEC33A2C0B; Tue, 4 May 2021 02:01:08 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4FZDN16Qz9z5wpK; Tue, 4 May 2021 11:01:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620118865; bh=GM3ET2wu+avKOIjD5zRoQ2iV5P1uYAneKCktPE9mkB0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=tlVqoK16c8p+OMZ6ybaSPjOXj/xP4Ic/DhoGfJsDoLtGS8y0cgCZVwX1cSTKLlr71 yYsQ78miFxtEg2HxEydSp2+k1UXGV7eWiXGiYgxw+qrWInUSwyThJoEi+3KRrZ/4WE toJ7A0C5EwD2iu4OShLAZwkPVT3kkOcF/aJjizXvkYzpCAnXisw6TivP5+xJfcx1Fj EI+C2+LChp8Oqyr0K+iMgAtB2IHwSu1XEgaCnG9ny7gx980bOsHws7nfxivD/6ueq+ XcGNP9v/hWFx4RTQIpvEMM4HYKg7rsu5cz/siAKyzvskMjvlU6JSdDlbRzGs4U8U64 IWZLhoZc3qylg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4FZDN14mMWzDq7T; Tue, 4 May 2021 11:01:05 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Martin Duke <martin.h.duke@gmail.com>
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: Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
Thread-Index: AQHXPU6wbjJP1GdcPEqPLDpTNWikEarMh5CAgAV4iwCAAOpaQA==
Date: Tue, 4 May 2021 09:01:04 +0000
Message-ID: <21895_1620118865_60910D51_21895_367_1_787AE7BB302AE849A7480A190F8B9330353764A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <161973861706.19975.3092798532288165336@ietfa.amsl.com> <9640_1619783334_608BEEA5_9640_342_16_787AE7BB302AE849A7480A190F8B9330353751A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAM4esxS7E54VF8PQ=MAPeLJbRi_NY1jZoK15ZWyJhWyE9VVn+Q@mail.gmail.com>
In-Reply-To: <CAM4esxS7E54VF8PQ=MAPeLJbRi_NY1jZoK15ZWyJhWyE9VVn+Q@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.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330353764A2OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/jrrK3N6gpPK4ibs7DfX_KXtI5sw>
Subject: Re: [core] Martin Duke'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, 04 May 2021 09:01:19 -0000

Hi Martin,

Please see inline.

Cheers,
Med

De : Martin Duke [mailto:martin.h.duke@gmail.com]
Envoyé : lundi 3 mai 2021 20:57
À : 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: Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)



On Fri, Apr 30, 2021 at 4:48 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
>
> I can't reconcile (4.1) with the last sentence in (7.2).

[Med] Why? 4.1 can be done with default CoAP setting. The purpose of this CON request is to determine support of the functionality. We made this change:

OLD:
   Congestion control for CON requests and responses is specified in
   Section 4.7 of [RFC7252].  In order to benefit from faster
   transmission rates, NSTART will need to be increased from 1.
   However, the other CON congestion control parameters will need to be
   tuned to cover this change.  This tuning is not specified in this
   document given that the applicability scope of the current
   specification assumes that all requests and responses using Q-Block1
   and Q-Block2 will be Non-confirmable (Section 3.2).

NEW:
   Congestion control for CON requests and responses is specified in
   Section 4.7 of [RFC7252].  In order to benefit from faster
   transmission rates, NSTART will need to be increased from 1.
   However, the other CON congestion control parameters will need to be
   tuned to cover this change.  This tuning is not specified in this
   document given that the applicability scope of the current
   specification assumes that all requests and responses using Q-Block1
   and Q-Block2 will be Non-confirmable (Section 3.2) apart from the
                                                      ^^^^^^^^^^^^^^
   initial Q-Block functionality negotiation.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Does the functionality negotiation in (4.1) involve something other than sending Q-Block options?
[Med] No. All what is needed is to send the options in a CON message as per:

   To indicate support for Q-Block2 responses, the CoAP client MUST
   include the Q-Block2 Option in a GET or similar request (FETCH, for
   example), the Q-Block2 Option in a PUT or similar request (POST, for
   example), or the Q-Block1 Option in a PUT or similar request so that
   the server knows that the client supports this Q-Block functionality
   should it need to send back a body that spans multiple payloads.
   Otherwise, the server would use the Block2 Option (if supported) to
   send back a message body that is too large to fit into a single IP
   packet [RFC7959].

If so, then (4.1) ought to clarify that it's what you mean. If it's just a GET or whatever, then the text here is fine, but there needs to be more on congestion control for confirmable messages.


 Moreover, if
> my reading of (4.1) is correct, it's not sufficient to declare
> congestion control guidance out of scope when it's a mandated part of
> the protocol.
>

>
> - (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the
> same value as computed for EXCHANGE_LIFETIME", why are they different
> variables?

[Med] Because they refer to distinct aspects that may be tweaked separately: the timeout induced by PROBING_RATE and the one to observe for expired partial bodies.

 Or is that they SHOULD have the same value but might not?
> A normative word would be helpful here.

[Med] Not sure a change is needed here given the definition of the two parameters.

But they can't be tweaked separately! The spec states that they are both computed as EXCHANGE_LIFETIME. It does not allow for them to be set separately.
[Med] Ah, I see what confuses you. We made this change:

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

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

NEW:

   NON_PROBING_WAIT is used to limit the potential wait needed

   calculated 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]).


_________________________________________________________________________________________________________________________

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.