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

supjps-ietf@jpshallow.com Wed, 12 May 2021 09:36 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 3B7643A3B67 for <core@ietfa.amsl.com>; Wed, 12 May 2021 02:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MJVCzkOk4-gP for <core@ietfa.amsl.com>; Wed, 12 May 2021 02:36:43 -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 B9E5C3A3B68 for <core@ietf.org>; Wed, 12 May 2021 02:36:43 -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 1lglIG-0004KH-Gh; Wed, 12 May 2021 10:36:40 +0100
From: <supjps-ietf@jpshallow.com>
To: "'Lars Eggert'" <lars@eggert.org>, <mohamed.boucadair@orange.com>
Cc: <draft-ietf-core-new-block@ietf.org>, <core-chairs@ietf.org>, "'The IESG'" <iesg@ietf.org>, <core@ietf.org>, <marco.tiloca@ri.se>
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> <17932_1620739727_609A868F_17932_314_1_787AE7BB302AE849A7480A190F8B9330353854D5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org>
In-Reply-To: <39AC6D5F-0FA3-4FE3-BD59-302B65CFDE49@eggert.org>
Date: Wed, 12 May 2021 10:36:43 +0100
Message-ID: <03a501d74712$516f6fc0$f44e4f40$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEp71xGbs3/HDljMxiZ+ChpLivgHgKIHcrlApPqG38CEWvyxQJ3w676AJILkT0BGVdVmavfrZtg
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lcweSLRKYWpKv6l-dNITuK3fhDI>
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: Wed, 12 May 2021 09:36:49 -0000

Hi Lars,

I will come up with draft changes if the below is acceptable to you.

Please see inline.

Regards

Jon

> -----Original Message-----
> From: Lars Eggert [mailto: lars@eggert.org]
> Sent: 11 May 2021 18:27
> To: mohamed.boucadair@orange.com
> Cc: draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; The IESG;
> core@ietf.org; marco.tiloca@ri.se
> Subject: Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with
> DISCUSS and COMMENT)
> 
> Hi,
> 
> On 2021-5-11, at 16:28, mohamed.boucadair@orange.com wrote:
> >> 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.
> 
> this says that draft-ietf-core-new-block works where RFC7959 fails. While
> it's technically true that this makes draft-ietf-core-new-block infinitely
> faster then RFC7959, I didn't understand that that was what the title,
> abstract and some other places in the document meant - it sounded to me
> that a performance difference compared to RFC7959 was the motivation for
> draft-ietf-core-new-block?

[Jon] No-  performance was not the original motivation.  We appear to have
been focused on highlighting the performance benefits rather that this draft
is supporting a missing piece out RFC7252/RFC7959, namely robustly
supporting of Non-Confirmable using a block-wise transfer.  It just happened
that there was a performance benefit (as seen with TCP sliding window where
each packet does not have to be acknowledged before sending the next one)
which we got excited about.

[Jon] I will look at updating the emphasis in the draft, including the title
and abstract which were there from the initial drafts and never properly
revisited.

[Jon] The presentation given at Interim Core 13 May 2020
https://datatracker.ietf.org/meeting/interim-2020-core-04/materials/slides-i
nterim-2020-core-04-sessa-new-coap-block-wise-transfer-options-draft-bosh-co
re-new-block-01.pdf Slide 4 highlights the RFC7959 issue when using
Non-Confirmable and lossy traffic, Slides 5 - 9 working through the issues
we had found up to that point.

[Jon] As can be seen the IETF 109 presentation
https://datatracker.ietf.org/meeting/109/materials/slides-109-core-sessa-dra
ft-ietf-core-new-block-01.pdf Slide 5 there was a lot of debate over the
naming of this Block option and ended up with Q-Block - again implying
performance.

[Jon] As a side note, if returning acknowledgement traffic from the remote
peer is getting dropped, the large request (or large response) will still
get through, albeit with a timeout of NON_TIMEOUT every MAX_PAYLOADS.  It is
more important (certainly in the DOTS case) to get the information through
than how fast could it get there. (Overall transmission rate is kept low,
covered by PROBING_WAIT, with an upper limit wait timeout of
NON_PROBING_WAIT).

> 
> Because if it's purely about not failing, you could make
draft-ietf-core-new-
> block (much) less aggressive and all my issues would go away. Is that a
way
> forward here?

[Jon] Yes, agreed.
> 
> If not, and a performance difference is part of the motivation, I think a
> Proposed Standard should refer to some analysis that demonstrates that in
> a number of scenarios of interest.

[Jon] I don't think that this is needed now.

> 
> >> 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 says "only use this for DOTS". But it doesn't discuss whether
draft-ietf-
> core-new-block is only deemed safe for DOTS scenarios in which a DDoS is
> present, or also in cases where a DDoS is absent, and it doesn't cite any
> analysis into *why* this recommendation can safely be made. If DOTS uses
> draft-ietf-core-new-block, what is the impact on crosstraffic?

[Jon] Good point.  I cannot think of any reason as to why it would not be
safe for any environment that supports Q-Block (subject to the noted
limitations list - hence comment about "intended use case should be
carefully weighed") .  As Q-Block1 and Q-Block2 are 'Critical', then if an
agent does not support Q-Block, there can be a fall-back to RFC7959 Block.
Also see next comment.

> 
> (Also, in the IESG discussion the point was brought up that
draft-ietf-core-
> new-block may form the basis for a revision of RFC7959, so it's a bit odd
to
> see this strict limitation on one application and/or a very specific
scenario.)
> 

[Jon] Initially, the WG were concerned that people would see this draft as
an alternative to RFC7959 (e.g. draft name of new-block) and wanted us to
highlight the limitations and indicate that it had come about from the DOTS
requirements. At that point, it was looking as if we may have to alter some
RFC7959 block characteristics to get things working.  After much discussion
/ brainstorming ways to handle Congestion  Control / Recovery there is no
longer any need to violate any of the RFC7252/RFC7959 principles.  Hence the
later WG thinking about the possibility of using this draft as material for
a RFC7959-bis.
 
> > 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