Re: [Lwip] Last Call: <draft-ietf-lwig-tcp-constrained-node-networks-10.txt> (TCP Usage Guidance in the Internet of Things (IoT)) to Informational RFC

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Fri, 18 September 2020 12:15 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899D53A0812; Fri, 18 Sep 2020 05:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9txWqeoedATz; Fri, 18 Sep 2020 05:15:01 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4217C3A07EF; Fri, 18 Sep 2020 05:14:59 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 08ICEuJ5035215; Fri, 18 Sep 2020 14:14:56 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 56D191D53C1; Fri, 18 Sep 2020 14:14:55 +0200 (CEST)
Received: from 2.142.148.95 by webmail.entel.upc.edu with HTTP; Fri, 18 Sep 2020 14:14:56 +0200
Message-ID: <a7d33f0bd4f5491be1affd868fb7144b.squirrel@webmail.entel.upc.edu>
In-Reply-To: <A4BB6B20-87EA-4F54-B35F-89FD7CBF9C80@fugue.com>
References: <160026450341.4741.15386274889650653489@ietfa.amsl.com> <157F51F5-28D9-46BE-A408-D79D647AE495@fugue.com> <A4BB6B20-87EA-4F54-B35F-89FD7CBF9C80@fugue.com>
Date: Fri, 18 Sep 2020 14:14:56 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Ted Lemon <mellon@fugue.com>
Cc: last-call@ietf.org, draft-ietf-lwig-tcp-constrained-node-networks@ietf.org, lwig-chairs@ietf.org, lwip@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 18 Sep 2020 14:14:57 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/QU193cQWGaJ3fBJEZ91QhYRZLKw>
Subject: Re: [Lwip] Last Call: <draft-ietf-lwig-tcp-constrained-node-networks-10.txt> (TCP Usage Guidance in the Internet of Things (IoT)) to Informational RFC
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2020 12:15:03 -0000

Hi Ted,

This document aims at offering guidance on the use of TCP in IoT
environments or use cases, based on contributions from a really long list
of folks from the LWIG and TCPM working groups, with diverse backgrounds
and expertise (from academia, industry, implementers, etc.). If
interested, you may want to see the Acknowledgments section.

Could you please provide any pointers to "existing research that
shows that MSS of greater than perhaps five lowpan frames is quite
harmful." ?

Also, we believe that the statement that the document "recommends larger
mss" is not true or accurate. In 4.1.1 we rather discuss the benefits of
not exceeding an MTU of 1280 bytes, and we give guidelines that may help
in this regard.

There is also the last paragraph of 4.1.1, which includes:

   "using larger MSS (to a suitable extent) may be beneficial, especially
    when transferring large payloads, as it reduces the number of packets
   (and packet headers) required for a given payload"

but it purposefully includes "to a suitable extent", which is also not
quantified, and it is given in the context of transferring large payloads.
And the "may" is also very relevant here.

We believe that what that last paragraph states is actually quite obvious,
implicitly assuming that the application of that paragraph will be done in
a careful, cautious way...

Best regards,

Carles (on behalf of all coauthors)



> On Sep 16, 2020, at 10:01 AM, Ted Lemon <mellon@fugue.com> wrote:
>> To a first approximation, this document is harmful garbage. It
>> recommends larger mss. Probably not based on opex.
>
> Wow, my first reply-all screwup in ages, and it was pretty bad. Really
> sorry about this—I did not intend to be this transparent on a public
> mailing list, and I hope my first impression is wrong. But with that said,
> that is my first impression, and I will be giving the document further
> review. It’s very disappointing to me that lwig has come out with this
> without, as far as I can tell, any reference to existing research that
> shows that MSS of greater than perhaps five lowpan frames is quite
> harmful.
>
> Could the authors common on what operational experience this document is
> based on?
>
> _______________________________________________
> Lwip mailing list
> Lwip@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>