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

Lars Eggert via Datatracker <noreply@ietf.org> Fri, 07 May 2021 12:50 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2653A1FF1; Fri, 7 May 2021 05:50:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: "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
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <162039183121.15574.16597240090409070575@ietfa.amsl.com>
Date: Fri, 07 May 2021 05:50:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/V6hZSkc9pQvowAObWSp_ywoYz5U>
Subject: [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
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, 07 May 2021 12:50:31 -0000

Lars Eggert 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:
----------------------------------------------------------------------

[Updating this DISCUSS based on the discussion during the May 6 telechat.]

Section 1, paragraph 4, discuss:
>    There is a requirement for these blocks of data to be transmitted at
>    higher rates under network conditions where there may be asymmetrical
>    transient packet loss (i.e., responses may get dropped).  An example
>    is when a network is subject to a Distributed Denial of Service
>    (DDoS) attack and there is a need for DDoS mitigation agents relying
>    upon CoAP to communicate with each other (e.g.,
>    [RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]

I understand that COAP was initially chosen to transport DOTS signaling messages
due to their small size, support for structured messages and request/response
semantics, as well as the ability to function over lossy paths such as found in
IoT deployment, which COAP is architected for.

DOTS now seems to desire to transport larger messages, and this document extends
CORE to enable this functionality. However, this CORE extension seems to solely
focus on Internet deployment scenarios, essentially attempting to re-architect
COAP into a general Internet transport protocol for transmission over paths with
high loss rates. It's questionable whether "maintenance of RFC7959" part of the
current CORE charter covers this document.

The motivation for this new extension is apparently that RFC7959 doesn't result
in sufficient performance for the DOTS use case, i.e., timely delivery of larger
amounts of data during periods of high random loss (i.e., under DDoS). This
is a fundamentally hard problem, because in order to deliver data in a timely
manner in such scenarios, the sender needs to be very aggressive, to send enough
packets into the network so that enough arrive at the receiver to make steady
progress; and at the same time the feedback channel is also severely degraded
due to loss.

The IETF TSV area currently has hence no known good solution for such use cases.
This specification possibly describes such a solution, but I was not able to find
any evaluation results that would show that this proposed mechanism actually
delivers the desired performance improvements over RFC7959 in the scenarios
of interest. I was also not able to find any evaluation results of whether the
proposed mechanism is safe to use in situations that might be easily confused
with DDoS, such as high-load scenarios that are not of malicious origin, or if it even
is safe when executing over normal Internet paths.

If such evaluation results exists, would you mind pointing me at them?

Without evaluation results that demonstrate that the proposed mechanism
is effective and safe, I do not believe it should be published on the Standards
Track. It could go forward as an Experimental RFC, supporting an experiment
to perform such an evaluation.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 3, nit:
> ell in environments where there are no or minimal packet losses. These optio
>                                     ^^
Did you mean "now" (=at this moment) instead of 'no' (negation)?

Section 3, paragraph 16, nit:
> ed by the peer whether the body comprises of a single or multiple payloads a
>                                 ^^^^^^^^^^^^
Did you mean "comprises" or "consists of"?

Section 4.1, paragraph 18, nit:
> T be included as Inner options. Similarly there MUST NOT be a mix of Q-Block
>                                 ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 4.3, paragraph 3, nit:
> -Tag value MUST be the same for all of the requests for the body of data tha
>                                 ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 3, nit:
> ue, the server still treats it as opaque but the client MUST ensure that it i
>                                   ^^^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.3, paragraph 6, nit:
>  not arrived after a timeout and a retransmit missing payloads response is n
>                                  ^^^^^^^^^^^^
After 'a', do not use a verb. Make sure that the spelling of 'retransmit' is
correct. If 'retransmit' is the first word in a compound adjective, use a
hyphen between the two words. Note: This error message can occur if you use a
verb as a noun, and the word is not a noun in standard English.

Section 4.3, paragraph 6, nit:
>  a timeout and a retransmit missing payloads response is needed. For reliabl
>                                     ^^^^^^^^
An apostrophe may be missing.

Section 4.3, paragraph 11, nit:
> g. The client should then release all of the tokens used for this body. Note
>                                   ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 13, nit:
> t. The client should then release all of the tokens used for this body. 2
>                                   ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 15, nit:
> quest. The client should then release all of the tokens used for this body.
>                                       ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 18, nit:
>  The client should then release all of the tokens used for this body unless
>                                 ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 20, nit:
> e Code can be used to indicate that all of the blocks up to and including th
>                                     ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 30, nit:
> ing-blocks+cbor-seq" indicates that some of the payloads are missing and need
>                                     ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 4.4, paragraph 4, nit:
> a request for that block and for all of the remaining blocks in the current
>                                  ^^^^^^^^^^^^^^^^
Consider using "all the".

Section 4.4, paragraph 7, nit:
> paque, the client still treats it as opaque but the server MUST ensure that i
>                                      ^^^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.4, paragraph 16, nit:
> , the client should then release all of the tokens used for this body unless
>                                  ^^^^^^^^^^
Consider using "all the".

Section 4.5, paragraph 1, nit:
> r a request that uses Q-Block1, the Observe value [RFC7641] MUST be the same
>                                 ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 4.5, paragraph 2, nit:
>  a response that uses Q-Block2, the Observe value MUST be the same for all t
>                                 ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 4.5, paragraph 3, nit:
> ferent from Block2 usage where the Observe value is only present in the firs
>                                ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 5, paragraph 2, nit:
> that the server has not received all of the blocks of the request body that
>                                  ^^^^^^^^^^
Consider using "all the".

Section 5, paragraph 4, nit:
> as a CBOR Sequence [RFC8742]. It comprises of one or more missing block numb
>                                  ^^^^^^^^^^^^
Did you mean "comprises" or "consists of"?

Section 5, paragraph 6, nit:
> sing blocks is as follows: ; A notional array, the elements of which
>                            ^
Loose punctuation mark.

Section 7.1, paragraph 2, nit:
>  It is implementation specific as to whether there should be any further req
>                                ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

Section 7.2, paragraph 9, nit:
> D consider the body stale, remove any body, and release Tokens and Request-T
>                                   ^^^^^^^^
Did you mean "anybody"?

Section 7.2, paragraph 10, nit:
> limit the potential wait needed calculated when using PROBING_WAIT. NON_PROB
>                                 ^^^^^^^^^^
"needed calculated" is only accepted in certain dialects. For something more
widely acceptable, consider "to be calculated".

Section 7.2, paragraph 14, nit:
> G_WAIT. Note: For the particular DOTS application, PROBING_RATE and other
>                                  ^^^^
An apostrophe may be missing.

Section 7.2, paragraph 15, nit:
> s. Even when not negotiated, the DOTS application uses customized defaults as
>                                  ^^^^
An apostrophe may be missing.

Section 7.2, paragraph 19, nit:
> rived for each body for at least a 24 hour period and it is known that there
>                                    ^^^^^^^
When a number forms part of an adjectival compound, use a hyphen: "24-hour"

Section 7.2, paragraph 19, nit:
> each body for at least a 24 hour period and it is known that there are no ot
>                                  ^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 7.2, paragraph 19, nit:
>  situation re-evaluated for another 24 hour period until there is no report
>                                     ^^^^^^^
It appears that a hyphen is missing.

Section 7.2, paragraph 19, nit:
> PAYLOADS values, a peer may continue indicate that there are some missing pa
>                             ^^^^^^^^^^^^^^^^^
Probably a preposition is missing after 'continue'.

Section 7.2, paragraph 22, nit:
> tinue) Response Code on receipt of all of the MAX_PAYLOADS payloads to preven
>                                    ^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 22, nit:
> t unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were receiv
>                                  ^^^^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 24, nit:
> xt set of payloads on receipt of all of the MAX_PAYLOADS payloads to prevent
>                                  ^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 24, nit:
> e server unnecessarily delaying. Otherwise the client SHOULD delay for NON_R
>                                  ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 10.1.3, paragraph 5, nit:
> - Tag by matching the token with the sent request. CoAP CoAP
>                                      ^^^^
Did you mean "scent"?

Section 10.2, paragraph 2, nit:
> n is not required for Q-Block2; the observe detail can thus be ignored. 10.2
>                                 ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'observe' is
correct. If 'observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.1, paragraph 2, nit:
> The same process is repeated when an Observe is triggered, but no loss is ex
>                                   ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.3, paragraph 1, nit:
> y Figure 10 shows the example of an Observe that is triggered but for which s
>                                  ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.4, paragraph 1, nit:
> t Figure 11 shows the example of an Observe that is triggered but only the fi
>                                  ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.3.3, paragraph 5, nit:
> t-Tag by matching the token with the sent request. CoAP CoAP C
>                                      ^^^^
Did you mean "scent"?

Section 12.3, paragraph 3, nit:
> blocks+cbor-seq o Encoding: - o Id: TBA3 o Reference: [RFCXXXX] Th
>                                 ^^
Possible spelling mistake found

Section 13.2, paragraph 4, nit:
> try] Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c.,
>                           ^
Add a space between sentences

Section 13.2, paragraph 9, nit:
> org/info/rfc8610>. [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P
>                                    ^
Add a space between sentences

"A.1.", paragraph 7, nit:
>  It is up to the implementation as to whether the application process stops t
>                                 ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

"A.2.", paragraph 4, nit:
>  It is up to the implementation as to whether the application process stops t
>                                 ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

"B.1.", paragraph 1, nit:
>  use of Q-Block1 Option with a reliable transport as shown in Figure 20. Ther
>                              ^^^^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

"B.1.", paragraph 2, nit:
> shown in Figure 20. There is no acknowledgment of packets at the CoAP layer,
>                                 ^^^^^^^^^^^^^^
Do not mix variants of the same word ('acknowledgment' and 'acknowledgement')
within a single text.

"B.2.", paragraph 1, nit:
>  of the use of Q-Block2 Option with a reliable transport is shown in Figure
>                                     ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

Document references draft-ietf-core-echo-request-tag-11, but
draft-ietf-core-echo-request-tag-12 is the latest available revision.