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 14:59 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 C47F43A0883 for <core@ietfa.amsl.com>; Wed, 12 May 2021 07:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 JhCX-w7a6wsg for <core@ietfa.amsl.com>; Wed, 12 May 2021 07:59:44 -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 839483A0874 for <core@ietf.org>; Wed, 12 May 2021 07:59:44 -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 1lgqKr-0004UL-4v; Wed, 12 May 2021 15:59:41 +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:
Date: Wed, 12 May 2021 15:59:43 +0100
Message-ID: <041601d7473f$7113e540$533bafc0$@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+ChpLivgHgKIHcrlApPqG38CEWvyxQJ3w676AJILkT0BGVdVmQE5F4wPq9ZR+dA=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Jj2nOToYMfU9MGII6soWCNyoW3A>
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 14:59:50 -0000

Hi Lars,

I have come up with some initial draft changes - do these work for you?

Please see
https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-block&url2=https://raw
.githubusercontent.com/core-wg/new-block/emphasis/draft-ietf-core-new-block.
txt

Regards

Jon

> -----Original Message-----
> From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
> Sent: 12 May 2021 10:37
> To: 'Lars Eggert'; '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 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-interim-2020-core-04-sessa-new-coap-block-wise-
> transfer-options-draft-bosh-core-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-
> draft-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