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

mohamed.boucadair@orange.com Tue, 11 May 2021 13:28 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 19F143A17E3; Tue, 11 May 2021 06:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.098
X-Spam-Level:
X-Spam-Status: No, score=-1.098 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, PDS_BAD_THREAD_QP_64=0.998, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2XQiWFWHDIzf; Tue, 11 May 2021 06:28:49 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 54AD23A17E0; Tue, 11 May 2021 06:28:49 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4Ffdzg5Ft9z16k8; Tue, 11 May 2021 15:28:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620739727; bh=Nb4p7AFUBgjDmDtvO+Vd2Aj02CQnXj4yYHNT1uL0Hw0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hoHGhqArn7MXKXohf0K9TVVjpzZZ0nEgnQ1e176zRsP3aKo10wY4RlRSqcLBhOQoH p4XYICh7izOXP8TetmhaIvE711ZLVcoBQyvBGdqZDMAY0E8zshvj8c10QiX2wCeoLF IJPfMuYgIcZxW+3cDSSFxb5IpfOpH6DrMW+bxRR4j0KbYiSFYKWVDQ6znxCWC1O6D2 oB8AMilskvdRXT3YZFGWk8P88T4EMKMj1GKEv3K6qF+OfhsS4KXP7CQWAnXPfV+oF4 VRuy6qI2ylOZRZFIjHA8Z1p0AqgyUlQvWWavTDbsGeoZDmGgQKd12avscw9qAeNWNq sqrjiwifXV1Pw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4Ffdzg3hS8zDq8B; Tue, 11 May 2021 15:28:47 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Lars Eggert <lars@eggert.org>
CC: The IESG <iesg@ietf.org>, "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: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
Thread-Index: AQHXRmcjbs3/HDljMxiZ+ChpLivgHqreQwXQ
Date: Tue, 11 May 2021 13:28:46 +0000
Message-ID: <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <162039183121.15574.16597240090409070575@ietfa.amsl.com> <29803_1620395762_609546F2_29803_68_1_787AE7BB302AE849A7480A190F8B9330353787B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <666D5FF1-9E96-4522-A0FB-0A3042225BE7@eggert.org> <17373_1620734755_609A7323_17373_63_1_787AE7BB302AE849A7480A190F8B933035384380@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <47273993-E4D3-4042-85B5-17163C984B18@eggert.org>
In-Reply-To: <47273993-E4D3-4042-85B5-17163C984B18@eggert.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/q-arzvD4zs7aug0LLADBFVl6FP0>
Subject: Re: [core] Lars Eggert'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: Tue, 11 May 2021 13:28:54 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Lars Eggert [mailto:lars@eggert.org]
> Envoyé : mardi 11 mai 2021 15:11
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : The IESG <iesg@ietf.org>; draft-ietf-core-new-block@ietf.org;
> core-chairs@ietf.org; core@ietf.org; marco.tiloca@ri.se
> Objet : Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11:
> (with DISCUSS and COMMENT)
> 
> Hi,
> 
> On 2021-5-11, at 15:05, mohamed.boucadair@orange.com wrote:
> > We prepared some material for your to describe the methodology and
> to list various interops and other useful pointers:
> > https://github.com/core-wg/new-
> block/blob/master/testing%20methodology.md
> 
> thanks for the pointer, Med. This is a clear description of the tests
> that were done, most (all?) of which seem to be focused on regression
> and interop testing.
> 
> What I was hoping to see, however, were some results that quantified
> the performance and safety aspects of this proposal. I tried to
> explain what I was looking for in my DISCUSS. draft-ietf-core-new-
> block basically proposes a send rate control mechanism, to be used in
> DDoS scenarios, i.e., a component of a transport protocol. The IETF
> has a pretty well-developed approach for analyzing such mechanisms.
> As part of that analysis, one would investigate a number of things:
> 
> 1. The motivation for draft-ietf-core-new-block seems to be a lack of
> performance with RFC7959. For a Proposed Standard, I would expect
> there to be an evaluation that draft-ietf-core-new-block achieves
> that desired level of performance over RFC7959, in a number of
> scenarios of interest. This is to establish that the proposed
> mechanism is fit for purpose.

[Med] We thought that this is covered by this part of the text: 

==
Libcoap was tested with complete packet loss in one direction (for NON) confirming data still gets through, albeit more slowly with the NON_TIMEOUT timeout for every MAX_PAYLOADS packets adding to the overall transmission time. Note that CON fails under these conditions, and as such RFC7959 fails to retrieve the body.
==

The performance comparison is straightforward as RFC7959 (with CON messages) fails while the body is successfully retrieved using the new-block.

> 
> 2. For a Proposed Standard, I would also expect to see an evaluation
> whether draft-ietf-core-new-block achieves that desired level of
> performance in non-DDoS scenarios *without* unduly affecting
> competing traffic. (Or else there needs to be an applicability
> statement that draft-ietf-core-new-block MUST only be used under
> DDoS, and a reference needs to be given for how a DDoS scenario can
> be reliably determined.)

[Med] We do have the following applicability scope (an excerpt below):  

   The block-wise transfer specified in [RFC7959] covers the general
   case, but falls short in situations where packet loss is highly
   asymmetrical.  The mechanism specified in this document provides
   roughly similar features to the Block1/Block2 Options.  It provides
   additional properties that are tailored towards the intended use case
   of Non-Confirmable transmission.  Concretely, this mechanism
   primarily targets applications such as DDoS Open Threat Signaling
   (DOTS) that cannot use CON responses to handle potential packet loss
   and that support application-specific mechanisms to assess whether
   the remote peer is not overloaded and thus is able to process the
   messages sent by a CoAP endpoint (e.g., DOTS heartbeats in
   Section 4.7 of [RFC8782]).
   ...
   This mechanism is not intended for general CoAP usage, and any use
   outside the intended use case should be carefully weighed 

I think that we do already have the guards clearly explained. If you don't think so, can you please share which change you would like see in the applicability scope?

 This is so the proposed mechanism can be
> recommended as the IETF solution for a given use case, without too
> many restrictions.
> 
> To be clear, that is not material that would be in the specification.
> Such material would probably be presented to the WG early during the
> standardization process (often at adoption time), and referred to in
> the specification. In other words, I'm not asking you or the WG to
> now go and perform this analysis - I'm asking whether it has been
> performed already, because that is to me the deciding factor in
> whether I can ballot "no objection" to publishing this as a Proposed
> Standard.
> 
> I hope this clarifies things further?
> 
> Thanks,
> Lars


_________________________________________________________________________________________________________________________

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.