TCP Usage Guidance in the Internet of Things (IoT)
draft-ietf-lwig-tcp-constrained-node-networks-13

Piling on: You don't appear to need Section 2.

Is Section 8 meant to be removed before publication, a la RFC 7942?

Thanks for this practical guidance to implementers.  A few minor nits:
S
ection 4.1.2. Typo. s/bandwitdh/bandwidth/

Section 4.2.1. Editorial.  s/implementation are/implementations are/

Section 6. Typo. s/ targetted/targeted/

Section 8.7.  Typo. s/ differrent/different/

Updated position as the previous DISCUSS point below (kept for archives) and COMMENTs have been addressed

-éric


Thank you for the work put into this document. It is an important topic and the document is both easy to ready and detailed.

Please find below one trivial DISCUSS point and a couple of non-blocking COMMENT points but please also check:
- Ines Robles IoT directorate review:
	https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-iotdir-telechat-robles-2020-10-20/
- Bernie Volz Internet directorate review: 
	https://datatracker.ietf.org/doc/review-ietf-lwig-tcp-constrained-node-networks-11-intdir-telechat-volz-2020-10-20/

I hope that this helps to improve the document,

Regards,

== COMMENTS ==

Should a reference to RFC 8900 be added in the MTU discussion in section 4.1 ?

-- Section 2 --
As noted by many, the BCP 14 boiler plate is the old one and the normative terminology is not used in this informational document. => remove it ?

Thanks for a useful document.  I just have a few editorial things here:

— Section 1 —

   However, TCP has been
   criticized (often, unfairly) as a protocol for the IoT.  In fact,
   some TCP features are not optimal for IoT scenarios, such as
   relatively long header size, unsuitability for multicast, and always-
   confirmed data delivery.  However, …

Both of these sentences have nit-level problems that make them a bit off.  The first sounds like the criticism is that TCP is a protocol for IoT (rather than that it’s not suitable for that usage).  The second has the examples misplaced, so it look as though they’re examples of IoT scenarios (rather than examples of TCP features).  And “in fact” has the wrong feel here: it would normally be used to contradict the previous sentence, not to explain it.  (And two “however”s in close proximity also feels awkward)  I suggest this fix:

NEW
   TCP has been
   criticized, often unfairly, as a protocol that’s unsuitable for the
   IoT.  It is true that some TCP features, such as its relatively long
   header size, unsuitability for multicast, and always-confirmed data
   delivery, are not optimal for IoT scenarios.  However, …
END

   TCP is also used by non-IETF application-
   layer protocols in the IoT space such as the Message Queue Telemetry
   Transport (MQTT) and its lightweight variants.

It’s “Message Queuing Telemetry Transport”, and an informative reference to ISO/IEC 20922 <https://www.iso.org/standard/69466.html> wouldn’t be a bad thing.

[edited to properly attribute the Discuss holder]
Mostly just editorial nits, but please see the comment on Section 5.3.

Section 2

(I believe the existence of the RFC 8174 version of the BCP 14
boilerplate has already been noted.)

Section 3.2

   or devices with a pool of multiple send/receive buffers.  In the
   latter case, it is possible that buffers also be shared for other
   protocols.

nit: s/be/are/ (or any number of other minor tweaks)

   One key use case for the use of TCP in CNNs is a model where

nit: "use case for the use" is probably redundant: "use case for TCP in
CNNs" seems like it would work okay.

   middlebox (e.g. a firewall, NAT, etc.).  Figure 1 illustrates such
   scenario.  Note that the scenario is asymmetric, as the unconstrained

nit: "such a scenario".

Section 3.3

   o  Unidirectional transfers: An IoT device (e.g. a sensor) can send
      (repeatedly) updates to the other endpoint.  Not in every case
      there is a need for an application response back to the IoT
      device.

(editorial) I suggest "There is not always a need for an application
response back to the IoT device".

Section 4.1.1

   smaller than 1220 bytes (e.g. not larger than 1200 bytes).  Note that
   it is advised for TCP implementations to consume payload space
   instead of increasing datagram size when including IP or TCP options
   in an IP packet to be sent [RFC6691].  Therefore, the suggestion of

[my reading of RFC 6691 is that it was required to consume payload
space, but only recommended to account for this behavior when
advertising MSS.  I guess Martin covered this in his Discuss point already, though.]

Section 5.3

   The message and latency overhead that stems from using a sequence of
   short-lived connections could be reduced by TCP Fast Open (TFO)
   [RFC7413], which is an experimental TCP extension, at the expense of
   increased implementation complexity and increased TCP Control Block
   (TCB) size.  TFO allows data to be carried in SYN (and SYN-ACK)

We should probably make at least a passing mention of the TFO security
considerations here, possibly with some discussion of why they are less
consequential for certain CNNs than in general.  (Note that the security
considerations for TFO are not limited to just the risk of replay, and
that there are privacy considerations for the TFO cookie being used to
link together multiple TCP connections between the same endpoints.)

Section 10.1

RFC 3819 may not need to be listed as normative, given the nature of the
one place in which it is referenced.

Similarly, we don't say much about TCP-AP other than it exists, so RFC
5925 may not need to be normative either.

Section 10.2

RFC 6092 appears to not be referenced from anywhere?
idnits notes a couple other reference-related issues.

Thanks for addressing my DISCUSS.

Original comments, since resolved:

Please address the tsv review comments.

Sec 4.2.3
 s/Disabling Delayed ACKs at the
   sender allows an immediate ACK/Disabling Delayed ACKs at the
   request sender allows an immediate ACK

Sec 4.3.1
   When a multiple-segment window is used, the receiver will need to
   manage the reception of possible out-of-order received segments,
   requiring sufficient buffer space.

It's worth pointing out here that even a 1 MSS window should also manage out-of-order arrival, as the sender may send multiple sub-MSS packets that fit in the window. (On the other hand, the receiver is free to simply drop the out-of-order segment, thus forcing a retransmission).

Sec 4.3.3.1
s/since with SACK recovery/since SACK recovery

Hi,

Thank you for this document.  It is somewhat outside my area of expertise, but I do not see any network management related issues.

One minor comment:

    3.2.  Usage scenarios

       There are different deployment and usage scenarios for CNNs.  Some
       CNNs follow the star topology, whereby one or several hosts are
       linked to a central device that acts as a router connecting the CNN
       to the Internet.  CNNs may also follow the multihop topology
       [RFC6606].

Perhaps: "Alternatively, CNNs may also follow ... ", otherwise it feels like this paragraph stops quite abruptly, whereas from the first couple of sentences I was expecting it to say a bit more about the different deployment scenarios.

Regards,
Rob