Skip to main content

Telechat Review of draft-ietf-lwig-tcp-constrained-node-networks-11

Request Review of draft-ietf-lwig-tcp-constrained-node-networks
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2020-10-20
Requested 2020-10-10
Requested by Martin Duke
Authors Carles Gomez , Jon Crowcroft , Michael Scharf
Draft last updated 2020-10-19
Completed reviews Genart Last Call review of -10 by Linda Dunbar (diff)
Intdir Telechat review of -11 by Bernie Volz (diff)
Iotdir Telechat review of -11 by Ines Robles (diff)
Tsvart Telechat review of -11 by Mirja Kühlewind (diff)
Assignment Reviewer Mirja Kühlewind
State Completed
Review review-ietf-lwig-tcp-constrained-node-networks-11-tsvart-telechat-kuehlewind-2020-10-19
Posted at
Reviewed revision 11 (document currently at 13)
Result Ready
Completed 2020-10-19
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 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

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