Re: [core] Tsvart last call review of draft-ietf-core-new-block-11

mohamed.boucadair@orange.com Thu, 29 April 2021 06:52 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 C9BAC3A32DD; Wed, 28 Apr 2021 23:52:40 -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 KIDtrTgKynUE; Wed, 28 Apr 2021 23:52: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 70D563A32DB; Wed, 28 Apr 2021 23:52:35 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4FW5m04bY5z5w3Y; Thu, 29 Apr 2021 08:52:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1619679152; bh=m3Ec6jqAw3weAYhqlHWWOOVIGws092QY8ET5+pZG3XA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=dVrf2ZYomAci7okJVwSZp9h8nDA3Cz8Xgt0zj0enl2TjsG53ToMXYdGBclWAbhvYz gEAUJ4Yv+6KWRxhEUsYniDHtlYcJP8sEebTMLiburURKUa+rs+0IcXftnp8EPNNI7m 987jY+kVj+fCpWStbHp5ZS4idE1OFPYwbdhtxHs1gF/aLXzkAC45eWzCDItY+uzb6y vzCbqqaFq0QpGVysK9OWvjMgJMaLLMCWwluTXiQfPq85COWRepmN9C+3IBf3p2zGd/ l0qC4vY/Vo9/hj2laxFcV5zJw2/RUb9ZXgUGibC1m/7fZQAVh+ayJVkyxBdeX+e8NT VWgb7tK05jNUw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4FW5m03pvDzDq8n; Thu, 29 Apr 2021 08:52:32 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Colin Perkins <csp@csperkins.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "core@ietf.org" <core@ietf.org>, "draft-ietf-core-new-block.all@ietf.org" <draft-ietf-core-new-block.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-core-new-block-11
Thread-Index: AQHXPHkVRkejB4Kn+k2ZJQYtAcqcVKrK9s4w
Date: Thu, 29 Apr 2021 06:52:31 +0000
Message-ID: <32001_1619679152_608A57B0_32001_95_1_787AE7BB302AE849A7480A190F8B93303537462E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <161964687448.26837.8092317722890333336@ietfa.amsl.com>
In-Reply-To: <161964687448.26837.8092317722890333336@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/snlLZtwxYj6vGWSD5zdrHAHsuxA>
Subject: Re: [core] Tsvart last call review of draft-ietf-core-new-block-11
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: Thu, 29 Apr 2021 06:52:41 -0000

Hi Colin,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Colin Perkins via Datatracker [mailto:noreply@ietf.org]
> Envoyé : mercredi 28 avril 2021 23:55
> À : tsv-art@ietf.org
> Cc : core@ietf.org; draft-ietf-core-new-block.all@ietf.org; last-
> call@ietf.org
> Objet : Tsvart last call review of draft-ietf-core-new-block-11
> 
> Reviewer: Colin Perkins
> Review result: Ready with Issues
> 
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments
> were written primarily for the transport area directors, but are
> copied to the document's authors and WG to allow them to address any
> issues raised and also to the IETF discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider
> this review as part of the last-call comments they receive. Please
> always CC tsv-art@ietf.org if you reply to or forward this review.
> 
> Thank you for preparing such a clearly written, precise,
> specification. On the whole, this is very good. I just have some
> minor issues to consider.

[Med] Thanks. 

> 
> Section 4.1 says “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, or the Q-Block1 Option in a PUT or similar request so that
> the server knows that the client supports this Q-Block functionality”
> – It would be useful to enumerate what are “similar” requests.

[Med] Argh, I thought we added an example as we did for GET. Thanks for catching this. We can cite POST or PATCH.

> 
> Section 5: “Such messages must not be treated by the client as a
> fatal error“
> - I was surprised this is not a normative MUST NOT.

[Med] We don't use the normative language here as we though this is implicitly covered by the behavior in 4.3 where we indicate that the client retransmits the missing blocks when such error is received. 

> 
> Section 7.1: “For 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 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).” - The way this is phrased is difficult to parse.
> I can interpret it as saying that the transmission rate *does* need
> to be faster, so implementations need to increase NSTART and tune the
> other parameters.
> Alternatively, I can interpret this as saying that *if* the
> transmission needs to be faster, then NSTART and the other parameters
> need to be tuned in some as-yet-unspecified way. The text would
> benefit from being rephrased to clarify which meaning is intended.
> 
> What happens when NSTART is increased beyond 1, and how the other
> parameters are tuned, is unclear. The text would be better if it
> either cross-referenced to the definition of how the parameters are
> to be tuned, or explicitly stated that this is not yet supported and
> will need to be defined in some future extension.

[Med] Updated as follows:

OLD: 
   Congestion control for CON requests and responses is specified in
   Section 4.7 of [RFC7252].  For 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 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).

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

> 
> In Section 7.2, I’m not convinced by the argument to set MAX_PAYLOAD
> to 10 for similar reasons to RFC 6928. The types of link layer that
> CoAP runs over are very different to those measured to support the
> increase in TCP’s initial window. An argument based on typical
> properties of links and buffer space in networks used by CoAP would
> be more convincing (I accept that using MAX_PAYLOAD of 10 is not
> going to do any significant harm, even if it is higher than optimal).

[Med] Actually we set it to 10 as the applicability scope of this spec is DOTS which runs in environments similar to those of 6928. Please see Section 3.2.

> 
> Section 7.2 also notes that “PROBING_RATE and other transmission
> parameters are negotiated between peers”. It would be appropriate to
> give some guidance on what are the bounds for safe values that can be
> negotiated for these parameters.

[Med] I'm afraid this is out of the scope of this spec. The intent of this note is to provide an example of an application that negotiates these parameters. Some of these details can be found in in rfc8782#section-4.5.2 mentioned in the text you quoted. 

> 
> Section 7.2 says:
> 
> >   As the sending of many payloads of a single body may itself cause
> >   congestion, it is RECOMMENDED that after transmission of every
> set of
> >   MAX_PAYLOADS payloads of a single body, a delay is introduced of
> >   NON_TIMEOUT before sending the next set of payloads to manage
> >   potential congestion issues.
> 
> and the following paragraph has guidance for reducing MAX_PAYLOADS if
> persistent congestion occurs “for at least a 24 hour period and it is
> known that there are no other network issues over that period”. It’s
> not clear how an implementation will know about other network issues,

[Med] An example is a DDoS attack. Made this change: s/about other network issues/about other network issues (e.g., DDoS attacks)

> and I would suggest that even if there are such issues, backoff would
> be appropriate given persistent congestion.
> 
> Finally, is there are mechanism for gradually recovering MAX_PAYLOADS
> to its original value, if persistent loss ceases for some period?
> 

[Med] This is covered by the configuration refresh/negotiation mechanism. The peers will refresh the configuration parameters following, for example, I-D.bosh-dots-quick-blocks.   

_________________________________________________________________________________________________________________________

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.