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

[Hannes Tschofenig <[e-mail]>]

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