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

mohamed.boucadair@orange.com Fri, 30 April 2021 11:49 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 3D97A3A1266; Fri, 30 Apr 2021 04:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Level:
X-Spam-Status: No, score=-2.818 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, RCVD_IN_DNSWL_LOW=-0.7, 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 tsz63_B8duOM; Fri, 30 Apr 2021 04:48:56 -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 E015B3A126B; Fri, 30 Apr 2021 04:48:55 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4FWrHV1Pbxz2yYS; Fri, 30 Apr 2021 13:48:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1619783334; bh=kBwB7fZKnXuUcOqJtn/z3fdSQx1nZ8L7W3vw4OH66zk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IFKTOw7fvcuerTcdWZnGsPIKxexgh4dEmVcG0KLDdrWB+h3SZ9nXHEfQdo9ch3Xv1 sE14YtIPcJI0tkQ6YlulKckc4rYY9fp0nzy7HIyA3Y4Wq46yKYNCcKgbcvFWrRbX06 Xxn9w//ztL85mV3se49E0lpT6UdHaNC9728DiGCOi2hyenLYTp8UVOrL2X4omE9QqB 5xMlgYFu2FZuqKPUqlBBCzL4Wch0qMqHNGD/IrZz8CBfjOr/0LxacrBWbAxx8tlj7O wTgHtPosTONUUlpZ0hnx+gDyfry07TDO131mHABklaDtN4g4797v+JKdziVqSec93M wxQwCZgWtP3hQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4FWrHT6zLTzBrLs; Fri, 30 Apr 2021 13:48:53 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Martin Duke <martin.h.duke@gmail.com>, The IESG <iesg@ietf.org>
CC: "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: AQHXPU6wbjJP1GdcPEqPLDpTNWikEarMh5CA
Date: Fri, 30 Apr 2021 11:48:53 +0000
Message-ID: <9640_1619783334_608BEEA5_9640_342_16_787AE7BB302AE849A7480A190F8B9330353751A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <161973861706.19975.3092798532288165336@ietfa.amsl.com>
In-Reply-To: <161973861706.19975.3092798532288165336@ietfa.amsl.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/sD3EHFsAv-te31AKdEFUJru4Svs>
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: Fri, 30 Apr 2021 11:49:01 -0000

Hi Martin, 

Thank you for the review. The changes can be tracked at: https://tinyurl.com/new-block-latest. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Martin Duke via Datatracker [mailto:noreply@ietf.org]
> Envoyé : vendredi 30 avril 2021 01:24
> À : The IESG <iesg@ietf.org>
> Cc : draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org;
> core@ietf.org; marco.tiloca@ri.se; marco.tiloca@ri.se
> Objet : Martin Duke's Discuss on draft-ietf-core-new-block-11: (with
> DISCUSS and COMMENT)
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-core-new-block-11: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-new-block/
> 
> 
> 
> ---------------------------------------------------------------------
> -
> DISCUSS:
> ---------------------------------------------------------------------
> -
> 
> I am concerned about the convergence of three different provisions in
> this spec:
> 
> - In (4.1), it says "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."
> 
> IIUC this mandates that at least one request will use CON.
> 
> - (7.1): all the blocks of a single body over an
>    unreliable transport MUST either all be Confirmable or all be Non-
>    confirmable.
> 
> - (7.2) However, the other CON congestion
>    control parameters will need to be tuned to cover this change.
> This
>    tuning is out of scope of this document as it is expected that all
>    requests and responses using Q-Block1 and Q-Block2 will be Non-
>    confirmable (Section 3.2).
> 
> 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.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 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.
> 
> 
> ---------------------------------------------------------------------
> -
> COMMENT:
> ---------------------------------------------------------------------
> -
> 
> Thank you for the examples. They were useful in providing an overview
> of the protocol.
> 
> Thanks also to Colin Perkins for an especially thoughtful TSVART
> review. Please address his comments, although his concerns about
> (7.1) are IMO mostly subsumed by my DISCUSS.
> 
> - It would be useful to introduce the "token", "request tag", and
> "Etag"
> concepts before using them. Reading front-to-back, I spent most of
> Section 4 confused.

[Med] As called out in Section 2, the assumption is that the reader is familiar with CoAP concepts. That’s said, we can add some key concepts. We made this change: 

OLD:
   Readers should be familiar with the terms and concepts defined in
   [RFC7252], [RFC7959], and [RFC8132].  

NEW:
   Readers should be familiar with the terms and concepts defined in
   [RFC7252], [RFC7959], and [RFC8132].  Particularly, the document uses
   the following key concepts:

   Token:  is used to match responses to requests independently from the
      underlying messages (Section 5.3.1 of [RFC7252]).

   ETag:  is used as a resource-local identifier for differentiating
      between representations of the same resource that vary over time
      (Section 5.10.6 of [RFC7252]).

   Request-Tag refers an option that allows a CoAP server to match
   message fragments belonging to the same request
   [I-D.ietf-core-echo-request-tag].

> 
> - (4.4) It would be useful to state that clients MUST (SHOULD?) NOT
> request retransmission of blocks from ETags that are not "fresh" --
> IIUC, they probably don't exist anymore, and anyway the server has no
> way of knowing which non-fresh ETag to serve beacuse it says "The
> ETag Option should not be used in the request for missing blocks"
> 
> BTW, s/should/SHOULD

[Med] We used to have the normative language but we changed it as per a valid comment we received from the WG. The reasoning is that this is more a factural statement than a normative one. The client cannot use it to retrieve a missing block as the server may reply with 2.03 (Valid) (which has no data) instead of 2.05 (Content) if a valid ETag was included.    

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

_________________________________________________________________________________________________________________________

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.