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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Fri, 07 May 2021 05:50:31 -0700

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.

---

From: <[email-masked]>
Date: Fri, 7 May 2021 13:56:00 +0000

Hi Lars, 

Please see inline. 

Cheers,
Jon & Med

> -----Message d'origine-----
> De : Lars Eggert via Datatracker [mailto:[email-masked]]
> Envoyé : vendredi 7 mai 2021 14:51
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with
> DISCUSS and COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> 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,

Actually, the motivation is the lack of support of block-wise for NON messages. This is explicitly indicated in the introduction:

   As a reminder, [RFC7959]
   recommends the use of Confirmable (CON) responses to handle potential
   packet loss.  However, such a recommendation does not work with a
   flooded pipe DDoS situation.

FWIW, here is the full background:

(1)

RFC7252 supports two communication types of request in the request/response model as in rfc7252#section-1.2: Confirmable Message and Non-confirmable Message.

(2)

CoAP imposes a limitation on the data transmission size as in rfc7252#section-4.6

   A CoAP message, appropriately encapsulated, SHOULD fit within a
   single IP packet (i.e., avoid IP fragmentation) and (by fitting into
   one UDP payload) obviously needs to fit within a single IP datagram.

(3)

So then RFC7959 came about to handle single packet limitations by adding in 'block' support. However, it is designed to work with Confirmable, recognizing the limitations of Non-confirmable as in rfc7959#section-1

    The present
   specification minimizes the constraints it adds to those base
   exchanges; however, not all variants of using CoAP are very useful
   inside a block-wise transfer (e.g., using Non-confirmable requests
   within block-wise transfers outside the use case of Section 2.8 would
   escalate the overall non-delivery probability).

(4)

draft-ietf-core-new-block provides a missing piece of RFC7959, namely the support of block-wise transfer using Non-confirmable where an entire body of data can be transmitted without the requirement for an acknowledgement.

(5)

Like 7959, draft-ietf-core-new-block does not remove any of the constraints posed by the base CoAP specification.

It just 'happens' that there are additional transmission rate benefits (subject to congestion control) when using draft-ietf-core-new-block.

We updated the introduction to clarify this background. Please check: https://tinyurl.com/new-block-latest 

Does this clarify your concern?

 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.
> 
> 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.
> 

There is not evaluation paper, but as stated in the thread with Eric V., extensive tests were made that confirmed the benefits. The code giving Q-Block support is out there in the public domain. A pointer is included in the write-up. 

> 
> 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.
> 
> 

_________________________________________________________________________________________________________________________

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.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 7 May 2021 17:03:16 +0300

Hi,

> There is not evaluation paper, but as stated in the thread with Eric V., extensive tests were made that confirmed the benefits. The code giving Q-Block support is out there in the public domain. A…

is there any public information about the methodology and results for these extensive tests? I understand there is no paper, but is there a presentation or anything else?

Thanks,
Lars

---

From: <[email-masked]>
Date: Tue, 11 May 2021 12:05:54 +0000

Hi Lars, 

We prepared some material for your to describe the methodology and to list various interops and other useful pointers:
https://github.com/core-wg/new-block/blob/master/testing%20methodology.md 

Please let us know if any further information is needed. 

Cheers,
Jon & Med

> De : Lars Eggert [mailto:[email-masked]]
> Envoyé : vendredi 7 mai 2021 16:03
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11:
> (with DISCUSS and COMMENT)
> 
> Hi,
> 
> > There is not evaluation paper, but as stated in the thread with
> Eric V., extensive tests were made that confirmed the benefits. The
> code giving Q-Block support is out there in the public domain. A
> pointer is included in the write-up.
> 
> is there any public information about the methodology and results for
> these extensive tests? I understand there is no paper, but is there a
> presentation or anything else?
> 
> Thanks,
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 11 May 2021 16:11:22 +0300

Hi,

> https://github.com/core-wg/new-block/blob/master/testing%20methodology.md

thanks for the pointer, Med. This is a clear description of the tests that were done, most (all?) of which seem to be focused on regression and interop testing.

What I was hoping to see, however, were some results that quantified the performance and safety aspects of this proposal. I tried to explain what I was looking for in my DISCUSS. draft-ietf-core-new-block basically proposes a send rate control mechanism, to be used in DDoS scenarios, i.e., a component of a transport protocol. The IETF has a pretty well-developed approach for analyzing such mechanisms. As part of that analysis, one would investigate a number of things:

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.

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.) 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

---

From: <[email-masked]>
Date: Tue, 11 May 2021 13:28:46 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 11 mai 2021 15:11
> > We prepared some material for your to describe the methodology and
> to list various interops and other useful pointers:
> > https://github.com/core-wg/new-
> block/blob/master/testing%20methodology.md
> 
> thanks for the pointer, Med. This is a clear description of the tests
> that were done, most (all?) of which seem to be focused on regression
> and interop testing.
> 
> What I was hoping to see, however, were some results that quantified
> the performance and safety aspects of this proposal. I tried to
> explain what I was looking for in my DISCUSS. draft-ietf-core-new-
> block basically proposes a send rate control mechanism, to be used in
> DDoS scenarios, i.e., a component of a transport protocol. The IETF
> has a pretty well-developed approach for analyzing such mechanisms.
> As part of that analysis, one would investigate a number of things:
> 
> 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.

> 
> 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 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.
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 11 May 2021 20:26:38 +0300

Hi,

> 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?

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?

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.

> 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?

(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.)

---

From: <[email-masked]>
Date: Wed, 12 May 2021 10:36:43 +0100

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: [email-masked]]
> Sent: 11 May 2021 18:27
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; The IESG;
> [email-masked]; [email-masked]
> Subject: Re: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with
> DISCUSS and COMMENT)
> 
> Hi,
> 
> > 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.

> > 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.

---

From: <[email-masked]>
Date: Wed, 12 May 2021 15:59:43 +0100

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

> From: Jon Shallow [mailto:[email-masked]]
> Sent: 12 May 2021 10:37
> To: 'Lars Eggert'; [email-masked]'
> Cc: [email-masked]'; [email-masked]'; 'The
IESG';
> [email-masked]'; [email-masked]'
> Subject: RE: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with
> DISCUSS and COMMENT)
> 
> Hi Lars,
> 
> 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.
> 
> 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.
> 
> 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
> 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).
> 
> >
draft-ietf-core-
> new-
way
don't
> > This says "only use this for DOTS". But it doesn't discuss whether
draft-
> ietf-
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.
> 
> >
draft-ietf-core-
> > new-block may form the basis for a revision of RFC7959, so it's a bit
odd to
> 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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 May 2021 10:49:06 +0300

Hi,

> .githubusercontent.com/core-wg/new-block/emphasis/draft-ietf-core-new-block.

thanks - these do work for me. I will clear my DISCUSS.

Lars

---

From: <[email-masked]>
Date: Tue, 18 May 2021 08:06:57 +0000

Hi Lars, 

Thank you for checking. I merged the PR.

Will wait for Ben before releasing the updated version that includes these changes. 

Cheers,
Med

> Envoyé : mardi 18 mai 2021 09:49
> À : [email-masked]
> Cc : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; draft-
> [email-masked]; [email-masked]; The IESG
> <[email-masked]>; [email-masked]; [email-masked]
> > https://www.ietf.org/rfcdiff?url1=draft-ietf-core-new-
> block&url2=https
> > ://raw