Hi Michael, Jon, Carles it is great that you have worked on this topic and, as stated during the Prague IETF meeting, I believe this document should become a WG item of the LWIG working group.
I nevertheless have a couple of comments & questions. - Who do you think is the main audience for this draft? Is it primarily written for implementers of embedded TCP stacks or is it rather written for embedded developers who have to decide what stack and what features of TCP to use? If you ask me, I prefer it to be the latter. The reason is that there are very few implementers who write their own embedded TCP stack. There is, however, also an implication if you are aiming for the latter group, namely you cannot expect them to know all the details of TCP well. So, you need to present them with enough background so that they can make informed trade-off decisions. - The title of the document was probably the reason why I only noticed it recently. For some reason the term "Constrained Node Networks" does not stick well with me. I would have expect to see something like "Guidance for TCP Usage for Internet of Things". I am also uncertain why you claim that the document defines a profile. It does not really define any profiles as far as I can tell. - I would like to see some discussion about the communication patterns. For example, in the draft you talk about transactions (and I assume you mean request/response interactions). Are you focusing on those only or do you also consider cases of firmware updates into account? (In Section 4.8 you briefly mention firmware updates.) Have you looked at traffic patterns of some IoT applications? - Section 7 with the information about the protocol stacks is great. I hope you will complete the table some time in the near future and provide additional information about RAM requirements as well (in addition to the codesize). More detailed comments: You write: "In order to meet the requirements that stem from CNNs, the IETF has produced a suite of protocols specifically designed for such environments [I-D.ietf-lwig-energy-efficient]." The IETF approach on IoT in general has been to re-use as much as possible rather than to develop a whole new universe just for IoT. There are, however, a few new protocol developments but those are not really described well in [I-D.ietf-lwig-energy-efficient] since [I-D.ietf-lwig-energy-efficient] talks specifically about energy efficiency. [I-D.tschofenig-core-coap-tcp-tls] has been replaced by [I-D.ietf-core-coap-tcp-tls]. You write: "On the other hand, other application layer protocols not specifically designed for CNNs are also being considered for the IoT space. Some examples include HTTP/2 and even HTTP/1.1, both of which run over TCP by default [RFC7540][RFC2616], and the Extensible Messaging and Presence Protocol (XMPP) [RFC 6120]. TCP is also used by non-IETF application-layer protocols in the IoT space such as MQTT and its lightweight variants [MQTTS]." I don't think the reference to [MQTTS] is appropriate. The other variant of MQTT, which exists as a standardized protocol is MQTT-SN and it uses UDP (if I recall correctly). As such, it does not fit into the argument you are making about TCP usage. XMPP is also not a good example since it is mostly used on gateways rather than low end IoT devices. It is just a very verbose protocol. Section 2 about "Characteristics of CNNs relevant for TCP" somehow feels a bit misplaced. I am wondering whether there is any loss in value of the document if you delete this entire section. RFC 7228, which you reference already in the abstract, talks about the constraints of IoT devices and there is probably no need to repeat them again (and if you think so then maybe it fits better into the introduction). Section 3 talks about the scenario and speaks about a model where constrained devices connect to unconstrained servers (cloud). What about cases where the TCP server itself is running on an IoT device? It appears that you consider such a scenario out of scope. Also the text in Section 4.1 gives me that impression. Section 4 is where the meat of the document is. I personally would have structured the document a bit differently. It seems to me that there is the impression in the engineering community that a TCP stack is complex (and therefore codesize-wise large) and requires a lot of RAM. I would have probably started by informing the reader of where the complexity comes from and what "tuning" can be done to make it more lightweight. 4.2. Maximum Segment Size (MSS) Am I reading the recommendations correctly? You have three cases: If the underlying layer supports a frame size of ... 1) < 1280 bytes THEN use an adaptation layer (like 6lowpan to make it look like case #2) 2) 1280 bytes THEN you are OK. 3) > 1280 bytes THEN limit the MTU to 1280 bytes and you SHOULD use the Path MTU mechanism. 4.3 Window Size You write: " A TCP stack can reduce the implementation complexity by advertising a TCP window size of one MSS, and also transmit at most one MSS of unacknowledged data, at the cost of decreased performance. This size for receive and send window is appropriate for simple message exchanges in the CNN space, reduces implementation complexity and memory requirements, and reduces overhead (see section 4.7). " I don't think it is a matter of implementation complexity on how large the window size should be but rather a question of how much RAM you have. I think that this section could better describe the performance tradeoffs. You write: " A TCP window size of one MSS follows the same rationale as the default setting for NSTART in [RFC7252], leading to equivalent operation when CoAP is used over TCP. " Could you explain the relationship between MSS and the NSTART concept in CoAP in more details? I only see an indirect relationship (via the congestion control mechanism) but not a direct one. I am also uncertain what you mean by the reference to CoAP over TCP. Expand and ideally explain all abbreviations, such as RTO You write: " For devices that can afford greater TCP window size, it may be useful to allow window sizes of at least five MSSs, in order to allow Fast Retransmit and Fast Recovery [RFC5681]. " Could you expand a bit on what you mean by "can afford"? If you have x amount of additional KB RAM then .... 4.4 RTO estimation You write: " A fundamental trade-off exists between responsiveness and correctness of RTOs [I-D.ietf-tcpm-rto-consider]. " Maybe you can explain the reader what the tradeoff is rather than just pointing to the document. You make an attempt in the text following the statement but it is incomplete (at least according to my reading of the tcp-rto-consider document.) At least I would have expected that you provide the recommendation from [I-D.ietf-tcpm-rto-consider] regarding the RTO setting or mention the timer setting in the DTLS/TLS profiles for IoT. I also believe that the paragraph about the work on congestion control for CoAP isn't really appropriate in this document. I would delete it. I understand why Carles wants to have it in there though ;-) 4. TCP connection lifetime In the discussions regarding using TCP keep-alive messages for CoAP over TCP we essentially got no response: https://www.ietf.org/mail-archive/web/maprg/current/msg00016.html I would expect a recommendation whether TCP keep-alives should or should not be used. With CoAP over TCP we have also defined a separate ping/pong mechanism. 4.7. TCP options You write: " TCP implementation for a constrained device that uses a single-MSS TCP receive or transmit window size may not benefit from supporting the following TCP options: Window scale [RFC1323], TCP Timestamps [RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted [RFC2018]. Other TCP options should not be used, in keeping with the principle of lightweight operation. Other TCP options should not be supported by a constrained device, in keeping with the principle of lightweight implementation and operation. " The last sentence starting with "Other TCP options ..." appears twice. I am not sure I understand the recommendation: Are you saying that "TCP implementation for a constrained device that uses a single-MSS TCP receive or transmit window size should not implement any TCP options?" Then, for all other devices should they implement SACK and TFO? Maybe you want to explain your rational a bit more, particularly under why you do not consider certain TCP options useful in an IoT environment. 4.8. Delayed Acknowledgments The recommendation is not clear to me. It sounds like you are suggesting to almost dynamically adjust the ACKs based on the type of traffic being sent. 5. Security Considerations I don't think that the The TCP Authentication Option is a useful option for IoT deployments. At least I haven't even heard anyone suggesting it to be used so far. Most standards (even outside the IETF) recommend the use of TLS. 8. References IMHO there are too many references in the normative reference section. I would put the background reading into the informative section. Ciao Hannes _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip