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

[G Fairhurst <[e-mail]>]

On 27/03/2019, 15:41, G Fairhurst wrote:
> 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: [e-mail]
> > Date: Wed, March 27, 2019 11:10 am
> > To: [e-mail]
> > Cc: [e-mail]
> > 
> --------------------------------------------------------------------------
> >
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lwip
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm