Re: [core] Tsvart last call review of draft-ietf-core-new-block-11
Colin Perkins <csp@csperkins.org> Fri, 30 April 2021 13:19 UTC
Return-Path: <csp@csperkins.org>
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 3AE873A17AC; Fri, 30 Apr 2021 06:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_MED=-2.3, SPF_PASS=-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=csperkins.org
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 VAJ0SnMWXpmf; Fri, 30 Apr 2021 06:19:07 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0846A3A17AB; Fri, 30 Apr 2021 06:19:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=+L+a79t5JGZ8AJE79jK+QY2mQa5n7adam1wiHZITNwg=; b=fvMhPS8ERjB9jXtMcP22qIeJLv 0MLzT0jFzyTcr9oyqqhJPJ3e8/pZYmc5D2xJ19oGb/biP39PHNO/IkZ4pZSrSOblEgJCIrMXnSx2W pvr1mBy6uz1/KlawJPoQH641hyAlOywliTTdEZ/kHma/3KGREHQN6IgM0pMmifAhJQ75/26IkoAc0 YFM4cnxiJIbLLWHij83PNzjltb464nnwXdZC15++l2QP5oSXYDTe7fqB8Kz3//E3Fa57w8XNuIJO+ dsvXgaDD1c4wqTocHMYJBI+0DDl3SzBoT+RH8HG9V1UJiDEdsI/bGeqS7Aq+k98ZLlB/VEeNwTWwp NsaEuS9w==;
Received: from [81.187.2.149] (port=35708 helo=[192.168.0.69]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1lcT2u-0000bx-2U; Fri, 30 Apr 2021 14:19:04 +0100
From: Colin Perkins <csp@csperkins.org>
Message-Id: <55772F99-57FE-42DE-B300-B9EE31626997@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_99A4DF44-8DF0-48B3-AAA0-84F1333178C5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
Date: Fri, 30 Apr 2021 14:18:58 +0100
In-Reply-To: <32339_1619788383_608C025E_32339_340_7_787AE7BB302AE849A7480A190F8B93303537522B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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>
To: mohamed.boucadair@orange.com
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> <32339_1619788383_608C025E_32339_340_7_787AE7BB302AE849A7480A190F8B93303537522B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.104.20)
X-BlackCat-Spam-Score: 14
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Mb18AeaBnsJwpj3MA21CTSz0rv8>
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:19:12 -0000
That’s all fine – thank you! Colin > On 30 Apr 2021, at 14:13, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote: > > 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 <https://tinyurl.com/new-block-latest> > >> -----Message d'origine----- >> De : Colin Perkins [mailto:csp@csperkins.org <mailto:csp@csperkins.org>] >> Envoyé : vendredi 30 avril 2021 13:02 >> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> >> Cc : tsv-art@ietf.org <mailto:tsv-art@ietf.org>; core@ietf.org <mailto:core@ietf.org>; draft-ietf-core-new- >> block.all@ietf.org <mailto:block.all@ietf.org>; last-call@ietf.org <mailto: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. -- Colin Perkins https://csperkins.org/
- [core] Tsvart last call review of draft-ietf-core… Colin Perkins via Datatracker
- Re: [core] Tsvart last call review of draft-ietf-… mohamed.boucadair
- Re: [core] Tsvart last call review of draft-ietf-… Colin Perkins
- Re: [core] Tsvart last call review of draft-ietf-… mohamed.boucadair
- Re: [core] Tsvart last call review of draft-ietf-… Colin Perkins