Hi Hannes, (If I may be the one who replies...)
First of all, thanks very much again for your thorough and useful review. We have been working on updates to the document based on your comments. We plan to submit a new version of the draft before the next I-D cutoff (early enough so that the WG can react to the new draft version), and send you a proper set of responses as well. Cheers, Carles > Hi Michael, > > the document has in the meanwhile become a working group item and I was > wondering whether you and your co-authors have had a chance to look at > the comments in the meanwhile. > > Ciao > Hannes > > On 08/11/2017 10:37 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote: >> Hi Hannes, >> >> Thanks a lot for this very valuable review, which will be addressed. >> Please give us some time to come back with actual wording proposals. >> >> Thanks >> >> Michael >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] >>> Sent: Thursday, August 10, 2017 1:40 PM >>> To: jon.crowcr...@cl.cam.ac.uk; Scharf, Michael (Nokia - DE/Stuttgart) >>> <michael.sch...@nokia.com>; Carles Gomez Montenegro >>> <carle...@entel.upc.edu>; lwip@ietf.org >>> Subject: draft-gomez-lwig-tcp-constrained-node-networks-03 >>> >>> 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
