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
