Re: [Lwip] draft-gomez-lwig-tcp-constrained-node-networks-03

["Scharf, Michael (Nokia - DE/Stuttgart)" <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, August 10, 2017 1:40 PM
> To: [e-mail]; Scharf, Michael (Nokia - DE/Stuttgart)
> <[e-mail]>; Carles Gomez Montenegro
> <[e-mail]>; [e-mail]
> 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