[tcpm] review on the last rev of lwig-tcp-constrained-node-networks

I also did a review based on the last rev of 
lwig-tcp-constrained-node-networks, after I saw it presented in TCPM.

Gorry

—
4.1.1. Maximum Segment Size (MSS)

" For the sake of lightweight implementation and operation, unless
applications require handling large data units (i.e. leading to an
IPv6 datagram size greater than 1280 bytes), it may be desirable to
limit the MTU to 1280 bytes in order to avoid the need to support
Path MTU Discovery [RFC8201]."

An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
the TCP MSS not larger than 1220 bytes. (Note: IP version 6 is
assumed.)

ISSUE:
I think the ID should also note the minimm size for IPv4 is smaller than 
1280B.
——
4.2.1. Single-MSS stacks - benefits and issues

NOTE: FastRetransmit/FastRecovery reduces recovery time, so a single MSS 
solution relies solely on timer-based recovery.

Also it later says: “A standard
compliant TCP receiver will then immediately acknowledge the second
segment, which can improve throughput. “
NOTE: I suggest a TCP receiver will acknowledge the second MSS of data.
- The ACK_Delay paremater can also can set a bound on the time to issue 
the ACK.
—-

4.3.1. Loss recovery and congestion/flow control

"Devices that have enough memory to allow larger TCP window size can
leverage a more efficient loss recovery using Fast Retransmit and
Fast Recovery [RFC5681],"

NOTE - insert "a" after "allow" and please define "larger” - i.e. "more 
than 3 MSS of data".
——
Section 4.3.1. Loss recovery and congestion/flow control could usefully 
be cross-referenced to 4.2.1 because these are on very similar topics.
—
The words memory and RAM are used in various places. I think memeory is 
arguably a better choice of word.
—
“Another approach is to use long-lived TCP connections with 
application-layer heartbeat messages. “
- No advice on how to set and use heartbeats. is there an RFC that 
provides this guidance,
- Is this advice any help - from RFC 8085?

"NATs require a state timeout of 2 minutes or longer [RFC4787]. However, 
empirical evidence suggests that a significant fraction of currently
deployed middleboxes unfortunately use shorter timeouts. The timeout
of 15 seconds originates with the Interactive Connectivity
Establishment (ICE) protocol [RFC5245]."
---

On 27/03/2019, 11:19, Carles Gomez Montenegro wrote:
 > Dear LWIG and TCPM WGs,
 >
 > We have just submitted a new revision (-06) of the draft referenced 
below.
 > This revision incorporates the comments that we received from Stuart
 > Cheshire.
 >
 > As expressed in the sessions in IETF 104, the authors believe that the
 > document is ready for WGLC.
 >
 > Thanks,
 >
 > Carles (on behalf of all authors)
 >
 >
 >
 > ---------------------------- Original Message 
----------------------------
 > Subject: [Lwip] I-D Action:
 > draft-ietf-lwig-tcp-constrained-node-networks-06.txt
 > From: internet-drafts@ietf.org
 > Date: Wed, March 27, 2019 11:10 am
 > To: i-d-announce@ietf.org
 > Cc: lwip@ietf.org
 > 
--------------------------------------------------------------------------
 >
 >
 > A New Internet-Draft is available from the on-line Internet-Drafts
 > directories.
 > This draft is a work item of the Light-Weight Implementation Guidance WG
 > of the IETF.
 >
 > Title : TCP Usage Guidance in the Internet of Things (IoT)
 > Authors : Carles Gomez
 > Jon Crowcroft
 > Michael Scharf
 > Filename : draft-ietf-lwig-tcp-constrained-node-networks-06.txt
 > Pages : 26
 > Date : 2019-03-27
 >
 > Abstract:
 > This document provides guidance on how to implement and use the
 > Transmission Control Protocol (TCP) in Constrained-Node Networks
 > (CNNs), which are a characterstic of the Internet of Things (IoT).
 > Such environments require a lightweight TCP implementation and may
 > not make use of optional functionality. This document explains a
 > number of known and deployed techniques to simplify a TCP stack as
 > well as corresponding tradeoffs. The objective is to help embedded
 > developers with decisions on which TCP features to use.
 >
 >
 > The IETF datatracker status page for this draft is:
 > 
https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/
 >
 > There are also htmlized versions available at:
 > 
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-06
 > 
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-06
 >
 > A diff from the previous version is available at:
 > 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-tcp-constrained-node-networks-06
 >
 >
 > 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.
 >
 > Internet-Drafts are also available by anonymous FTP at:
 > ftp://ftp.ietf.org/internet-drafts/
 >
 > _______________________________________________
 > Lwip mailing list
 > Lwip@ietf.org
 > https://www.ietf.org/mailman/listinfo/lwip
 >
 >
 > _______________________________________________
 > tcpm mailing list
 > tcpm@ietf.org
 > https://www.ietf.org/mailman/listinfo/tcpm