Re: [core] Éric Vyncke's No Objection on draft-ietf-core-new-block-11: (with COMMENT)

supjps-ietf@jpshallow.com Tue, 04 May 2021 08:05 UTC

Return-Path: <jon.shallow@jpshallow.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 D198B3A2A66 for <core@ietfa.amsl.com>; Tue, 4 May 2021 01:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
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 rS-cJ8wedTdL for <core@ietfa.amsl.com>; Tue, 4 May 2021 01:05:21 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 8F37A3A2A6A for <core@ietf.org>; Tue, 4 May 2021 01:05:21 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1ldq3S-0006FK-8i; Tue, 04 May 2021 09:05:18 +0100
From: supjps-ietf@jpshallow.com
To: "'Eric Vyncke (evyncke)'" <evyncke@cisco.com>, 'The IESG' <iesg@ietf.org>, mohamed.boucadair@orange.com
Cc: draft-ietf-core-new-block@ietf.org, core-chairs@ietf.org, core@ietf.org, marco.tiloca@ri.se, csp@csperkins.org, Emmanuel.Baccelli@inria.fr
References: <162004421064.19511.6477108778521848512@ietfa.amsl.com> <32469_1620045364_608FEE34_32469_195_1_787AE7BB302AE849A7480A190F8B933035375C5B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <165556CA-81F5-46F6-A40C-B4F3B69E03CC@cisco.com> <4090_1620111273_6090EFA9_4090_294_1_787AE7BB302AE849A7480A190F8B933035376354@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <4090_1620111273_6090EFA9_4090_294_1_787AE7BB302AE849A7480A190F8B933035376354@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Tue, 04 May 2021 09:05:13 +0100
Message-ID: <038501d740bc$3639b5a0$a2ad20e0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKGE6Nw3OFgz/ZV5pUWU0xmNvlPXAI8Dl6IAlhE7hUBPvCS36lGsmIQ
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/xW8Y9C7vuxwWo9lJSdV-jdntewc>
Subject: Re: [core] Éric Vyncke's No Objection on draft-ietf-core-new-block-11: (with 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 08:05:24 -0000

Hi Eric,

> >
> > EV> indeed, thank you. Now, whether this code has been tested in
> > several setups / test cases (bandwidth, packet loss, reboots) would
> > be interesting.
> >
> 
> [Med] It was tested in the context of DOTS telemetry. The list above shows
> how the testing was helpful to refine/assess the design.
> 

Libcoap provides the testing capability of one or more specific packets dropped, or randomly dropped. Testing was done with one or more packets missing from the start, around the MAX_PAYLOADS pause point, at the end as well as in the middle of a MAX_PAYLOAD sequence for both CON and NON.  Lessons learnt about the recoveries etc. updated the draft.

Logic tested with complete packet loss in one direction (for NON, CON fails here) confirming data still gets through.

Multiple concurrent sessions were run in parallel - including with enforced packet loss.

Applications running on the peers were restarted frequently (other peer remaining up) to checkout out recovery etc.

The block size (SZX) was deliberately set to a small size, thus considerably increasing the number of blocks needed to transfer large payloads to exercise that logic.  This brought about the addition of the 'Continue' logic.

Regards

Jon