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. >
- [core] Benjamin Kaduk's Discuss on draft-ietf-cor… Benjamin Kaduk via Datatracker
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… mohamed.boucadair
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… mohamed.boucadair
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… mohamed.boucadair
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… mohamed.boucadair