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 16:33 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 737293A113F; Tue, 4 May 2021 09:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Dn4VizJaW_dY; Tue, 4 May 2021 09:33:36 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 581893A1271; Tue, 4 May 2021 09:33:12 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4FZQPd3sQ5z1yw9; Tue, 4 May 2021 18:33:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620145989; bh=PMNdAPe2KRyKbCfkjO3Q+3Ry8lsT/xlK3J+xkciKhE8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=I0eEBZG5+FolaM0e8Zm4Vqs6EEJdbf0UunfsDuUFNWgmO3Zg50HJ/9JfoLkOflo9O 5jN5Bv4KXaKfR+OR+Kfk5QAROGSkEPUHOqyWo9l4jWZsMAZbac04oXOF+X93uLXp86 +21ZhI0oH3sdAXBCw0r+3Hkwfv66Z6AnCaWjFZayvGNLZL0EH0KcZDkLJKIJYjEkdj L0d5/qrARgE2sLhIuJv1SXEb3OnV/LLL9WX6napemM/dU/A9zi5J3kbk5hzHv76Kng aG3V/VdbKpQ50VNogZJGoWx2EZWJw86VuouACyznvvxVsJPoTFkepyvwQSJR4guYIo F7mqwsMyQO9KA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4FZQPd2z5GzDq7l; Tue, 4 May 2021 18:33:09 +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: AQHXPU6wbjJP1GdcPEqPLDpTNWikEarMh5CAgAV4iwCAAOpaQIAAbaOAgAAv2jA=
Date: Tue, 4 May 2021 16:33:08 +0000
Message-ID: <18827_1620145989_60917745_18827_231_1_787AE7BB302AE849A7480A190F8B93303537688C@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> <21895_1620118865_60910D51_21895_367_1_787AE7BB302AE849A7480A190F8B9330353764A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAM4esxS=q-NRUp4ph8oPjwWhY1uznDqH1p5YQ1WfWTy+TAVERg@mail.gmail.com>
In-Reply-To: <CAM4esxS=q-NRUp4ph8oPjwWhY1uznDqH1p5YQ1WfWTy+TAVERg@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_787AE7BB302AE849A7480A190F8B93303537688COPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/rEzYG8EmOJwhL0k1S8JFGAQtNsE>
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 16:33:42 -0000

Re-,

We are not seeking for performance enhancement when determining Q-Block support. This why I indicated in my first reply that no change to the base CC is needed for that. We updated the text as follows:

OLD:
   With CoAP over UDP, the way a request message is rejected for
   critical options depends on the message type.  A Confirmable message
   with an unrecognized critical option is rejected with a 4.02 (Bad
   Option) response (Section 5.4.1 of [RFC7252]).  A Non-confirmable
   message with an unrecognized critical option is either rejected with
   a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of
   [RFC7252]).  To reliably get a rejection message, it is therefore
   REQUIRED that clients use a Confirmable message for determining
   support for Q-Block1 and Q-Block2 Options.

NEW:
   With CoAP over UDP, the way a request message is rejected for
   critical options depends on the message type.  A Confirmable message
   with an unrecognized critical option is rejected with a 4.02 (Bad
   Option) response (Section 5.4.1 of [RFC7252]).  A Non-confirmable
   message with an unrecognized critical option is either rejected with
   a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of
   [RFC7252]).  To reliably get a rejection message, it is therefore
   REQUIRED that clients use a Confirmable message for determining
   support for Q-Block1 and Q-Block2 Options.  This CON message can be
   sent under base CoAP congestion control setup specified in
   Section 4.7 of [RFC7252] (that is, NSTART does not need to be
   increased).

Cheers,
Med

De : Martin Duke [mailto:martin.h.duke@gmail.com]
Envoyé : mardi 4 mai 2021 17:28
À : 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)

OK, we've reached understanding on the NON_PROBING_WAIT/NON_PARTIAL_TIMEOUT issue. Thank you for the edit.

I also now understand that essentially every connection will have a Q-block exchange using CON. As this is an integral part of the protocol, I don't believe it's sufficient for Sec 7.1 to declare congestion control parameters out of scope, unless there's a normative reference to some other draft that explains how to do it.

Thanks
Martin

On Tue, May 4, 2021 at 2:01 AM <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Martin,

Please see inline.

Cheers,
Med

De : Martin Duke [mailto:martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>]
Envoyé : lundi 3 mai 2021 20:57
À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Cc : The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; draft-ietf-core-new-block@ietf.org<mailto:draft-ietf-core-new-block@ietf.org>; core-chairs@ietf.org<mailto:core-chairs@ietf.org>; core@ietf.org<mailto:core@ietf.org>; marco.tiloca@ri.se<mailto: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.