Re: [Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-01.txt]

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

Hi, 

I like this version better than the former one. Yet, I still have quite a number of observations:

1/ Target of the document (Best Current Practice)

The survey in the Appendix is very useful and it would be good to expand it. It states:

7.2.  lwIP

   lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers.
   lwIP has a total code size of ~14 kB to ~22 kB (which comprises
   memory management, checksumming, network interfaces, IP, ICMP and
   TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk].

   In contrast with uIP, lwIP decouples applications from the network
   stack. lwIP supports a TCP transmission window greater than a single
   segment, as well as buffering of incoming and outcoming data.  Other
   implemented mechanisms comprise slow start, congestion avoidance,
   fast retransmit and fast recovery.  SACK and Window Scale are not
   implemented.

So, it seems to me that the guidance written in the document (only a single window etc.) is actually *not* the best current practice actually used in lightweight implementations. So, to me the document needs significant changes to cover the lwIP implementation correctly, which I think would be appropriate.

Or does the document target only environments for which this lwIP stack does not apply?

2/ Section 2

I think you should better define the what exactly you mean by Constrained-Node Networks. For instance, is this limited to 6LoWPAN? What about some of the emerging 4G/5G radio interfaces that focus on energy constrained devices? Does the same guidance really apply to all (radio) networks?

2/ Section 4.2 Maximum Segment Size (MSS)

I think this section would first benefit from a wider survey of link technologies before coming to conclusions.

This sentence needs rewording regarding the "in any case", which could be read in different ways in particular in isolation: "In any case, the TCP MSS must not be set to a value leading to an IPv6 datagram size exceeding 1280 bytes."

The next sentence also needs rewording: "If a link layer technology used by a constrained device offers a link layer MTU greater than 1280 bytes, it is still useful to set the MSS so that IPv6 datagram size does not exceed 1280 bytes, in order to avoid issues due to Internet links that do not support greater MTUs." The Internet as a whole has means to handle MTUs larger than 1280 bytes, so this guidance seems not in general "useful". 

3/ Section 4.3.  Window Size
 
Why does this document include this recommendation even if there are relevant lightweight stacks that can do much better?

I think what is more appropriate would be a wording such as: "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."

And the following sentence should probably replace "use" by "allow": "For devices that can afford greater TCP window size, it may be useful to use window sizes of at least five MSSs, in order to allow Fast Retransmit and Fast Recovery [RFC5681]." If a sender has larger window sizes, it has to implement congestion control, and as a result the window size will be variable. After an RTO, it can be as low as one MSS and is thus less than 5 MSS. I could read this sentence as suggesting a fixed minimum window size, which is not appropriate.

4/ Section 4.4.  RTO estimation

This section must be entirely rewritten. First of all, this section should cite draft-ietf-tcpm-rto-consider and consider the guidance therein (in particular Section 3). One of the key insights of draft-ietf-tcpm-rto-consider is that there is typically no single best algorithm, as there are always tradeoffs. If this conclusion was wrong, this document would have to explicitly explain why. draft-ietf-tsvwg-rfc5405bis could also be referenced.

To me, the key aspect that this section should probably discuss is that if a sender uses only very small window sizes and can hardly use fast retransmit (or even SACK), the RTO algorithm has a larger impact on the performance than for a more powerful TCP stack. This may open room for some algorithm tuning. But then the downsides of doing that should also be discussed (e.g., spurious timeouts etc.). 

5/ Section 4.5.  TCP connection lifetime

I think in this section you should better separate what a TCP stack should support, or not, and how the TCP stack should be used by applications, e.g., whether to close connections or not.

6/ Section 4.6.  Explicit congestion notification

As motivation for ECN the text notes "As transactional data size decreases, the probability of detecting congestion by the presence of three duplicate ACKs decreases." But three DUPACKs are quite impossible if the sender follows Section 4.3, right?

7/ Section TCP options

The sentence

  "A TCP implementation for a constrained device that uses a single-MSS TCP receive or transmit window size will benefit from not supporting, and ignoring if received, the following TCP options: Window scale [RFC1323], TCP Timestamps [RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted [RFC2018]."

should at least be reworded to 

  "A TCP implementation for a constrained device that uses a single-MSS TCP receive or transmit window size may not benefit supporting from the following TCP options: Window scale [RFC1323], TCP Timestamps [RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted [RFC2018]."

I do not believe that RFC 2119 language of the form "Other TCP options SHOULD NOT be used, in keeping with the principle of lightweight operation." is appropriate, in particular since it may also exclude future new TCP options that specifically target lightweight operation. 

Also, this section may have to consider TFO options as this is discussed elsewhere in the draft.

8/ Section 4.8.  Delayed Acknowledgments

I think the last paragraph in this section should be moved earlier in the document, i.e., the document should probably explain early the different types of workloads in a CCN as well as their possibly different needs regarding TCP stack configuration. The assumption that most communication sizes is smaller than one MSS is very fundamental and if it is violated, a lot of the reasoning in the document does not apply.

9/ Section 5.  Security Considerations

I am not a security expert but here is a question: If an attacker knows that a TCP stack only uses a window of one MSS (because it sits in a CCN), and if some packet can be passively intercepted, isn't the likelihood of successfully injecting segments into an established TCP connection larger?

Another aspect to be mentioned is that certain TCP options can improve TCP security (e.g., MD5, TCP-AO) but come along with complexity.

Thanks

Michael



> -----Original Message-----
> From: Lwip [mailto:[e-mail]] On Behalf Of Carles Gomez Montenegro
> Sent: Monday, October 31, 2016 1:36 PM
> To: [e-mail]; [e-mail] Extensions
> Subject: [Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-
> constrained-node-networks-01.txt]
> 
> Dear LWIG and TCPM WGs,
> 
> Please find below pointers to our update of the TCP over Constrained-Node
> Networks I-D.
> 
> In this version we expand the document while trying to address many of the
> comments received on -00. The main changes are:
> 
> - Remove RFC 2119 language and rather document how TCP can be used in CNNs
> 
> - Illustrate scenario (e.g. constrained to unconstrained device...)
> 
> - 'Allow' window greater than 1 MSS (and Fast recovery & Fast retransmit)
> 
> - Add TCP Fast Open subsection
> 
> - Add Delayed ACKs section
> 
> - Improve section on TCP options
> 
> - Collect implementation details (Annex)
> 
> Note that the home WG for this work is LWIG (as discussed in Berlin).
> 
> Thanks a lot for the feedback received so far. Comments on -01 are welcome
> and appreciated!
> 
> Cheers,
> 
> Carles and Jon
> 
> 
> 
> 
> ---------------------------- Original Message ----------------------------
> Subject: New Version Notification for
> draft-gomez-lwig-tcp-constrained-node-networks-01.txt
> From:    [e-mail]
> Date:    Mon, October 31, 2016 1:13 pm
> To:      "Jon Crowcroft" <[e-mail]>
>          "Carles Gomez" <[e-mail]>
> --------------------------------------------------------------------------
> 
> 
> A new version of I-D, draft-gomez-lwig-tcp-constrained-node-networks-01.txt
> has been successfully submitted by Carles Gomez and posted to the
> IETF repository.
> 
> Name:		draft-gomez-lwig-tcp-constrained-node-networks
> Revision:	01
> Title:		TCP over Constrained-Node Networks
> Document date:	2016-10-31
> Group:		Individual Submission
> Pages:		13
> URL:
> https://www.ietf.org/internet-drafts/draft-gomez-lwig-tcp-constrained-node-
> networks-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gomez-lwig-tcp-constrained-node-
> networks/
> Htmlized:
> https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-networks-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-gomez-lwig-tcp-constrained-node-
> networks-01
> 
> Abstract:
>    This document provides a profile for the Transmission Control
>    Protocol (TCP) over Constrained-Node Networks (CNNs).  The
>    overarching goal is to offer simple measures to allow for lightweight
>    TCP implementation and suitable operation in such environments.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> Lwip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lwip