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

Benjamin Kaduk <kaduk@mit.edu> Fri, 21 May 2021 17:52 UTC

Return-Path: <kaduk@mit.edu>
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 044753A1960; Fri, 21 May 2021 10:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 jpLPFnTk90jO; Fri, 21 May 2021 10:52:54 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9DAFD3A1979; Fri, 21 May 2021 10:52:47 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14LHqbRt004666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 May 2021 13:52:43 -0400
Date: Fri, 21 May 2021 10:52:37 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: mohamed.boucadair@orange.com
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>
Message-ID: <20210521175237.GS32395@kduck.mit.edu>
References: <162026630680.17506.6477675472375470197@ietfa.amsl.com> <12589_1620322520_609428D8_12589_262_1_787AE7BB302AE849A7480A190F8B933035377DD2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210513215221.GH79563@kduck.mit.edu> <4685_1621248354_60A24962_4685_382_1_787AE7BB302AE849A7480A190F8B9330353899CD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4685_1621248354_60A24962_4685_382_1_787AE7BB302AE849A7480A190F8B9330353899CD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/AkQkKLwiN7wkidlkVAf_LFm42fU>
Subject: Re: [core] Benjamin Kaduk'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: Fri, 21 May 2021 17:52:59 -0000

Hi Med, Jon,

Thanks for the diff and commentary.
My concerns have been addressed (so no further remarks inline).

I guess I'm the last discuss-holder for this one, so presumably it's time
to upload a new I-D and then Francesca and I get to push buttons in the
datatracker...

Thanks again,

Ben

On Mon, May 17, 2021 at 10:45:53AM +0000, mohamed.boucadair@orange.com wrote:
> Hi Ben, 
> 
> Please see inline. The latest changes can be tracked at: https://tinyurl.com/new-block-latest. 
> 
> Cheers,
> Jon & Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk [mailto:kaduk@mit.edu]
> > Envoyé : jeudi 13 mai 2021 23:52
> > À : 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: Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11:
> > (with DISCUSS and COMMENT)
> > 
> > Hi Med,
> > 
> > On Thu, May 06, 2021 at 05:35:19PM +0000,
> > mohamed.boucadair@orange.com wrote:
> > > Hi Ben,
> > >
> > > Thank you for the review. All the changes can be tracked at:
> > https://tinyurl.com/new-block-latest.
> > 
> > (Apparently I waited long enough to be able to just use rfcdiff on
> > the published -12; PR #26 posted with a couple nits from that diff.)
> > 
> 
> Merged the PR. Thank you.
> 
> > > Please see inline.
> > >
> > > Cheers,
> > > Jon & Med
> > >
> > > > -----Message d'origine-----
> > > > De : Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org]
> > Envoyé
> > > > : jeudi 6 mai 2021 03:58 À : The IESG <iesg@ietf.org> Cc :
> > > > draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org;
> > > > core@ietf.org; marco.tiloca@ri.se; marco.tiloca@ri.se Objet :
> > > > Benjamin Kaduk's Discuss on draft-ietf-core-new-block-11:
> > > > (with DISCUSS and COMMENT)
> > > >
> > > > Benjamin Kaduk has entered the following ballot position for
> > > > draft-ietf-core-new-block-11: Discuss
> > > >
> > > > When responding, please keep the subject line intact and reply to
> > > > all email addresses included in the To and CC lines. (Feel free
> > to
> > > > cut this introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to https://www.ietf.org/iesg/statement/discuss-
> > > > criteria.html
> > > > for more information about DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found
> > here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-core-new-block/
> > > >
> > > >
> > > >
> > > > -----------------------------------------------------------------
> > ---
> > > > -
> > > > -
> > > > DISCUSS:
> > > > -----------------------------------------------------------------
> > ---
> > > > -
> > > > -
> > > >
> > > > I have a concern about the MAX_PAYLOADS congestion-control
> > parameter.
> > > > In Section 7.2 it is stated that both endpoints only SHOULD have
> > the
> > > > same value.  I don't see how this can be anything less than MUST,
> > > > given that we attribute semantics to whether NUM modulo
> > MAX_PAYLOADS
> > > > is zero or non-zero in the processing of the Q-Block2 option.  If
> > > > the endpoints disagree on the value of MAX_PAYLOADS they will
> > > > disagree on the semantics of Q-Block2 -- how can that be
> > interoperable?
> > > > (Being able to negotiate the value does not seem inherently
> > > > problematic, but since it is relevant for protocol semantics it
> > > > seems like the value must be identical on both endpoints.) This
> > > > seems especially important to have clarity on given that the
> > current
> > > > specification allows for MAX_PAYLOADS to be decreased at runtime
> > in
> > > > response to congestion feedback over a 24-hour period, with no
> > > > synchronization between peers provided ("Note that the CoAP peer
> > > > will not know about the MAX_PAYLOADS change until it is
> > > > reconfigured".)
> > > >
> > > >
> > >
> > > Implementation testing with MAX_PAYLOAD being different in the
> > peers showed things worked badly (unnecessary timeouts/recovery) but
> > continued to work.
> > >
> > > If the peers were negotiating and installing a new common value
> > (application layer), there was a brief period of instability.
> > 
> > I still think there's a fundamental mismatch between "this is a
> > parameter that is part of the protocol and part of request/response
> > semantics" and "this is a parameter that each endpoint is allowed to
> > vary unilaterally".
> > This holds even if we attempt to set things up so in the former case
> > the behavior degrades somewhat gracefully, with one direction
> > transmitting as expected and the other only making slow progress.
> > 
> > If this was just a local parameter for how to batch and pace
> > transmissions, that would be fine, and letting it vary (even if not
> > recommended) between peers would also be fine.
> > 
> > But the -12 currently has text like (§4.4):
> > 
> >    In a request for any block number, the M bit unset indicates the
> >    request is just for that block.  If the M bit is set, this has
> >    different meanings based on the NUM value:
> > 
> >    NUM is zero:  This is a request for the entire body.
> > 
> >    'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero:  This is
> >       used to confirm that the current MAX_PAYLOADS_SET (the latest
> >       block having block number NUM-1) has been successfully received
> >       and that, upon receipt of this request, the server can continue
> > to
> >       send the next MAX_PAYLOADS_SET (the first block having block
> >       number NUM).  This is the 'Continue' Q-Block-2 and conceptually
> >       has the same usage (i.e., continue sending the next set of
> > data)
> >       as the use of 2.31 (Continue) for Q-Block1.
> > 
> >    Any other value of NUM:  This is a request for that block and for
> > all
> >       of the remaining blocks in the current MAX_PAYLOADS_SET.
> > 
> > That is, the semantics of a request are supposed to depend on the
> > value of MAX_PAYLOADS.  The semantics of what the sender sent can
> > disagree with the semantics of what the receiver interprets, if there
> > is skew in this value.
> > 
> > Now, maybe it happens that things work out okay if the client and
> > server have different MAX_PAYLOADS values, in that setting the M bit
> > does not have to be tied to a specific MAX_PAYLOADS_SET and rather
> > means "give me a chunk of up to your max-transmit-window of
> > payloads", and the receiver's value determines whether the "up to"
> > means a full window's worth or not, but that's not what we say it
> > means.  For Proposed Standards, I think we need to be accurate about
> > what the semantics actually are, not just what they are in the ideal
> > case, if the MAX_PAYLOADS value is allowed to vary between peers.
> > And if skew is allowed, we need to say that behavior degrades in case
> > of skew and how, but that progress will still be made.
> > 
> > (Even if the semantics actually are "give me a chunk of up to your
> > max-window", things can still end up behaving badly if the skew is
> > quite significant -- if I think I'm asking for a window of up to 10
> > blocks but I get back 100, I may not be able to handle the full
> > response.)
> > 
> > 
> > > Please note that this is a value that is unlikely to change: 1500
> > byte packets and MAX_PAYLOADS(10) gives a set of 15,000 bytes. With
> > an up to NON_TIMEOUT (2 secs) delay, average data rates are of the
> > order of 60kbps (1500 * 8 * 10 / 2), so providing the congested
> > network can handle 60Kbps, all will be OK. If higher values, then the
> > 'Continue' will come back quicker than the NON_TIMEOUT.
> > 
> > If it's unlikely to change, then what's wrong with making it a fixed
> > parameter (subject to change by out-of-band agreement)?
> 
> These are fair observations. We made the following changes: 
> 
> (1)
> 
> OLD:
>    MAX_PAYLOADS should be configurable with a default value of 10.  Both
>    CoAP endpoints SHOULD have the same value (otherwise there will be
>    transmission delays in one direction) and the value MAY be negotiated
>    between the endpoints to a common value by using a higher level
>    protocol (out of scope of this document).
> 
> NEW:
>    MAX_PAYLOADS should be configurable with a default value of 10.  Both
>    CoAP endpoints MUST have the same value (otherwise there will be
>    transmission delays in one direction) and the value MAY be negotiated
>    between the endpoints to a common value by using a higher level
>    protocol (out of scope of this document).
> 
> (2) replaced this text with a note:
> 
> OLD: 
>    If the CoAP peer reports that at least one payload has not arrived
>    for each body for at least a 24-hour period and it is known that
>    there are no other network issues over that period (e.g., DDoS
>    attacks), then the value of MAX_PAYLOADS can be reduced by 1 at a
>    time (to a minimum of 1) and the situation re-evaluated for another
>    24-hour period until there is no report of missing payloads under
>    normal operating conditions.  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.  The newly derived value for MAX_PAYLOADS
>    should be used for both ends of this particular CoAP peer link.  Note
>    that the CoAP peer will not know about the MAX_PAYLOADS change until
>    it is reconfigured.  As a consequence of the two peers having
>    different MAX_PAYLOADS values, a peer may continue indicating that
>    there are some missing payloads as all of its MAX_PAYLOADS_SET may
>    not have arrived.  How the two peer values for MAX_PAYLOADS are
>    synchronized is out of the scope.
> 
> NEW:
>       Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having
>       10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits.  With
>       a maximum delay of 2 seconds between MAX_PAYLOADS_SET, this
>       indicates an average speed requirement of 60 Kbps for a single
>       body should there be no responses.  This transmission rate is
>       further reduced by being subject to PROBING_RATE.
> 
> > >
> > > >
> > > >       If the FETCH request includes the Observe Option, then the
> > > > server
> > > >       MUST use the same token as used for the initial response
> > for
> > > >       returning any Observe triggered responses so that the
> > client
> > > > can
> > > >       match them up.
> > > >
> > > >       The client should then release all of the tokens used for
> > this
> > > >       body unless a resource is being observed.
> > > >
> > > > If a resource is being observed, should the client release all
> > the
> > > > other tokens (than the one used for the initial response)?
> > >
> > > There is no reason why the client cannot release all the other
> > tokens.
> > >
> > > >
> > > > Also, is the "initial response" the first response for the
> > blockwise
> > > > transfer (which might be a 2.31 or 4.08 for NON requests), or the
> > > > first one with response code 2.05?
> > >
> > > The "initial all data received response" - i.e. 2.01 or 2.05.
> > 
> > I'd suggest adding that clarification.
> 
> Sure. We made the following change:  
> 
> OLD: 
>       If the FETCH request includes the Observe Option, then the server
>       MUST use the same token as used for the initial response for
>       returning any Observe triggered responses so that the client can
>       match them up.
> 
> NEW:
>       If the FETCH request includes the Observe Option, then the server
>       MUST use the same token as used for the 2.05 (Content) response
>       for returning any Observe triggered responses so that the client
>       can match them up.
> 
> > 
> > > >
> > > >    2.31 (Continue)
> > > >
> > > >       This Response Code can be used to indicate that all of the
> > > > blocks
> > > >       up to and including the Q-Block1 Option block NUM (all
> > having
> > > > the
> > > >       M bit set) have been successfully received.  The token used
> > > > MUST
> > > >       be one of the tokens that were received in a request for
> > this
> > > >       block-wise exchange.  However, it is desirable to provide
> > the
> > > > one
> > > >       used in the last received request.
> > > >
> > > > Can the client release any tokens upon receipt of such a
> > response?
> > >
> > > Yes.  If going with the Implementation Note #6., the lower 32 bits
> > tracker must not be released.
> > 
> > Since we mention releasing tokens for other response codes, it would
> > feel natural to mention it here as well, to me.
> 
> Added this NEW text: 
> 
>       The client should then release all of the tokens used for this
>       MAX_PAYLOADS_SET.
> 
> > 
> > > >
> > > >    4.02 (Bad Option)
> > > >
> > > >       This Response Code MUST be returned for a Confirmable
> > request
> > > > if
> > > >       the server does not support the Q-Block Options.  Note that
> > a
> > > >       reset message must be sent in case of Non-confirmable
> > request.
> > > >
> > > > Reset only needs to be sent if the server is not ignoring the
> > > > request entirely, though, right?
> > >
> > > The request will be rejected. Please see:
> > >
> > >    A Non-confirmable
> > >    message with an unrecognized critical option is either rejected
> > with
> > >    a Reset message or just silently ignored (Sections 5.4.1 and 4.3
> > of
> > >    [RFC7252]).
> > 
> > I don't think I understand.  "either rejected ... or just silently
> > ignored"
> > says that "just silently ignore" is a valid way to handle such a
> > message.
> > So, if "silently ignore" is a valid option for the server, I don't
> > see how we can say "must be sent" without deviating from RFC 7252.
> > 
> 
> Fair point: s/must be sent/may be sent. We don't want to deviate from 7252.
> 
> 
> > > >    For Confirmable responses, the client continues to acknowledge
> > > > each
> > > >    packet.  Typically, the server acknowledges the initial
> > request
> > > > using
> > > >    an ACK with the payload, and then sends the subsequent
> > payloads as
> > > >    CON responses.  The server will detect failure to send a
> > packet,
> > > > but
> > > >    the client can issue, after a MAX_TRANSMIT_SPAN delay, a
> > separate
> > > >    GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks
> > as
> > > >    needed.
> > > >
> > > > Starting out with "for confirmable responses" implies that we're
> > > > going to separately cover non-confirmable responses later, or at
> > > > some point transition to statements of general applicability (to
> > > > both confirmable and non-confirmable responses).  Where does that
> > happen?
> > >
> > > It is in this section. The text you quoted is what is specific to
> > CON responses.
> > 
> > I would have preferred a more explicit signal that the subsequent
> > paragraphs apply to both the confirmable and non-confirmable cases,
> > but the only option I'm coming up with at the moment ("for both
> > confirmable and non-confirmable responses" to start the subsequent
> > paragraph") is not great.
> > 
> 
> We reordered the text so that the text about confirmable is positioned at the end of the section. 
> 
> > > > Section 5
> > > >
> > > >    The data payload of the 4.08 (Request Entity Incomplete)
> > response
> > > > is
> > > >    encoded as a CBOR Sequence [RFC8742].  It comprises of one or
> > > > more
> > > >
> > > > I think we want some qualifying text that reaffirms that the
> > > > behavior being described is applicable only to the
> > > > application/missing-
> > > > blocks+cbor-seq content-type case, possibly by having the
> > previous
> > > > discussion state that "this section defines the behavior and
> > > > semantics for 4.08 responses using the new content-type."
> > >
> > > Why is this needed?
> > 
> > The data payload of the 4.08 response as specified in RFC 7959 is not
> > a CBOR sequence.  The current wording and paragraph structure doesn't
> > provide a clear connection between the new content-type (as mentioned
> > in the first sentence of the section) and this text, so a reader
> > might misread this text (which has no normative keywords) as
> > describing the preexisting situation for 4.08 responses, and that is
> > not correct.  Even just adding the word "new" ("data payload of the
> > new 4.08 (Request Entity Incomplete) response") would help clarify
> > that the description is of the new behavior, not the preexisting
> > behavior.
> 
> We understand your point better. Thanks. We made this change:
> 
> OLD: 
>    The data payload of the 4.08 (Request Entity Incomplete) response is
>    encoded as a CBOR Sequence [RFC8742].
> 
> NEW:
>    The new data payload of the 4.08 (Request Entity Incomplete) response
>    with Content-Type set to "application/missing-blocks+cbor-seq" is
>    encoded as a CBOR Sequence [RFC8742].
> 
> > 
> > > >
> > > >    The Concise Data Definition Language [RFC8610] (and see
> > Section
> > > > 4.1
> > > >    [RFC8742]) for the data describing these missing blocks is as
> > > >    follows:
> > > >
> > > > (Should we mention that this is only informational and that the
> > > > prose description is normative, in line with RFC 8610 being only
> > an
> > > > informative reference?)
> > >
> > > I'm not sure this is needed. What is authoritative is the CBOR
> > sequence.
> > 
> > In my experience, it's quite common for documents to specifically say
> > whether the protocol-description-language version or the prose
> > version is authoritative in case of conflict.  Hopefully there is no
> > conflict, but to have a clear and unambiguous specification, we have
> > to say which version to use if there is a conflict.
> > 
> 
> Let's then make things clear:
> 
> NEW:
>    This CDDL syntax MUST be followed.
> 
> > > > Section 6
> > > >
> > > >    Implementation Note:  By using 8-byte tokens, it is possible
> > to
> > > >       easily minimize the number of tokens that have to be
> > tracked by
> > > >       clients, by keeping the bottom 32 bits the same for the
> > same
> > > > body
> > > >       and the upper 32 bits containing the current body's request
> > > > number
> > > >       (incrementing every request, including every re-transmit).
> > > > This
> > > >       allows the client to be alleviated from keeping all the
> > per-
> > > >       request-state, e.g., in Section 3 of [RFC8974].
> > > >
> > > > If we're going to introduce structure into a nominally opaque
> > > > identifier, we need to discuss the consequences of that in the
> > > > security considerations.  draft-gont-numeric-ids-sec-
> > considerations
> > > > has some guidance in this regard.
> > >
> > > It is all opaque to the server, the client is just using it to make
> > sure his requests are unique. If one can access the token, it can
> > access more critical information. I'm not sure there is much to say
> > as the messages are not supposed to be sent on clear. Tampering of
> > the token is thus very difficult given we are not using NoSec.
> > 
> > It's only NOT RECOMMENDED to use NoSec, which means we still have to
> > accurately document the security considerations if NoSec is used.
> > 
> 
> Added this NEW text: 
> 
>   "However, if using NoSec, Section 5.2 of [RFC8974] needs to be considered for	
>   security implications."
> 
> Section 11 is also updated with this NEW text: 
> 
>    If OSCORE is not used, it is also NOT RECOMMENDED to use the NoSec
>    security mode if either the Q-Block1 or Q-Block2 Options is used.
> 
>    If NoSec is being used, Section D.5 of [RFC8613] discusses the
>    security analysis and considerations for unprotected message fields
>    even if OSCORE is not being used.
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>