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

["Carles Gomez Montenegro" <[e-mail]>]

Hi Michael,

First of all, sorry for the delay in this response, and thanks a lot for
your comments, suggestions and pointers.

We have updated the draft with the aim to address your comments. Latest
version is -02.

Please find below inline responses:

> 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?

The correct intended status for the draft is Informational. The “BCP”
previously shown in the draft should have already been replaced by
"Informational" in -01. Solved in -02.

> 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?

CNNs are defined in RFC 7228 as networks whose characteristics are
influenced by being composed of a significant portion of constrained
nodes.

CNNs are not limited to 6LoWPAN/6Lo networks. Guidance may apply to other
networks as long as devices (and the links/networks they use) suffer the
type of constraints  described for ‘constrained nodes’. Please note that
the actual definition of CNNs [RFC 7228] is not tied to 6LoWPAN or any
particular type of network/technology.


> 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.

-02 refers also to other technologies used in the CNN space (such as
MS/TP, IEEE 802.11ah and NB-IoT) which do not suffer the same degree of
frame (payload) size limitation as the ones already mentioned.

> 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."

Agreed and done.

> 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".

Agreed. This text has been removed.

> 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."

Agreed and applied to the document.

> 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.

Agreed and applied to the document.

> 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.).

Modified the section accordingly. However, CoCoA RTO work is still
mentioned (now as a note on a related area, just for informational
purposes).

> 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.

Agreed. This will be done in future revisions.

> 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?

After the changes in section 4.3, this comment is hopefully addressed.

> 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]."

Agreed. Applied to the document.

> 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.

Sorry, we missed that one in -01. Removed this 2119 form now.

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

TFO is now mentioned in the section for completeness, although the main
description of TFO comes already in section 4.5.

> 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.

Updated text in -02 just describes when delayed ACKs are recommended and
when they are not, without stating whether some scenarios are more likely
than others. Even if my current *impression* is the one formerly expressed
in the document, a more solid support for it would be needed, and also the
way CNNs are used may vary over time (and it definitely varies across
scenarios). Implementers or administrators may choose the most appropriate
setting for each particular scenario.

> 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?

Do you mean something like a replay attack? Generating a spoofed duplicate?

Why is the likelihood of successfully injecting segments greater? Is it
e.g. because it makes it easier for the attacker to appear as a legitimate
sender when the actual legitimate sender is silent?

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

Agreed. A brief description of these has been added.

Cheers,

Carles

> Thanks
>
> Michael