Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
In Sec 4.1.1: An IPv6 datagram size exceeding 1280 bytes can be avoided by setting the TCP MSS not larger than 1220 bytes. This assumes that the remote sender will use no TCP options, aside from possibly the MSS option, which is only used in the initial TCP SYN packet. In order to accommodate unrequested TCP options that may be used by some TCP implementations, a constrained device may advertise an MSS 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 advertising an MSS smaller than 1220 bytes is likely to be overcautious and its suitability should be considered carefully. I would delete everything after the first sentence in this excerpt. While RFC6691 is informational, it clarifies RFC1122, which is a standard, and Sec 126.96.36.199 is quite clear that senders MUST consider TCP and IP option length when sizing TCP payloads. Absent any evidence that there are TCP endpoints or middleboxes that are violating RFC1122, further reducing the MSS because someone might be violating it is excessive.
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 188.8.131.52 s/since with SACK recovery/since SACK recovery
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, -éric == DISCUSS == Please replace all RFC 2460 references to RFC 8200. Trivial to fix ;-)
== 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 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/
[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.
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 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.
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