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:[email protected]] >> Sent: Thursday, August 10, 2017 1:40 PM >> To: [email protected]; Scharf, Michael (Nokia - DE/Stuttgart) >> <[email protected]>; Carles Gomez Montenegro >> <[email protected]>; [email protected] >> 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 [email protected] https://www.ietf.org/mailman/listinfo/lwip
