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

mohamed.boucadair@orange.com Fri, 30 April 2021 13:13 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 D29D03A1777; Fri, 30 Apr 2021 06:13:09 -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 tLUD2gbVO0Zv; Fri, 30 Apr 2021 06:13:05 -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 15E293A1776; Fri, 30 Apr 2021 06:13:05 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 4FWt8b11j6z5wCb; Fri, 30 Apr 2021 15:13:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1619788383; bh=OKuJIM1XA5ROTgFc5u4pLKUD+ZwuZmGF1s8jeR+8DKE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=B4+S2s43U9qSkCYCV1zmIiZf8S3fMgtkbX7D6WZi/ZLxIePiNoy38eKlxoI9eM3dY zUw8vR1KoTiPmY18dhj3aLlfEA4gJ/vwlituGNaipwhGhI1NX0iaUPBhJ+D/Q9Remy nSLYeIqObuKGJAERNknGjEm7yvuMDzPYUXp/vyxx0ynBxsgDsp++1BWiAmxsdwsD+i XIri/DX/NTIFf9/AxFmSweiAJTbGzEk7TSgLntmUDUdel52pafSgxCIzn4Iyyelcpw slLZ2hRu3q0SRYObpHEKch7xizhWVLOmmPKGIEqhlqgrb4L9Kkwz8JoayB6/wld4kM 4J6sx0F+Mfk1Q==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4FWt8Z6sfnz8sYn; Fri, 30 Apr 2021 15:13:02 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Colin Perkins <csp@csperkins.org>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "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: AQHXPbBYH8Yl+HsopE691vYfsp0InarM7XGw
Date: Fri, 30 Apr 2021 13:13:01 +0000
Message-ID: <32339_1619788383_608C025E_32339_340_7_787AE7BB302AE849A7480A190F8B93303537522B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <161964687448.26837.8092317722890333336@ietfa.amsl.com> <32001_1619679152_608A57B0_32001_95_1_787AE7BB302AE849A7480A190F8B93303537462E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <53FBD74C-D8CF-41B9-A67D-836760FE111B@csperkins.org>
In-Reply-To: <53FBD74C-D8CF-41B9-A67D-836760FE111B@csperkins.org>
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/Wqzil-afcYVucKihwnEVqtc5pFc>
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: Fri, 30 Apr 2021 13:13:10 -0000

Hi Colin, 

Please see inline. (removed items that are addressed)

Cheers,
Med

PS: The changes can be tracked here: https://tinyurl.com/new-block-latest 

> -----Message d'origine-----
> De : Colin Perkins [mailto:csp@csperkins.org]
> Envoyé : vendredi 30 avril 2021 13:02
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : tsv-art@ietf.org; core@ietf.org; draft-ietf-core-new-
> block.all@ietf.org; last-call@ietf.org
> Objet : Re: Tsvart last call review of draft-ietf-core-new-block-11
> 
> Hi,
> 
> [inline]
> 
> On 29 Apr 2021, at 7:52, mohamed.boucadair@orange.com wrote:
> > 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
> >>
> 
> >>
> >> 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.
> 
> This would be a lot clearer if Section 3.2 were cross-referenced, and
> a reminder of the limited applicability of this specification was
> added to Section 7.2.
> 

[Med] Made this change: 

OLD:
      Note: The default value of 10 is chosen for reasons similar to
      those discussed in Section 5 of [RFC6928].

NEW:
      Note: The default value of 10 is chosen for reasons similar to
      those discussed in Section 5 of [RFC6928], especially given the
      target application discussed in 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.
> 
> Makes sense, although I wonder if the text in Section 7.2 might be
> more clearly written “The DOTS application uses customised defaults
> for PROBING_RATE and other transmission parameters, as discussed in
> Section
> 4.5.2 of [RFC8782], that are negotiated between peers”?
> 

[Med] Thank you, but I prefer the old wording.  

> 
> >> 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.
> 
> Might be worth stating that in the draft?
> 

[Med] After thinking about this further, we added this NEW text:

NEW:
   Following a period of 24 hours where no packet
   recovery was required, the value of MAX_PAYLOADS can be increased by
   1 (but without exceeding the default value) for a further 24 hour
   evaluation.

_________________________________________________________________________________________________________________________

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.