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

[Hannes Tschofenig <[e-mail]>]

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:[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