Subject: [Lwip] Tsvart telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 19 Oct 2020 05:43:17 -0700

Reviewer: Mirja Kühlewind
Review result: Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

Thanks for the well-written document! This is good to go, I only have some
optional suggestions below:

In section 4.1.2. you could potentially also mention
draft-ietf-tcpm-generalized-ecn as connections with small windows might
especially benefit when the ACK is also ECN-capable.

In section 4.2.1: "In that case, both congestion and flow control
implementation are quite simple." I guess this is even an understatement.
Basically this would be a static configuration and there is nothing left to
"control".

In section 4.2.3: "Disabling Delayed ACKs at the sender allows an immediate ACK
for the data segment carrying the response." I guess you can in addition,
however, explain that keeping the delayed ACK could help to piggy-back the ACK
with maybe some additional data to send instead of sending the ACK in a
separate TCP packet (of course depending on the traffic pattern of the
application). I think this is roughly mentioned later again but seems to belong
her as well.

Section 4.3.1.1: is this sentence correct? It least it did confuse me a bit
when reading first: “A receiver supporting SACK will need to keep track of the
SACK blocks that need to be received.” Maybe “A receiver supporting SACK will
need to keep track of the data blocks that need to be received.” ?

Section 4.3.2: Maybe s/it may make sense to use a small timeout/it may make
sense to use a smaller timeout/ or s/it may make sense to use a small
timeout/it may make sense to use a very small timeout/ ?

Section 4.3.3: “with an IW setting of 10 MSS, there is significant buffer
overflow risk” I think it would be good to explain slightly better which buffer
you mean. Is there an assumption that network buffer sizes are known in CNNs as
managed by the same entity than the constraint devices? Maybe the
recommendation should be to make this parameter configurable? I guess most
stacks provide an option for this but not sure if all do…

Section 6: maybe provide a reference to RFC8446 TLS1.3..?

Also section 6: You mention TCP-OA but you don’t give a really recommendation
if or when it should be used or not.

I assume section 8 is intended to be kept for publication. I support that as
it’s interesting information.

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 30 Oct 2020 08:26:22 +0100

Hi Mirja,

Thank you very much for your review!

We just submitted revision -12, which aims at addressing the comments
received from the IESG and related reviewers, including yours:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12

Please find below our inline responses:

> Reviewer: Mirja KÃ¼hlewind
> Review result: Ready
>

Thanks for your kind words and for your constructive review.

> especially benefit when the ACK is also ECN-capable.

Agreed. We added the following before the last sentence of former 4.1.2
(now 3.1.2):

NEW:
   As of the writing, there is on-going work to extend the types of TCP
   packets that are ECN-capable, including pure ACKs [draft-ietf-tcpm-
   generalized-ecn]. Such a feature may further increase the benefits of
   ECN in CNN environments.

> Basically this would be a static configuration and there is nothing left

We see your point, but we understand that at least some sort of flow
control is still possible for a very simple TCP/IP stack. For instance, a
TCP receiver can still send segments with zero receive window (RWND=0).
Regarding congestion control, the RTO backoff applies, which is some basic
form of congestion control. The wording "quite simple" in the document
aims to capture that. However, please let us know if you have a different
opinion.

> application). I think this is roughly mentioned later again but seems to

If we understand it correctly, your suggested addition is already present
in the sentence right before the one that you focused on in this comment.
If we misunderstood your comment, please let us know.

> when reading first: â€œA receiver supporting SACK will need to keep track
> of the
> SACK blocks that need to be received.â€ Maybe â€œA receiver supporting
> SACK will
> need to keep track of the data blocks that need to be received.â€ ?

Agreed.

> timeout/it may make sense to use a very small timeout/ ?

Agreed (we used the first proposal).

> Section 4.3.3: â€œwith an IW setting of 10 MSS, there is significant
> buffer
> overflow riskâ€ I think it would be good to explain slightly better which
> buffer
> stacks provide an option for this but not sure if all doâ€¦

In the highlighted text, “buffer” may actually refer to a buffer at any
layer (e.g. a “radio buffer”, or an upper layer buffer), depending on the
specific context. For example, some constrained device hardware platforms
support a send buffer of at most one MSS of data.  We hope that the
following update can help clarify the intent:

OLD:
    with an IW setting of 10 MSS, there is significant buffer overflow risk,

NEW:
    with an IW setting of 10 MSS, there is significant buffer overflow risk,
    since many CNN devices support network or radio buffers of a size
    smaller than 10 MSS.

> Section 6: maybe provide a reference to RFC8446 TLS1.3..?

Agreed.

> Also section 6: You mention TCP-OA but you donâ€™t give a really
> recommendation

We now aim at highlighting the benefits of TCP-AO, along with the
trade-off that needs to be assessed by the implementer. We updated the
first two paragraphs in Section 5 (formerly, Section 6), as follows:

NEW:
   Best current practice for securing TCP and TCP-based communication
   also applies to CNN.  As example, use of Transport Layer Security
   (TLS) [RFC 8446] is strongly recommended if it is applicable. However,
   note that TLS protects only the contents of the data segments.

   There are TCP options which can actually protect the transport layer.
   One example is the TCP Authentication Option (TCP-AO) [RFC5925]. However,
   this option adds overhead and complexity.  TCP-AO typically has a size of
   16-20 bytes. An implementer needs to asses the trade-off between security
   and performance when using TCP-AO, considering the characteristics (in
   terms of energy, bandwidth and computational power) of the environment
   where TCP will be used.

> itâ€™s interesting information.

Thanks for your support!

Yes, we (the authors) would like to keep that former section 8 (now,
section 7) for publication.

Greetings,

Carles (on behalf of the authors)

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 30 Oct 2020 11:23:01 +0100

Hi Carles,

Thanks for you edits. Looks all good to me!

Mirja

> On 30. Oct 2020, at 08:26, Carles Gomez Montenegro <[email-masked]> wrote:
> 
> Hi Mirja,
> 
>> when reading first: âA receiver supporting SACK will need to keep track
>> of the
>> SACK blocks that need to be received.â Maybe âA receiver supporting
>> SACK will
>> need to keep track of the data blocks that need to be received.â ?
> 
> Agreed.
> 
>> Section 4.3.3: âwith an IW setting of 10 MSS, there is significant
>> buffer
>> overflow riskâ I think it would be good to explain slightly better which
>> buffer
>> stacks provide an option for this but not sure if all doâ¦
> 
> In the highlighted text, buffer may actually refer to a buffer at any
> layer (e.g. a radio buffer, or an upper layer buffer), depending on the
>> Also section 6: You mention TCP-OA but you donât give a really
>> recommendation
>> itâs interesting information.
> 
> Thanks for your support!
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
>